Yazılım Mühendisliğinin Yasaları
(lawsofsoftwareengineering.com)- Yazılım sistemlerini, ekipleri ve karar alma süreçlerini etkileyen 56 ilke ve kalıbı tek bir yerde toplayan bir derleme; ekip yönetiminden mimariye, kaliteden tasarıma ve karar almaya kadar geniş bir alanı kapsıyor
- Conway Yasası, Brooks Yasası, Dunbar sayısı gibi ekiple ilgili yasalar, organizasyon yapısının sistem tasarımı ve üretkenlik üzerinde doğrudan etkili olduğunu gösteriyor
- Mimari alanında Hyrum Yasası, CAP teoremi, Gall Yasası gibi karmaşık sistem tasarımında mutlaka dikkate alınması gereken kısıtlar ve ilkeler düzenleniyor
- Kaliteyle ilgili yasalar; teknik borç, test piramidi, Kernighan Yasası gibi konular üzerinden kod kalitesini korumanın ve hata ayıklamanın pratik zorluklarını ele alıyor
- Karar alma alanında ise Dunning-Kruger etkisi, batık maliyet yanılgısı, Pareto ilkesi gibi geliştirme sürecinde sıkça karşılaşılan bilişsel önyargıları ve değerlendirme ölçütlerini kapsıyor
Ekipler (Teams)
1. Conway Yasası (Conway's Law)
> Organizasyonlar, kendi iletişim yapılarını yansıtan sistemler tasarlar
- Yazılım mimarisinin, onu oluşturan organizasyonun iletişim yapısını doğal olarak takip etmesi olgusu
- Ekip 3 parçaya bölünmüşse sistemin de 3 büyük modüle ayrılma eğilimi vardır
- Bunun tersinden yararlanan "Ters Conway stratejisi" (Inverse Conway Maneuver) de vardır: istenen mimariye göre önce ekip yapısını yeniden düzenleme yaklaşımı
- Mikroservis benimserken ekip sınırlarıyla servis sınırlarını hizalamak etkilidir
2. Brooks Yasası (Brooks's Law)
> Gecikmiş bir yazılım projesine insan eklemek, projeyi daha da geciktirir
- Yeni kişiler ekibe katıldığında mevcut ekip üyeleri eğitim ve koordinasyona zaman harcar, bu da toplam üretkenliği geçici olarak düşürür
- Ekip büyüdükçe iletişim yolları geometrik olarak artar (n kişi olduğunda n(n-1)/2 adet)
- Frederick Brooks, bunu IBM OS/360 projesindeki deneyimine dayanarak 1975 tarihli The Mythical Man-Month kitabında formüle etti
- Little Yasası (L = λ × W) ile nicel olarak açıklanabilir: personel eklendiğinde WIP (devam eden iş) artar, ancak throughput durağan kaldığı için lead time aksine uzar
- Çözüm, insan eklemek değil kapsamı ayarlamak veya takvimi değiştirmektir
3. Dunbar Sayısı (Dunbar's Number)
> Bir insanın istikrarlı biçimde sürdürebileceği ilişkilerin bilişsel sınırı yaklaşık 150 kişidir
- Robin Dunbar'ın, primat beyin büyüklüğü ile sosyal grup boyutu arasındaki korelasyondan çıkardığı sayı
- Dunbar'ın sosyal katman yapısı: ~5 kişi (yakın ilişkiler), ~15 kişi (güvenilir iş birlikçileri), ~50 kişi (yakın iş ilişkileri), ~150 kişi (istikrarlı sosyal bağlantılar)
- Mühendislik organizasyonu 150 kişiyi aştığında gayriresmî iletişim sınırına ulaşılır ve resmî hiyerarşi ile süreçler gerekir
- Amazon'un "Two-Pizza Team" yaklaşımı (5~10 kişi), 150 kişinin altında bile fiilî iş birliğinin daha küçük birimlerde gerçekleştiğini yansıtır
4. Ringelmann Etkisi (The Ringelmann Effect)
> Grubun boyutu büyüdükçe bireysel üretkenlik azalır
- Grup üyelerinin sayısı arttıkça her bireyin katkısının azalmasına yol açan "sosyal kaytarma" (social loafing) olgusu
- Yazılım ekiplerinde de ekip büyüdükçe bireysel sorumluluk duygusu zayıflar ve koordinasyon maliyeti artar
- Küçük ekiplerin kişi başına neden daha yüksek çıktı ürettiğini açıklar
5. Price Yasası (Price's Law)
> Katılımcıların toplam sayısının karekökü kadar kişi, toplam işin %50'sini yapar
- 100 kişilik bir organizasyonda yaklaşık 10 kişi toplam işin yarısını üstlenir
- Organizasyon büyüdükçe az sayıdaki yüksek performanslı kişiye bağımlılık artar
- Ekip büyütüldüğünde üretkenliğin neden doğrusal artmadığını açıklar
6. Putt Yasası (Putt's Law)
> Teknolojiyi anlayanlar yönetmez, yönetenler de teknolojiyi anlamaz
- Teknik organizasyonlarda yönetim rolü ile teknik uzmanlık arasındaki kopukluğu hicivli biçimde ifade eder
- Teknik liderlik yapısı tasarlanırken bu boşluğun farkında olunmalı ve telafi mekanizmaları kurulmalıdır
7. Peter İlkesi (Peter Principle)
> Organizasyonlarda her çalışan, kendi yetersizlik düzeyine kadar terfi etme eğilimindedir
- Belirli bir rolde yetkin olan kişinin terfi ettikten sonra yeni rolünde yetersiz hale gelmesi örüntüsü
- Harika bir geliştiricinin mutlaka iyi bir yönetici olmayabileceği gerçeğini yansıtır
- IC (Individual Contributor) hattı ile yönetim hattını ayıran çift kariyer basamağı sistemine duyulan ihtiyaç
8. Bus Factor
> Bir projenin ciddi risk altına girmesine yol açabilecek en az ekip üyesi kaybı sayısı
- Bus Factor 1 ise tek hata noktası (Single Point of Failure) vardır
- Bilgi paylaşımı, pair programming ve dokümantasyon yoluyla Bus Factor'ı yükseltmek önemlidir
- Code review ve cross-training, Bus Factor'ı iyileştirmenin pratik yollarıdır
9. Dilbert İlkesi (Dilbert Principle)
> Şirketler, verecekleri zararı sınırlamak için yetersiz çalışanları yönetim pozisyonlarına terfi ettirme eğilimindedir
- Scott Adams'ın ortaya attığı hicivli bir gözlem olup Peter İlkesi'nin bir varyasyonudur
- Yönetim pozisyonunun, uygulamalı işte en az zarar verecek yer olarak görülmesine ilişkin paradoksal organizasyon olgusu
Planlama (Planning)
10. Erken optimizasyon / Knuth'un optimizasyon ilkesi (Premature Optimization)
> Erken optimizasyon bütün kötülüklerin kaynağıdır
- Donald Knuth'un 1974 tarihli makalesinde söylediği gibi: "Vakaların yaklaşık %97'sinde küçük verimlilikleri göz ardı etmeliyiz"
- Kodun yaklaşık %20'si çalışma süresinin %80'ini tükettiği için, kalan %80'lik kodu optimize etmek israftır
- Doğru sıra şudur: Önce çalıştır → sonra doğru hale getir → gerekirse hızlandır
- Optimize edilmiş kod karmaşıklığı artırdığı için, profiling ile gerçek darboğazları doğruladıktan sonra uygulanmalıdır
11. Parkinson Yasası (Parkinson's Law)
> İş, kendisine ayrılan sürenin tamamını dolduracak şekilde genişler
- Son tarih 2 haftaysa iş 2 haftaya, 4 haftaysa 4 haftaya yayılır
- Yazılım projelerinde kısa ve net kilometre taşları belirlemenin neden önemli olduğunu gösterir
- Sprint tabanlı çevik yaklaşım, bu yasaya karşı pratik bir yanıttır
12. 90-90 Yasası (The Ninety-Ninety Rule)
> Kodun ilk %90'ı geliştirme süresinin %90'ını alır, kalan %10 da bir başka %90'lık süreyi alır
- Yazılım projelerinde son %10'unun (edge case'ler, polish, bug fix) beklenenden çok daha uzun sürebileceği konusunda uyarır
- "Neredeyse bitti" ifadesi, gerçekte toplam takvimin yarısı anlamına gelebilir
13. Hofstadter Yasası (Hofstadter's Law)
> Hofstadter Yasası hesaba katılsa bile işler her zaman beklenenden daha uzun sürer
- Özyinelemeli öz gönderim yapısına sahip bir yasa olarak, yazılım takvimi tahmininin özündeki zorluğu ifade eder
- Tampon süre eklense bile takvimin yine aşılması gerçeği
- Douglas Hofstadter tarafından 1979 tarihli Gödel, Escher, Bach kitabında tanıtıldı
14. Goodhart Yasası (Goodhart's Law)
> Bir ölçüm metriği hedefe dönüştüğünde artık iyi bir ölçüm metriği olmaktan çıkar
- Kod kapsamını KPI yapmak, anlamlı olmayan testlerin çoğalmasına yol açmasıyla tipik bir örnektir
- Kod satırı sayısı (LOC) ile üretkenlik ölçülürse gereksiz yere uzun kod üretilir
- Metrikleri optimize etmeye değil, özdeki değeri gerçekleştirmeye odaklanmak gerekir
15. Gilb Yasası (Gilb's Law)
> Nicelleştirilmesi gereken bir şeyi hiç ölçmemektense, bir şekilde ölçmek daha iyidir
- Mükemmel ölçüm mümkün olmasa bile kabaca ölçüm yapmak, hiç ölçmemekten her zaman daha faydalıdır
- Yazılım kalitesi, kullanıcı memnuniyeti gibi nicelleştirilmesi zor alanlara da uygulanabilir
Mimari (Architecture)
16. Hyrum Yasası (Hyrum's Law)
> Bir API'nin yeterince çok kullanıcısı varsa, sistemin gözlemlenebilir her davranışına birileri bağımlı hale gelir
- Resmî API spesifikasyonunun yanı sıra zamanlama, hata mesajı biçimi, sıralama düzeni gibi gayriresmî davranışlar da bağımlılık hâline gelir
- Microsoft Windows’un, geçmişte belgelenmemiş davranışlara ve hatalara dayanan üçüncü taraf uygulamalarla uyumluluğu korumak için eski sürüm davranışlarını sürdürdüğü örnekler
- Google’dan Hyrum Wright’ın, 2011-2012 civarında Google içi kütüphane değişiklikleri deneyimlerinden yola çıkarak gözlemlediği durum
- Çalışma arkadaşı Titus Winters buna "Hyrum Yasası" adını verdi (Software Engineering at Google içinde yer alır)
- Fiilî sözleşme, resmî API değil, fiilen gözlemlenen davranışların tamamıdır
17. Gall Yasası (Gall's Law)
> Çalışan karmaşık bir sistem, mutlaka çalışan basit bir sistemden evrilmiştir
- Karmaşık bir sistemi en baştan tasarlamaya çalışırsanız, doğrulanmamış bilinmeyen değişken sayısı çok fazla olacağından başarısızlık olasılığı yükselir
- MVP (Minimum Viable Product) yaklaşımının teorik dayanağı
- Facebook’un 2004’te Harvard öğrencilerine yönelik basit bir profil sistemi olarak başlayıp kademeli biçimde büyümesi
- Mikroservislere geçişte de monolitten başlayıp aşamalı olarak ayırmak daha avantajlıdır
- John Gall tarafından 1975 tarihli Systemantics kitabında ortaya kondu (30 yayınevinin reddinden sonra yayımlanan bir kült klasik)
18. Sızdıran Soyutlamalar Yasası (The Law of Leaky Abstractions)
> Önemsiz olmayan her soyutlama, bir dereceye kadar sızıntı yapar
- ORM, SQL’i gizler; ancak performans sorunu çıktığında sonunda üretilen sorguları kontrol etmek zorunda kalmanız bunun tipik örneğidir
- Java/Python’daki çöp toplama da bir soyutlamadır; ancak GC duraklamaları gibi iç davranışlar performansı etkiler
- Buradaki ders, soyutlamanın kötü olduğu değil, soyutlama bozulduğunda ne yapılacağını önden düşünmek gerektiğidir
- Joel Spolsky bunu 2002 tarihli blog yazısında TCP, sanal bellek gibi örneklerle birlikte anlattı
- George Box’ın "Bütün modeller yanlıştır, ama bazıları faydalıdır" sözüyle de bağlam olarak ilişkilidir
19. Tesler Yasası / Karmaşıklığın Korunumu Yasası (Tesler's Law)
> Her uygulamanın kaldırılamayan kendine özgü bir karmaşıklığı vardır; bu karmaşıklık ancak taşınabilir, yok edilemez
- Temel soru şudur: Karmaşıklığı kim üstlenecek (kullanıcı mı, sistem mi)?
- Calendly, takvim koordinasyonunun karmaşıklığını sistem içinde emer; e-posta zincirleri ise bunu kullanıcıya yükler
- İyi tasarım, karmaşıklığı kullanıcı deneyiminden sistemin içine taşır
- Larry Tesler bunu 1980’lerde Apple Lisa ve erken GUI çalışmaları sırasında formüle etti
20. CAP Teoremi (CAP Theorem)
> Dağıtık sistemler, tutarlılık (C), erişilebilirlik (A) ve bölüm toleransı (P) arasından yalnızca ikisini garanti edebilir
- Ağ bölünmeleri gerçek dünyada kaçınılmaz olduğundan, pratikteki seçim tutarlılık ile erişilebilirlik arasındadır
- CP sistemleri (ör. MongoDB): Bölünme sırasında yazmayı engelleyerek tüm replikaların senkron kalmasını sağlar
- AP sistemleri (ör. Cassandra, DNS): Bölünme sırasında da isteklere yanıt vermeyi sürdürür, replikalar arasında geçici tutarsızlığa izin verir
- Eric Brewer tarafından 2000’de web servisleri bağlamında öne sürüldü; Gilbert & Lynch ise 2002’de resmî ispatını yaptı
21. İkinci Sistem Etkisi (Second-System Effect)
> Küçük ve başarılı bir sistemin ardından, aşırı tasarlanmış ve şişkin bir ikinci sistem gelme eğilimi vardır
- İlk sistemin başarısı özgüven yaratır ve ikinci sisteme bütün fikirleri doldurma eğilimine yol açar
- Özellik şişmesi (feature creep) ve aşırı genelleme (over-generalization) başlıca nedenlerdir
- Frederick Brooks bunu The Mythical Man-Month’ta tanımladı
22. Dağıtık Hesaplamanın Yanılgıları (Fallacies of Distributed Computing)
> Dağıtık sistemleri ilk kez tasarlayanların sıkça yaptığı 8 yanlış varsayım
- Bu 8 yanılgı şunlardır: (1) ağ güvenilirdir, (2) gecikme 0’dır, (3) bant genişliği sonsuzdur, (4) ağ güvenlidir, (5) topoloji değişmez, (6) tek bir yönetici vardır, (7) taşıma maliyeti 0’dır, (8) ağ homojendir
- Tasarım bu varsayımlar üzerine kurulduğunda, prodüksiyonda beklenmedik arızalar ve performans sorunları ortaya çıkar
23. İstenmeyen Sonuçlar Yasası (Law of Unintended Consequences)
> Karmaşık bir sistemi değiştirdiğinizde, beklenmedik sonuçları da hesaba katmalısınız
- Sistemin tek bir bileşenini değiştirmek, öngörülmeyen yerlerde yan etkilere yol açabilir
- Kaos mühendisliği ve kapsamlı test ihtiyacını destekleyen bir ilkedir
24. Zawinski Yasası (Zawinski's Law)
> Her program, e-posta okuyabilir hâle gelene kadar genişlemeye çalışır
- Yazılım başarılı oldukça, giderek daha fazla özellik ekleme eğilimini, yani özellik şişmesini (feature bloat) hicveder
- Bunu Jamie Zawinski (Netscape’in ilk geliştiricilerinden) gözlemledi
- Basit bir aracın zamanla her işi yapan bir platforma dönüşmeye çalışma eğilimine karşı uyarıdır
Kalite (Quality)
25. Boy Scout Kuralı (The Boy Scout Rule)
> Kodu, bulduğundan daha iyi durumda bırakmalısın
- Buradaki kilit nokta büyük çaplı refaktörler değil, sürekli ve kademeli iyileştirmedir
- Karışık fonksiyon adlarını düzeltmek, yinelenen kodu kaldırmak, eksik testler eklemek gibi her seferinde küçük iyileştirmeler yapmak gerekir
- Robert C. Martin (Uncle Bob), bunu Clean Code (2008) ile yazılım geliştirmeye uyarladı
- Google mühendislerinin "If you touch it, you own it" ilkesi — bir kodu değiştiriyorsan, onun kalitesinin sorumluluğunu da alırsın
- Bu kural uygulanırsa Kırık Camlar etkisi (Broken Windows) önlenir ve teknik borcun birikmesi engellenir
26. Murphy Yasası (Murphy's Law)
> Ters gidebilecek her şey, ters gider
- Savunmacı programlama, istisna yönetimi ve arızalara dayanıklı tasarım için temel dayanaklardan biridir
- Yazılımda, "olabilecek hata mutlaka olur" yaklaşımıyla hata işleme ve fallback mekanizmaları tasarlanmalıdır
27. Postel Yasası / Sağlamlık İlkesi (Postel's Law)
> Yaptığında tutucu ol, başkalarından aldığında cömert ol
- API tasarımında, çıktının spesifikasyona sıkı sıkıya uyması, buna karşılık girdinin farklı biçimlerini esnek biçimde kabul etmesi gerektiğini söyler
- Jon Postel’in TCP/IP protokollerini tasarlarken ortaya koyduğu sağlamlık ilkesi (Robustness Principle)
- Sistemler arası birlikte çalışabilirliği artıran pratik bir kılavuzdur
28. Kırık Camlar Teorisi (Broken Windows Theory)
> Kötü tasarımı, yanlış kararları ve düşük kaliteli kodu olduğu gibi bırakma
- Tek bir "kırık cam"ın (kötü kodun) bırakılması, ek kalite düşüşlerini tetikler
- Kod tabanında TODO yorumları, ölü kod ve çözülmemiş uyarılar birikirse, yeni kod da daha düşük standartta yazılma eğilimine girer
- Küçük sorunların bile fark edilir edilmez düzeltilmesi kültürü önemlidir
29. Teknik Borç (Technical Debt)
> Yazılım geliştirme hızını düşüren her türlü unsur
- Ward Cunningham bu finans metaforunu 1992’de OOPSLA’da ilk kez kullandı: Kodda kestirme yola başvurmak, gelecekten zaman ödünç almak gibidir
- Anapara (düzeltme maliyeti) + faiz (dağınık kodun yol açtığı kalıcı verimlilik kaybı)
- Kasıtlı teknik borç bazen mantıklı olabilir (pazara çıkış zamanı, prototipleme), ancak geri ödeme planı şarttır
- Bunun tipik örneklerinden biri otomatik testleri atlamaktır: Sürüm başarıyla çıkar, ama sonraki her değişiklikte beklenmedik hatalar oluşur
- Çözüm yolları: refaktöring, eksik testleri ekleme, tasarımı iyileştirme
30. Linus Yasası (Linus's Law)
> Yeterince çok gözden geçiren varsa, bütün hatalar kolayca bulunur
- Açık kaynak geliştirmenin temel ilkesi şudur: çok sayıda göz kodu inceliyorsa, hatalar önemsiz hâle gelir
- Eric Raymond bunu The Cathedral and the Bazaar’da Linus Torvalds’ın adından türeterek adlandırdı
- Kod inceleme kültürünün önemini destekler
31. Kernighan Yasası (Kernighan's Law)
> Debugging, kodu ilk yazmaktan iki kat daha zordur
- Bu nedenle, kodu ne kadar akıllıca yazarsanız, debug ederken o kadar yeterince akıllı olamazsınız
- Okunabilirliği yüksek, basit kod yazmak gerekmesinin nedeni
- Brian Kernighan tarafından The Elements of Programming Style içinde ortaya kondu
32. Test Piramidi (Testing Pyramid)
Bir proje çok sayıda hızlı unit test, daha az integration test ve yalnızca az sayıda UI testine sahip olmalıdır
- Unit testler (alt katman): hızlı ve düşük maliyetli, en fazla yazılması gereken testler
- Integration testler (orta katman): bileşenler arası etkileşimi doğrular
- UI/E2E testleri (üst katman): yavaş ve kırılgan oldukları için en aza indirilmelidir
- Mike Cohn'un Succeeding with Agile kitabında tanıttığı test stratejisi modeli
33. Pestisit Paradoksu (Pesticide Paradox)
Aynı testler tekrar tekrar çalıştırıldığında etkileri zamanla azalır
- Mevcut testler zaten yakalayabildikleri hataların hepsini yakaladığı için, yeni test case'leri sürekli eklemek gerekir
- Test setini düzenli olarak gözden geçirmek ve güncellemek zorunludur
34. Lehman'ın Yazılım Evrimi Yasaları (Lehman's Laws of Software Evolution)
Gerçek dünyayı yansıtan yazılım mutlaka evrilmelidir ve bu evrimin öngörülebilir sınırları vardır
- E-type (gerçek dünyayı yansıtan) yazılımın kullanılabilir kalması için sürekli değişmesi kaçınılmazdır
- Her değişiklikte karmaşıklık artar; bu durum aktif biçimde yönetilmezse kalite düşer
35. Sturgeon Yasası (Sturgeon's Law)
Her şeyin %90'ı işe yaramazdır
- Theodore Sturgeon tarafından SF edebiyat eleştirilerine yanıt olarak ortaya atıldı
- Yazılıma da uygulanır: kodların, araçların ve framework'lerin çoğu içinde gerçekten mükemmel olanlar azınlıktır
- Kalite için yüksek standartları korumak ve değerli olan %10'a odaklanmak gerekir
Ölçek (Scale)
36. Amdahl Yasası (Amdahl's Law)
Paralelleştirmeyle sağlanan hız artışı, paralelleştirilemeyen iş oranı tarafından sınırlanır
- Programın %5'i sıralıysa, ne kadar çok işlemci eklerseniz ekleyin teorik maksimum hızlanma 20 kat olur
- Paralelleştirmenin sınırlarını anlamak ve sıralı darboğazları azaltmak daha etkilidir
- Gene Amdahl tarafından 1967'de ortaya kondu
37. Gustafson Yasası (Gustafson's Law)
Problem boyutu artırılarak paralel işlemde önemli hız kazanımları elde edilebilir
- Amdahl Yasası'na tamamlayıcı bir bakış: sabit bir problem yerine ölçeklenebilir problemlerde işlemci eklemek etkilidir
- Büyük veri işleme, bilimsel simülasyonlar gibi alanlarda daha fazla kaynakla daha büyük problemler çözülebilir
38. Metcalfe Yasası (Metcalfe's Law)
Bir ağın değeri, kullanıcı sayısının karesiyle orantılıdır
- Kullanıcı sayısı 10 ise değer 100 birim, 100 ise 10.000 birime çıkar
- Sosyal ağlar, mesajlaşma uygulamaları, marketplace'ler gibi alanlarda network effect için teorik temel sağlar
- Robert Metcalfe tarafından Ethernet teknolojisinin değerini açıklamak için ortaya atıldı
Tasarım (Design)
39. DRY İlkesi (Don't Repeat Yourself)
Her bilgi, tekil, açık ve yetkili bir ifadeye sahip olmalıdır
- Yalnızca kod tekrarını değil, bilgi, mantık ve veri tekrarını da kapsar
- Tekrar, değişiklik sırasında birden çok yerin aynı anda düzeltilmesini gerektirdiği için bug ve tutarsızlıkların nedenidir
- Andy Hunt ve Dave Thomas tarafından The Pragmatic Programmer içinde formüle edildi
40. KISS İlkesi (Keep It Simple, Stupid)
Tasarım ve sistemler mümkün olduğunca basit olmalıdır
- Karmaşıklık; anlama, bakım ve debug maliyetini artırır
- Basit çözümler çoğu durumda daha etkilidir ve hata olasılığı da daha düşüktür
- Kökeni, ABD Donanması'nın 1960'larda ortaya koyduğu tasarım ilkesine dayanır
41. SOLID İlkeleri (SOLID Principles)
Yazılım tasarımını iyileştiren 5 temel kılavuz ilke
- S — Tek Sorumluluk İlkesi (Single Responsibility): Bir sınıf yalnızca tek bir nedenle değişmelidir
- O — Açık-Kapalı İlkesi (Open-Closed): Genişletmeye açık, değiştirmeye kapalı olmalıdır
- L — Liskov Yerine Geçme İlkesi: Alt tipler, üst tiplerin yerine geçebilmelidir
- I — Arayüz Ayrımı İlkesi: Client'lar kullanmadıkları arayüzlere bağımlı olmamalıdır
- D — Bağımlılıkların Tersine Çevrilmesi İlkesi: Üst modüller alt modüllere değil, soyutlamalara bağımlı olmalıdır
- Robert C. Martin tarafından formüle edildi, SOLID kısaltması ise Michael Feathers tarafından adlandırıldı
42. Demeter Yasası (Law of Demeter)
Nesneler yalnızca doğrudan arkadaşlarıyla etkileşime girmeli, yabancı nesnelerle doğrudan iletişimden kaçınmalıdır
a.getB().getC().doSomething()gibi zincir çağrıların kaçınılması gerektiğini söyler- Bağlılığı azaltır, encapsulation'ı güçlendirir ve değişikliklerin etki alanını daraltır
- "En az bilgi ilkesi" olarak da bilinir
43. En Az Şaşırtma İlkesi (Principle of Least Astonishment)
Yazılım ve arayüzler, kullanıcıları ve diğer geliştiricileri en az şaşırtacak şekilde çalışmalıdır
- Fonksiyonlar, API'ler ve UI; adlandırma ve konvansiyonlar açısından öngörülebilir davranış sergilemelidir
delete()fonksiyonu gerçekte sadece arşivleme yapıyorsa şaşkınlık yaratır → bu bir tasarım kusurudur- Sezgisel olmayan davranışlar bug'lara ve kullanıcı hatalarına yol açar
44. YAGNI (You Aren't Gonna Need It)
Gerekmeyene kadar özellik ekleme
- Extreme Programming (XP)'in temel ilkelerinden biridir; 1990'ların sonlarında Ron Jeffries tarafından ortaya kondu
- "Gelecekte gerekebilir" diye kod yazmak aşırı tasarıma ve bakım yüküne yol açar
- YAGNI'yi uygulayabilmek için refactoring konusunda özgüven (iyi test kapsamı, CI) gerekir
- Şu anda yalnızca JSON export gerekiyorsa sadece JSON'u uygulayın; XML/YAML vb. ise talep geldiğinde ekleyin
Karar Verme (Decisions)
45. Dunning-Kruger Etkisi (Dunning-Kruger Effect)
Bir şey hakkında ne kadar az bilirseniz, o kadar fazla özgüven taşıma eğiliminde olursunuz
- Acemi geliştiricilerin karmaşık sistemlerin zorluğunu küçümsemesi ya da uzmanların kendi bilgilerine karşı daha alçakgönüllü olması gibi durumlar
- Code review, mentorluk ve sürekli öğrenme yoluyla öz farkındalık doğruluğunu artırmak önemlidir
46. Hanlon'un Usturası (Hanlon's Razor)
Aptallık ya da dikkatsizlikle yeterince açıklanabilen bir şeyi kötü niyete bağlamayın
- Bir ekip arkadaşının kötü kodunu ya da yanlış kararını kasıtlı sabotaj olarak yorumlamadan önce bilgisizlik, hata ve zaman yetersizliğini düşünmek gerekir
- Ekip içi güvenin ve yapıcı iletişimin temelidir
47. Occam'ın Usturası (Occam's Razor)
En basit açıklama çoğu zaman en doğru olandır
- Debug sırasında karmaşık nedenlerden önce en basit olasılığı kontrol edin
- Mimari tasarımda da gereksiz soyutlama katmanları eklemeden önce basit çözümleri önce değerlendirin
48. Batık Maliyet Yanılgısı (Sunk Cost Fallacy)
Sırf zaman ya da enerji harcandığı için zarar ettiren bir seçimi sürdürme eğilimi
- 6 ay geliştirilen bir özellik yanlış yönde olsa bile harcanan zaman yüzünden ondan vazgeçememe psikolojisi
- Doğru karar, geçmiş yatırımlara değil gelecekteki değere göre verilmelidir
49. Harita Bölgenin Kendisi Değildir (The Map Is Not the Territory)
Gerçekliğin temsili olan bir model, gerçekliğin kendisiyle aynı değildir
- UML diyagramları, mimari dokümanlar, veri modelleri vb. yalnızca gerçekliğin yaklaşık temsilleridir
- Modele körü körüne güvenmeyin; gerçek sistem davranışını gözlemleyip modeli güncelleyin
50. Doğrulama Yanlılığı (Confirmation Bias)
Mevcut inançları ya da fikirleri destekleyen bilgileri tercih etme eğilimi
- Seçtiğiniz teknoloji stack'i ya da tasarım kararı lehine olan bilgileri seçici biçimde toplama tuzağı
- Karşıt kanıtları aktif olarak aramak ve farklı bakış açılarını kabul etmek, dengeli karar vermenin anahtarıdır
51. Hype Cycle ve Amara Yasası (The Hype Cycle & Amara's Law)
Teknolojinin kısa vadeli etkileri abartılma, uzun vadeli etkileri ise küçümsenme eğilimindedir
- Gartner'ın Hype Cycle'ı: teknolojik tetikleyici → abartılı beklentilerin zirvesi → hayal kırıklığı çukuru → aydınlanma eğimi → üretkenlik platosu
- Yeni teknolojiler (blockchain, AI vb.) benimsenirken kısa vadeli aşırı heyecana kapılmadan uzun vadeli pratikliği değerlendirmek gerekir
52. Lindy etkisi (The Lindy Effect)
Bir şey ne kadar uzun süredir kullanılıyorsa, gelecekte de kullanılmaya devam etme olasılığı o kadar yüksektir
- UNIX, SQL ve C dili gibi on yıllardır kullanılan teknolojilerin gelecekte de uzun süre varlığını sürdürme olasılığı yüksektir
- Yeni framework'ler yerine kendini kanıtlamış teknolojileri seçmenin teorik gerekçesi
- Nassim Nicholas Taleb tarafından Antifragile'da popülerleştirildi
53. Birinci ilkeler düşüncesi (First Principles Thinking)
Karmaşık bir problemi en temel bileşenlerine ayırıp ardından oradan yeniden inşa eden düşünme yöntemi
- Mevcut pratikleri ve varsayımları kaldırıp temel gerçeklerden yola çıkarak çözüm üretir
- Elon Musk'ın SpaceX roket maliyetlerini düşürmede uyguladığı örnekle bilinir
- Karmaşık sistemler tasarlanırken "zaten hep böyle yapılıyor" anlayışına karşı dikkatli olunmalı
54. Tersine düşünme (Inversion)
Zıt sonucu varsayıp tersten akıl yürüterek problemi çözme yöntemi
- "Nasıl başarılı oluruz" yerine önce "Nasıl başarısız oluruz" diye düşünerek risk unsurlarını belirlemek
- Failure Mode Analysis ve Pre-mortem için teorik temel sağlar
- Charlie Munger'ın sık kullandığı zihinsel modellerden biridir
55. Pareto ilkesi / 80/20 kuralı (Pareto Principle)
Sorunların %80'i, nedenlerin %20'sinden kaynaklanır
- Tüm bug'ların %80'inin kodun %20'sinde yoğunlaşma eğilimi vardır
- Etkisi en yüksek %20'ye kaynak ayırmak, verimli bir kaynak dağıtımı stratejisidir
- Kökeni, Vilfredo Pareto'nun İtalya'daki arazi sahipliği dağılımında gözlemlediği ilkeye dayanır
56. Cunningham Yasası (Cunningham's Law)
İnternette doğru cevabı almanın en iyi yolu soru sormak değil, yanlış cevabı paylaşmaktır
- İnsanlar soruları yanıtlamaktan çok yanlış bilgiyi düzeltmeye daha aktif katılır
- Wiki'nin mucidi Ward Cunningham'ın adını taşır, ancak bu adı aslında Steven McGeady vermiştir
- Açık kaynak topluluklarında dokümantasyon ve bilgi paylaşımı için kullanılabilecek bir içgörü
2 yorum
vibe codingyapınca kısa vadede iyi geliyor ama sonunda dönüp dolaşıp bedeli size çıkıyor gibi görünüyor...Hacker News görüşleri
Ben özellikle "erken optimizasyon tüm kötülüklerin kaynağıdır" sözünden nefret ediyorum. Bu cümle 1974 bağlamında söylenmişti, dolayısıyla bugünkünden farklı varsayımlara dayanıyordu. O zamanlar optimizasyon assembly ve çevrim hesabına daha yakındı, ama bugün performans çoğunlukla mimari seçim meselesi ve en baştan düşünülmesi gerekiyor. Profiling ile tesadüfi O(n²) gibi performans hatalarını yakalama tavsiyesi hâlâ geçerli, ancak soyutlama maliyeti darboğaz hâline geldikten sonra üzerine sadece cache ve paralellik eklemek sistemi daha karmaşık ve daha yavaş yapmaya çok açık. Bugün geç optimizasyonun da erken optimizasyon kadar, hatta belki daha kötü olduğunu düşünüyorum
Curly's Law'ın eksik olmasına üzüldüm. Bir değişkenin yalnızca tek bir anlamı olmalı; bağlama göre başka domain'lerden değer taşımamalı ya da aynı anda iki rol üstlenmemeli. "Hem zemin cilası hem tatlı sosu" gibi bir duruma düşmemesi gerektiği benzetmesi tam oturuyor
Bu tür yazılım "yasalarını" bir araya koyunca aralarında o kadar çok iç çelişki görüyorum ki, sonunda kendi tezini meşrulaştıran bir cümleyi seçip kullanmak çok kolaylaşıyor. Asıl zor olan, hangi durumda hangi yasayı bozacağını ve neden bozduğunu bilmektir
2026 sürümü yazılım mühendisliği yasası olarak, tüm web sitelerinin Claude Opus ile vibe coding yapılarak üretileceği diye şaka yapmak istiyorum. Sonuç olarak arka plan rengi Anthropic'i andıran krem tonlarına dönecek, fontlar ve kalınlıklar tasarıma yeni girişen birinin tipografiyi yeni öğrenmiş gibi aşırı karışacak, card UI her yeri kaplayacak ve kartların yalnızca bir kenarında yuvarlatılmış renkli kenarlıklar gibi kalıplar tekrar edecek
Boyd's Law of Iteration'ın da eklenmesi gerektiğini düşünüyorum. Karmaşıklıkla uğraşırken derin analizden ziyade hızlı iterasyonun daha iyi sonuç verdiğini söyleyen bir yasa; Boyd'un OODA loop'un mucidi olduğunu düşününce daha da etkileyici geliyor
Silinen yorumlar arasında bu yazı için en iyi meta yasanın olduğunu düşünüyorum. "Tüm yazılım mühendisliği yasaları anında yanlış anlaşılır ve ilk yazarını dehşete düşürecek şekilde sorgusuz uygulanır" diyordu; temel bağlamı kaçıran LLM davranışlarına bakınca bunun nedenini daha iyi anlıyorum. Sonuçta onlarca yıllık bilgelik ve deneyimi tek satırlık aforizmalara sıkıştırmanın sınırları var
"'Yazılım mühendisliğinin yasaları' listesi" sitesini baştan sona vibe coding ile yapacaklarına, neden doğrudan bir Wikipedia sayfası oluşturmadılar diye sormak istiyorum; bu da hangi yasayı çiğniyor acaba
Bunun gibi şeylerin işe alım şartı olacak kadar temel genel kültür olmasını isterdim. Herkesin bilmesi gereken şeyler gibi geliyor
Yazılıma özel bir yasa olmasa da Chesterton's Fence'i stajyerlere ve yeni başlayanlara ilk öğrettiğim şeylerden biri yapıyorum
Tesler'in karmaşıklığın korunumu yasası bana ifadenin kendisiyle doğrudan içgörü veriyor gibi geliyor. Her uygulamanın ortadan kaldırılamayan, yalnızca yeri değiştirilebilen kendine özgü bir karmaşıklığı olduğu söyleniyor. Ama açıklamaya girince bunun sonunda kullanıcıyı daha az uğraştırın gibi sıradan bir tavsiyeye indirgendiğini hissediyorum ve biraz daha az ilginç geliyor. Kullanıcı, gereken düzeyde karmaşıklığı eninde sonunda üstlenmek zorunda; bunu düşünmeden azaltırsanız sistem esnekliği olmayan bir oyuncağa dönüşebilir. Bu yüzden refactoring yaparken bir kısmı sadeleştirmenin başka bir kısmı daha karmaşık hâle getirebileceğini akılda tutmayı daha faydalı buluyorum