Merih Forum Programlama ve yazılım algoritmalar Genel Muhtemelen Daha Önce Hiç Duymadığınız Tuhaf Programlama İlkeleri

ABD Münbiçi bırakır mı ?

ABD, Münbiçin yarısı sizde yarısı bizde kalsın dedi

SON 20 YILDA OSCAR KAZANAN KADINLAR

Son 20 yılda En İyi Kadın Oyuncu kategorisinde Oscar kazanan oyuncuların listesi...

AFRİN HAREKATI

Zeytin Dalı Harekatında teröristlerden temizlenen bölge artıyor

Silkroad XIAN

Silkroad sevdalıları için bir server

  • Toplam: 0 Oy - Ortalama: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Muhtemelen Daha Önce Hiç Duymadığınız Tuhaf Programlama İlkeleri

 
#1

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
7cca66d4ea4a8b72baa9f10f4579e7f98c542f4a.jpeg
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
7b04cf7414cd8b0b521b62c4a5a4f10eb892b9c8.jpeg
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
71ae4666d4ad4cb7fe2b4b6ee1e030f8390ce401.jpeg
“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ı
aab0e7bbe036145dcb093122f62dd94b7f33dfd4.jpeg
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
877bbd71b3d995fe4c8d0e59c97ae032a5aca331.jpeg
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ı
dea6f0e11fc16321d0dd948cbe535e99d53c37bd.jpeg
"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ı
52a6a092d7e56323a643b2bfccb6a8fa52c2d14f.jpeg
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ı
f80018c56bc1cb4d55bdd7fa04cd2f5aaadb23ce.png
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ı
34d45d8d958dc646cece9d6d184774c412edad10.jpeg
"İş, 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ı
727967365c78ee3a02a91d4ca5af38ffcbe004eb.jpeg
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.




Ara
Cevapla


[-]
Hızlı Cevap

İnsan Doğrulama:
Aşağıda görünen onay kutusunu işaretleyiniz. Bu işlem otomatik spam kayıtları önlemek için kullanılır.

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Konuyu Okuyanlar:
1 Ziyaretçi

   
Türkçe Çeviri: MCTR, Forum Yazılımı: MyBB, © 2002-2018 MyBB Group.  



Merih Forum® bilgi paylaşım platformu. 2015-2018 Tüm hakları saklıdır.