Çoxumuzun bilmədiyi "absurd" proqramlaşdırma prinsipləri
Kod yazmaq özlüyündə bir sənətdir və onu yazarkən müxtəlif hallarla qarşılaşa bilərik. Bu zaman fərqli vaxt intervallarında müxtəlif yoxlamalar aparılmazsa, kod nəzarətdən çıxır və idarəolunmaz hala gəlir. Dünyadakı demək olar ki, bütün proqram tərtibatçıları bu tip vəziyyətlərlə qarşılaşır. Bu kontekstdə bəzi problemlərin daha əvvəl yaşamış şəxslər tərəfindən verilmiş bir adı və tərifi var.
"Rubber Duck ilə bug tutmaq" prinsipi
Kodunuzdakı səhvləri düzəltməyə çalışarkən bəlkə də edə biləcəyiniz ən təsirli şey kodunuzu sətir-sətir obyektə izah etməkdir. İzah edərkən kodunuza müxtəlif rakurslardan baxa və harada səhv etdiyinizi görə bilərsiniz. Beləliklə, oyuncaq ördək kodunuzda səhvləri tapmağa kömək edir.
Bloat prinsipi
Bu prinsip Zavinski qanunu kimi də tanınır. Bu yazılı kodun zamanla böyüdüyü və çıxılmaz hala gəldiyi vəziyyətə verilən addır. Vəziyyəti belə izah etsək: Deyək ki, web sayt qurursunuz, kod yazmağa başlayanda, iş irəlilədikcə müxtəlif funksiyalar əlavə etməyə başlayırsınız və sonra yenə də fərqli xüsusiyyətlər əlavə edirsiniz, nəticədə sadə dizayn çox mürəkkəb bir quruluşa çevrilir. Bu qaydaya görə, hər bir kod genişlənməyə və artıq istifadə olunmamağa məhkumdur.
Eagleson qanunu
Bu kodlaşdırma dilin transkripsiyasına bənzəyir. Ancaq bu dil ana dilimiz kimi davamlı danışdığımız bir dil olmadığı üçün unudulmağa meyllidir. Təsəvvür edin ki, siz aylar əvvəl öz ana dilinizdən başqa dildə məqalə yazmısınız və indi onu yoxlayırsınız. Onlar unudulur və sizə öz cümlələriniz deyilmiş kimi gəlir. Kodlaşdırmada da vəziyyət çox oxşardır; 6 ay əvvəl yazılmış kod ardıcıllığı indi sizə yad görünür. Eagleson qanunu tərtibatçıların 6 ay ərzində irəliləyişini göstərir. Çünki, insanlar daim inkişafdadır və bu qanuna görə, aylar əvvəl yazdığınız koddan daha yaxşı kod yaza bilmirsinizsə, deməli, inkişaf etməmisiniz.
"Hər zaman başqa bir səhv var" prinsipi
Adətən Lubarskinin Kibernetik Entomologiya Qanunu olaraq adlandırılan bu qanun bildirir ki, proqram kodunu nə qədər təmiz yazsanız da, onun komponentlərini nə qədər sınaqdan keçirsəniz, nə qədər tez-tez refaktor etsəniz də, yenə də bir səhv olacaq. Deməli, mükəmməl deyə bir şey yoxdur.
Kernigan qanunu
Bu qanuna görə, koddakı səhvləri aradan qaldırmaq kodun özünü yazmaqdan iki dəfə çətindir. Buna görə də, kodu mümkün qədər ağıllı yazsanız belə, onu sazlamaq üçün kifayət qədər ağıllı olmadığınız ortaya çıxır. C proqramlaşdırma dili haqqında kitab yazan Brayan Kernigan bu informativ qanunu ilə məşhurdur. Bu halda ən məntiqli hərəkət ağıllı kodlar yazmaqdansa yaxşı, oxunaqlı və sadə kodlar yazmaq olardı. Çünki, kod nə qədər başa düşülsə, onu səhvlərdən təmizləmək bir o qədər asan olar.
Brook qanunu
Ümumiyyətlə, qanunda göstərilir ki, proqram təminatı prosesində nə qədər çox işçi qüvvəsi iştirak edirsə, kodun yazılması bir o qədər çox vaxt aparır. Bu, hər kəsin eyni işlə məşğul olması kimi izah edilir. Belə ki, bu daha uzun vaxt və mümkün vəziyyətdən çıxmaq üçün daha çox müzakirələr tələb edəcək.
"Least Astonishment" prinsipi
Minimum sürpriz kimi də ifadə oluna bilən bu prinsipə görə, proqram tərtibatçısı yazdığı koda yenilik gətirmək istəyərkən radikal bir rəftar edərsə, tamamilə yad bir məhsul istehsal edə bilər. Bu kontekstdə böyük dəyişiklikdənsə, addım-addım irəliləmək daha vacibdir. Məsələn, istifadə etdiyimiz sosial şəbəkələrə də baxsaq belədir, heç vaxt köklü dəyişiklik görmürük.
90-90 qaydası
Kodun 90%-ni yazmaq vaxtınızın 10%-ni alır. Qalan 10%-i yazmaq isə qalan 90%-ni aparır. Tezliklə bitəcəyini düşündüyünüz kodların indicə başladığını anladığınız zaman bu prinsip özünü doğruldur. Bir az sinir bozucu olsa da, hər kəsin başına gəldiyini görmək rahatlıq verir. Sizcə də elə deyil mi?
Parkinson qanunu
Tədqiqatlar göstərir ki, insanlara yerinə yetirmək üçün tapşırıq veriləndə “Onu tamamlamaq üçün mənə nə qədər vaxt lazımdır?” deyə soruşurlar. Bu düşüncə tərzi insanların lazımsız yerə vaxt itirməsinə və nisbətən səmərəsiz işləməsinə səbəb ola bilər. İnsan bir işlə bağlı vaxtını nə qədər genişləndirsə, bu işə diqqəti bir o qədər dağılacaq.
Cyril Northcote Parkinson tərəfindən hazırlanmış bu qanun daha geniş prinsipdir və 90-90 qanunu ilə birləşir. Proqram təminatının hazırlanmasında "erkən bitirmək" həqiqətən bir fantaziyadır. Bu kontekstdə Parkinson qanununun proqramlaşdırmadan başqa bir çox iş üçün keçərli olduğunu düşünə bilərik. Bu qanununun mənası kodu yazmaq üçün müəyyən bir vaxt ayırmaq və onu aşmamaq olardı.
Proqramlaşdırma sahəsi daim inkişaf edir və bu prinsiplər, tərtibatçılara təcrübə və bacarıq qazanmağa kömək edir. Daim öyrənmək, inkişaf etmək və müstəqil düşünmə qabiliyyətinizi artırmaq üçün bu prinsipləri tətbiq edə bilərsiniz.