22
6
5
2
0
Kod yazmak başlı başına bir sanat ve bu sanatın icra edilmesi sırasında çeşitli talihsiz durumlar da yaşanabiliyor. 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" bu cümleyi ya da tanımı daha önce hiç duydunuz mu? Elbette birçok yazılımcının bu tip teknik ve küresel ifadelerden haberi vardır. Zira normal bir insanın yaşam evrelerini daha farklı bir şekilde yaşayan bu insanlar dünya üzerinde herhangi bir noktada olan ufak bir olaydan sanki yanı başında olmuş gibi haberdar olabiliyor. ( Ya da bize öyle geliyor. ) Bu içerikte yukarıdaki tanıma benzeyen bazı yasa ve önerileri derledik.

Plastik Ördekle Bug Yakalama

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. Ördek kullanılmasının sebebi ise bu işten hiç anlamayan birisine anlatır gibi yapılması.

Bloat Principle

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.

“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. "Sınırlı, ancak kullanımı kolay yazılım, kullanıcıya ve pazara sınırlı olmayan ve karmaşık olandan daha cazip gelebilir." 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. Aylar önce ana diliniz dışında bir yazı yazdığınızı düşünün ve şimdi kontol ettiğinizi hayal edin. Sanki sizin cümleleriniz değil gibi gelir. Kodlamada da durum buna çok benzerdir, 6 ay önce yazılan bir kod silsilesi artık size yabancı gelmektedir. Kabaca Eagleson Yasası, geliştiricilerin 6 aylık ilerlemelerine dikkat çekiyor. Zira insan sürekli bir gelişim içindedir ve bu yasaya göre aylar önce yazdığınız koddan daha iyisini yazamıyorsanız gelişmemişsiniz demektir. Elbette buna karşı çıkanlar olacaktır ve belki de bu bir yasa değil hala bir teoridir.

Principle of Least Astonishment

Türkçe’de Minimum Hayret İlkesi şeklinde ifade edilebilecek bu ilkeye göre, yazılımcı yazdığı kodda yenilik getirmek isterken ekstrem noktalara ya da radikal bir tutum içerisine girerse, kullanıcıların beklentisine yabancı bir ürün ortaya koyabilir. Bu bağlamda büyük değişim yerine adım adım ilerlemek daha önemlidir. 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ı

"Her zaman bir bug daha var."  Tipik olarak Lubarsky'nin Sibernetik Entomoloji Yasası olarak anılan bu yasada (Lubarsky'nin kim olduğu belirsizdir.) program kodunuzu ne kadar temiz yazdığınızdan bağımsız olarak, bileşenlerini ne denli sağlam test ettiğinizden bağımsız olarak, sınıflarınızı ne sıklıkta refactorladığınıza bakılmaksızın, bir hata daha olacaktır. Yani mükemmel diye bir şey yoktur.

Kernighan Yasası

Bu yasaya göre hata ayıklama kodu yazmaktan iki kat daha zor bir süreçtir. Bu nedenle kodu olabildiğince akıllıca yazsanız da hata ayıklama işlemi için yeterince akıllı olmadığınız ortaya çıkar. 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.

Doksan-Doksan Kuralı

Bu kurala göre kodun %90'lık kısmı toplam harcanan emek süresinin %10'una denktir. Dolayısıyla geriye kalan %10'luk kısım da zamanın %90'ını kapsamaktadır. Tom Cargill'in bu tanımı kodlamanın can sıkıcı olmasının bir anlamda temelini oluşturuyor: zira ne kadar yakın olduğunuzu düşünseniz de bir o kadar uzakta olduğunuzu görebiliyorsunuz. 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.

Parkinson Yasası

"İş, tamamlanması için gereken zamanı dolduracak şekilde genişler." Cyril Northcote Parkinson tarafından hazırlanan bu özel program, tamamen programlamayla ilgili olan ve 90-90 Yasası ile birlikte hareket eden daha geniş bir ilkedir: yapılacak iş elinizde bulunan zamanın tamamını yiyecek kadar uzar. Yazılım geliştirmede, "erken bitirme" gerçekten bir fantezidir.

Brook Yasası

Bu yasaya tam da denk gelen bir atasözüne sahibiz ancak onu burada yazmayacağım. Genel olarak yasa bir yazılım sürecine ne kadar çok insan gücü dahi olursa kodu yazma süresinin de o kadar artacağını söyler. Bu da herkesin aynı işle uğraşması olası bir krizin aşılması için gereken bürokratik zamanın uzaması ve daha fazla tartışma anlamına gelecektir şeklinde açıklanır.

Kaynak : https://webrazzi.com/2018/01/25/duymamis-olabileceginiz-absurt-programlama-ilkeleri/
22
6
5
2
0
Emoji İle Tepki Ver
22
6
5
2
0