Duymamış olabileceğiniz absürt programlama ilkeleri
Arama

Duymamış olabileceğiniz absürt programlama ilkeleri

Kod yazarken 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. Bu normal kabul edilen absürt durumlardan 10 tanesini inceledik.

Bloat Principle

Zawinski Kuralı olarak da bilinen Bloat Principle (Şişme İlkesi) kodunuzun zamanla büyüyüp kaçınılmaz olarak karmaşıklaşması durumuna verilen bir ad. Sürekli eklediğiniz yeni özelliklerin eninde sonunda kodunuzu asıl amacından ve ilk basitliğinden uzaklaştıracağını ifade ediyor. Kurala göre, her kod genişleyip şişmeye ya da artık kullanılmamaya mahkum.

“Daha kötü daha iyidir” zihniyeti

“Daha Kötü Daha İyidir” Zihniyeti (The “Worst is Better” Mentality) programınızın spesifik bir soruna çözüm olarak çalışmasının, farklı sorunlara da uygulanabilir olmasından daha iyi olduğunu savunuyor. Basit ve hedeflediği sorunu çok iyi çözen programlar hem daha verimli çalışıyorlar hem de daha çok kullanıcı çekiyorlar. Aksi takdirde, gerek kullanıcılar gerek geliştiriciler tarafından anlaşılması zorlaşıp kullanışlılığını yitiriyor.

Eagleson yasası

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.

Principle of least astonishment

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.

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. Ne kadar olumsuz bir ifade olsa da, mükemmelliyetçiliği bir kenara bırakıp bug’ları ortaya çıktıkça yok etmeye yönlendirerek iyi bir amaca hizmet ettiğini düşünebiliriz.

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. 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.

Plastik ördekle bug yakalama

Plastik Ördekle Bug Yakalama (Rubber Duck Debugging), sıkça karşılaşılan durumlar için yapılan bir tespitten ziyade bir öneri. 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.

Doksan-doksan kuralı

Kodun %90’ını yazmak zamanınızın %10’unu alır. Geriye kalan %10’unu yazmaksa diğer %90’ını alır. 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.

Yorumları GösterYorumlar Gizle (1)
  1. Serkan dedi ki:

    Yaşadığım stresli veya karmaşık anları aslında birçok meslektaşımında yaşamış olması beni mutlu etti 🙂

Bir Yorum Yazın