İlk kez duyacağınız 10 adet garip programlama ilke ve yasaları

Programlama yaparken veya kodlama yaparken sıkça karşılaştığınız talihsizlikleri, programlama sürecinin garip gerçeklerini sadece siz yaşamıyorsunuz. O kadar yaygınlar ki hepsinin birer adı ve tanımı var. Programlama yaparken, çeşitli zaman aralıklarında çeşitli kontroller yapılmazsa iş bir anlamda çığrından çıkıyor ve başedilemez hale geliyor. Bu durumların her birini dünya üzerindeki neredeyse tüm yazılımcılar yaşıyor. Bu bağlamda bu problemlerin hepsinin daha önce yaşayanlar tarafından verilmiş bir adı ve tanımı bulunuyor. Sizler için 10 tanesini inceledik.

Plastik Ördekle Bug Yakalama (Rubber Duck Debugging)

Orijinal adı Rubber Duck Debugging bilinen bu durum sıkça yaşanan bug durumlarının önüne geçmek için oluşturulan bir öneri. The Pragmatic Programmer adlı kitapta bulunan bir hikayeye atıfta bulunan bu tanıma göre programcı yazdığı kodları ördeklere açıklamaya çalışıyor ve yaptığı hataları ortaya çıkarıyor. Kodunuzu bug’larından arındırmaya çalışırken belki de yapabileceğiniz en etkili şey kodunuzu satır satır bir objeye anlatmak. Anlatırken kodunuza farklı açılardan bakıp nerede hata yaptığınızı görebiliyorsunuz. Böylece plastik ördek kodunuzdaki bug’ları bulmanızda yardımcı oluyor.Ördek kullanılmasının sebebi ise bu işten hiç anlamayan birisine anlatır gibi yapılması.

Bloat Principle (Zawinski Kuralı-Şişme İlkesi)

Zawinski Kuralı olarak da bilinen Bloat Principle (Şişme İlkesi) yazılan kodun zamanla büyüyerek içinden çıkılmaz bir hal alması durumuna verilen isim. Durumu şu şekilde izah edecek olursak; bir kod yazmaya başladığınız zaman, diyelim ki bir web sitesi yapıyosunuz, iş ilerledikçe çeşitli özellikler eklemeye başlıyorsunuz ve daha sonra tekrar farklı özellikler ekliyorsunuz en sonunda aklınızda olan o sade ve basit tasarım oldukça karmaşık bir yapıya dönüşmüş oluyor. Bu kurala göre her kod genişleyip şişmeye ya da artık kullanılmamaya mahkum.

The “Worse is Better” Mentality (“Daha Kötü Daha İyidir” Zihniyeti)

“Daha Kötü Daha İyidir” Zihniyeti (The “Worse is Better” Mentality) Bloat Principle ilkesine tepki olarak Richard P. Gabriel tarafından bilgisayar yazılımı kalitesi üzerine yayınlanan bir deneme içerisinde ortaya çıkmıştır. Basitçe söylemek gerekirse, yazılımınızın çözmeye çalıştığı ana sorunu belirlemek akıllıca olacaktır ve bu çerçevede hareket edilirse her şey iyi olacaktır. Basit tutmak önemlidir çünkü çok fazla detaycı olmak ipin ucunun kaçmasına sebep olabilir ve müşteriler istemeyebilir.

 

Eagleson Yasası

Kodlama bir dilin yazıya dökülmesi gibidir. Ancak bu dil ana diliniz gibi sürekli konuştuğunuz bir dil olmadığı için unutulmaya elverişli bir yapıdadır. 6 aydan uzun süredir bakmadığınız herhangi bir kod, sanki başkası yazmışçasına yabancıdır. Biraz şevk kırıcı bir beyanda bulunan Eagleson Yasası, aslında bir geliştirici olarak 6 aydaki ilerlemenize dikkat çekiyor. Her kod daha iyi yazılabilir ve her zaman daha iyi bir geliştirici olabilirsiniz. Öyle ki, geçmiş kodlarınıza bakıp yabancılık hissetmiyorsanız, muhtemelen bu sürede kendinizi pek de geliştirmediğinizdendir. Elbette buna karşı çıkanlar olacaktır ve belki de bu bir yasa değil hala bir teoridir.

