Yazılım Mühendisliği Kanunları
Yazılım sistemlerini, ekiplerini ve mimari kararlarımızı şekillendiren en kritik prensiplerin kısa özetleri ve detaylı örnekleri.
Aşağıdaki kategorilerden projenizin aşamasına uygun olan kanunu seçerek, detaylı inceleme ve kod örneklerine ulaşabilirsiniz.
Ekipler (Teams) ve Organizasyon
Conway Kanunu
Organizasyonlar, kendi iletişim yapılarını kopyalayan sistemler tasarlarlar. Sistem mimariniz şirket içi iletişimin bir aynası olur.
Brooks Kanunu
Gecikmiş bir yazılım projesine insan gücü eklemek, projeyi daha da geciktirir.
Dunbar Sayısı
Bir insanın sürdürebileceği istikrarlı sosyal ilişki sayısının sınırı 150'dir. Ekipler büyüdükçe iletişim çöker.
Ringelmann Etkisi
Bir gruba katılan insan sayısı arttıkça, bireylerin gruba sağladığı üretkenlik eforu azalır (Sosyal Kaytarma).
Price Kanunu
Bir projede işin yarısını (%50'sini), toplam çalışan sayısının sadece karekökü kadar kişi yapar.
Putt Kanunu
Teknolojiyi anlayanlar onu yönetemezler, teknoloji yönetiminde olanlar ise onu anlamazlar.
Peter Prensibi
Bir şirkette her çalışan, artık işini iyi yapamayacağı (yetersiz kalacağı) bir pozisyona kadar terfi etme eğilimindedir.
Otobüs Faktörü (Bus Factor)
Projeyi çökertecek kadar kritik bilgiye tek başına sahip olan minimum kişi sayısıdır. Bilgiyi paylaşın.
Dilbert Prensibi
Şirketler üretimi bozmamak için vasıfsız çalışanları sistemden atmak yerine üst yönetime terfi ettirirler.
Planlama (Planning) ve Zaman Yönetimi
Erken Optimizasyon
Erken optimizasyon her türlü kötülüğün anasıdır. Henüz ölçüm yapmadan kodu hızlandırmaya çalışmayın.
Parkinson Kanunu
Bir iş, tamamlanması için ayrılan zamanı dolduracak kadar genişler. Süreyi kısıtlamak işi hızlandırır.
Doksan-Doksan Kuralı
Kodun ilk %90'ı zamanın %90'ını alır. Kalan "ufak detay" %10 ise sürenin DİĞER %90'ını alır.
Hofstadter Kanunu
Bir işin ne kadar süreceğini doğru tahmin etmek imkansızdır, Hofstadter kuralını hesaba katsanız bile gecikir.
Goodhart Kanunu
Bir metrik veya ölçüm ana hedef haline geldiğinde, iyi bir metrik olmaktan çıkar.
Gilb Kanunu
Sistemde ölçülmesi gereken her şey bir şekilde ölçülebilir, yeter ki gözlemlemeye çalışın.
Kalite (Quality) ve Hata Ayıklama
İzcilik Kuralı (Boy Scout Rule)
Kodu, ilk bulduğunuzdan biraz daha iyi durumda bırakın. Sistemin zamanla çürümesini engeller.
Murphy Kanunu
Ters gidebilecek her şey, bir gün mutlaka ters gidecektir.
Postel Kanunu (Sağlamlık Prensibi)
Kendi çıktılarınızda çok katı kurallara uyun, başkalarından gelen girdileri kabul ederken esnek olun.
Kırık Camlar Teorisi
Kötü kod, kötü tasarımı cesaretlendirir. Sistemdeki küçük bozulmaları anında onarmalısınız.
Teknik Borç (Technical Debt)
Zaman kazanmak için yazılan kötü kodlar kredi çekmek gibidir. Hızla geri ödenmezse faiziyle geliştirme hızınızı bitirir.
Linus Kanunu
Yeterince göz (geliştirici incelemesi) olduğu sürece, hiçbir yazılım hatası gizli kalamaz.
Kernighan Kanunu
Hata ayıklamak, kodu yazmaktan iki kat daha zordur. Kod yazarken aşırı zekice davranırsanız, o hatayı bulacak zekanız kalmaz.
Test Piramidi
Projelerde çok fazla hızlı birim(unit) testi, az sayıda arayüz(UI) testi bulunmalıdır.
Pestisit Paradoksu
Aynı testleri tekrar tekrar çalıştırırsanız, bir süre sonra sistemdeki yeni hataları bulamaz hale gelirler.
Sturgeon Kanunu
Her şeyin (ve piyasadaki yazılımların, framework'lerin) %90'ı çöptür.
Lehman'ın Yazılım Evrim Kanunları
Kullanılan bir yazılım sürekli değişime ayak uydurmak zorundadır, aksi halde eskir.
Mimari (Architecture) ve Ölçeklenebilirlik
Hyrum Kanunu
Yeterince kullanıcıya sahip bir API'nin, dokümante edilmemiş tüm rastgele davranışlarına bile bağımlı hale gelen birileri olacaktır.
Gall Kanunu
Çalışan karmaşık bir sistem, daima daha önce çalışan basit bir sistemden evrilmiştir. Karmaşık sistemler sıfırdan yaratılamaz.
Sızdıran Soyutlamalar (Leaky Abstractions)
Araçlar ve frameworkler hayatı kolaylaştırsa da, er ya da geç altındaki sistemin karmaşıklığını ve sorunlarını dışarı sızdırır.
Tesler Kanunu (Karmaşıklığın Korunumu)
Her uygulamanın ortadan kaldırılamayan sabit bir karmaşıklığı vardır. Sadece kimin (kullanıcı veya geliştirici) uğraşacağı seçilebilir.
CAP Teoremi
Dağıtık bir sistem Tutarlılık, Erişilebilirlik ve Bölünme Toleransından aynı anda sadece ikisini garanti edebilir.
İkinci Sistem Etkisi (Second-System Effect)
Küçük ve başarılı ilk sistemlerin ardından gelen "versiyon 2.0" projeleri genellikle aşırı mühendislik ve şişkinlik kurbanı olur.
Dağıtık Bilişim Yanılgıları
Yazılımcıların ağ üzerinden çalışan sistemler tasarlarken düştüğü 8 ölümcül varsayım.
Beklenmeyen Sonuçlar Kanunu
Karmaşık bir sistemi herhangi bir yerinden değiştirdiğinizde, hiç ummadığınız bir yerinde sürpriz arızalar çıkacaktır.
Zawinski Kanunu
Her başarılı program, e-posta/mesaj okuyabilene kadar özelliklerle şişirilme eğilimi gösterir.
Amdahl Kanunu
Sistemi ne kadar paralelleştirirseniz (thread, cpu) paralelleştirin, performans kazancı paralel yapılamayan dar boğaza takılır.
Gustafson Kanunu
Paralel CPU'lar eklendikçe, kodun çalışma süresi kısalmaz ama çözülen işin veri büyüklüğü devasa oranda artar.
Metcalfe Kanunu
Bir ağın veya sosyal medyanın değeri, kullanıcı sayısının karesi ile orantılı olarak artar.
Geliştirme Prensibi ve Karar Süreçleri
YAGNI (You Aren't Gonna Need It)
İhtiyacınız olana kadar sisteme yeni özellik eklemeyin. Varsayımlar üzerine kod yazmak teknik borcu artırır.
DRY (Don't Repeat Yourself)
Sistemdeki her bilgi parçasının veya iş mantığının tek ve kesin bir temsili olmalıdır. Kod kopyalamak bug'lara yol açar.
KISS (Keep It Simple, Stupid)
Tasarımınızı ve kodunuzu okuması mümkün olduğunca basit tutun. Karmaşıklıktan kaçının.
SOLID Prensipleri
Nesne Yönelimli Programlamanın (OOP) sürdürülebilir ve esnek olması için gereken 5 altın kural.
Demeter Kanunu
En Az Bilgi prensibi. Bir nesne yalnızca yakın arkadaşlarıyla konuşmalı, onların da altındaki nesnelere erişmemelidir.
En Az Şaşkınlık Prensibi
Yazılım arayüzleri, kullanıcıları (veya diğer geliştiricileri) en az şaşırtacak şekilde standart ve öngörülebilir olmalıdır.
Dunning-Kruger Etkisi
Bir konu hakkında ne kadar az şey bilirseniz, o konuda kendinize o kadar gereksiz ve tehlikeli bir güven duyarsınız.
Hanlon'un Usturası
Yetersizlik veya aptallıkla açıklanabilen hataları asla kötü niyete veya komploya yormayın.
Ockham'ın Usturası (Occam's Razor)
Birden fazla teori veya çözüm varsa, en az varsayım içeren (en basit olanı) genellikle doğru olandır.
Batık Maliyet Yanılgısı
Zaman veya para harcadığınız için yanlış bir kararda/mimaride ısrar etmeye devam etmek.
Harita Arazinin Kendisi Değildir
Mimariler, diyagramlar ve planlar gerçeği temsil eder ama gerçeğin (production) karmaşıklığını asla barındıramazlar.
Onaylama Sapması (Confirmation Bias)
Mevcut inançlarımızı veya kararlarımızı destekleyen verileri görüp, onlara ters düşen verileri yok sayma eğilimi.
Hype Döngüsü ve Amara Kanunu
Teknolojilerin kısa vadeli etkilerini inanılmaz abartırız, ancak uzun vadedeki devrimsel etkilerini küçümseriz.
Lindy Etkisi
Bir teknoloji ne kadar eskiyse, gelecekte de o kadar uzun süre kullanılmaya ve var olmaya devam edecektir.
İlk Prensipler Düşüncesi (First Principles)
Karmaşık bir problemi tamamen parçalarına ayırıp temel varsayımlardan sıfırdan düşünerek çözmek.
Tersine Çevirme (Inversion)
Bir problemi çözemiyorsanız, problemin tam tersini düşünün. "Nasıl başarılı oluruz?" yerine "Nasıl kesin batarız?" diye sorun.
Pareto Prensibi (80/20)
Problemlerin, özelliklerin veya sonuçların %80'i, eforun veya kodun %20'sinden kaynaklanır.
Cunningham Kanunu
İnternette en iyi doğru cevabı bulmanın yolu soru sormak değil, bilerek çok yanlış bir cevap yazmaktır.
Detayları Oku →💡 İpucu: Bu kanunlar yazılım mühendisliği boyunca teknik sorunlardan daha fazla insanî (psikolojik) ve proje planlama bazlı sorunları gözetmemiz gerektiğini tecrübe ile ortaya koymuştur. Yazılımlar cihazlarda yaşar ama insanlar tarafından insanlara hizmet etmek için var edilir.