Principle of Least Astonishment (Minimum Hayret İlkesi)

Türkçe’de Minimum Hayret İlkesi şeklinde ifade edebileceğimiz ilke, kullanıcıların radikal değişimlere kolay adapte olamaması üzerine yapılan bir tespit. Yenilik getirirken halihazırda alışılmış yapıdan çok uzaklaşan bir yazılımın, kullanıcıların beklentisine yabancı kalacağını ifade ediyor. Bu nedenle büyük değişimlerdense adım adım ilerlemeler daha iyi bir seçim olabilir.Zira kullandığımız sosyal ağlara baktığımızda da durum böyledir hiçbir zaman radikal bir değişiklik görmemekteyiz. Elbette bu durumun keskin bir değişimin gerektiği zamanlarda anlamsız olduğunu da söylemek yanlış olmaz.

Sibernetik Böcek Bilimi Yasası

Kim olduğu bliinmeyen bir Lubarsky’nin Kuralı olarak da bilinen Sibernetik Böcek Bilimi Yasası (Law of Cybernetic Entomology), kodunuzda her zaman bir bug daha olduğunu iddia ediyor. Ne kadar uğraşırsanız uğraşın bir yerlerde hep bir bug daha olacak. Yani mükemmel diye bir şey yoktur.

Kernighan Yasası

Kernighan Yasası’na göre, bir koddaki bug’ları temizlemek kodu yazmaktan iki kat daha zordur. Bu yüzden de yazabildiğiniz en iyi kodun bug’larından arındırmanız mümkün olmayacaktır. C programlama dilinin kitabını yazan Brian Kernighan, bu bilgilendirici yasa ile ünlüdür. Bu durumda yapılacak en mantıklı hareket akıllıca kodlar yazmaktansa iyi, okunabilir ve basit kodlar yazmak olabilir.  Çünkü bir kod ne kadar anlaşılırsa, bug’larından da o kadar kolay temizlenebilir.

Doksan-Doksan Kuralı

Başka bir deyişle kendinizi bu işi bitirmeye yakın görürken kısa bir göz gezdirdiğinizde henüz ortalara geldiğinizi anlarsınız.

Bu kurala göre kodun %90’ını yazmak zamanınızın %10’unu alır. Geriye kalan %10’unu yazmaksa diğer %90’ını alır. Tom Cargill’in bu tanımı kodlamanın can sıkıcı olmasının bir anlamda temelini oluşturuyor: Birazdan biteceğini düşündüğünüz kodların sonradan bakınca daha yeni başlamış olduğunu fark ettiğiniz zamanlar bu ilkeyi haklı çıkarır cinsten. Biraz sinir bozucu olsa da, herkesin başına geldiğini görmek rahatlatıyor.

Parkinson Yasası

Bir koda harcayacağınız zaman, harcayabileceğiniz zaman kadardır. Yapılacak iş elinizdeki zamanı tamamen kullanacak kadar uzar. Bu bağlamda programlama dışında pek çok iş için de geçerli olduğunu düşünebiliriz. Parkinson Yasası’ndan çıkarılacak sonuç, bir kodu yazmak için belirli bir süre ayırmak ve onu aşmamak olabilir.

 

Brook Yasası

Bir kodla ilgilenen kişi sayısı arttıkça, kodu yazma süresi de artacaktır. Herkesin aynı şekilde düşünmesi, grup içi iletişimin sağlanması derken kodun tamamlanması bir kişiye göre çok daha uzun sürecektir. Bir daha bir kodu yetiştirmekte zorlandığınızda, Brook Yasası’nı düşünüp işe başka insanları dahil etmeden önce plastik ördeğinizle tekrar bakmak isteyebilirsiniz.

 

 

Please follow and like us:
0

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir