Yazılım Mühendisliği Kanunları CATEGORY All Architecture Teams Planning Quality Design TEAMS Conway Kanunu Organizasyonlar, kendi iletişim yapılarını kopyalayan sistemler tasarlarlar. Sistem mimariniz şirket içi iletişimin bir aynası olur. DESIGN 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. DESIGN 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. QUALITY Kırık Camlar Teorisi Kötü kod, kötü tasarımı cesaretlendirir. Sistemdeki küçük bozulmaları anında onarmalısınız. PLANNING 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. DESIGN SOLID Prensipleri Nesne Yönelimli Programlamanın (OOP) sürdürülebilir ve esnek olması için gereken 5 altın kural. TEAMS Brooks Kanunu Gecikmiş bir yazılım projesine insan gücü eklemek, projeyi daha da geciktirir. QUALITY 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. DESIGN 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. ARCHITECTURE CAP Teoremi Dağıtık bir sistem Tutarlılık, Erişilebilirlik ve Bölünme Toleransından aynı anda sadece ikisini garanti edebilir. DESIGN 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. PLANNING 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. ARCHITECTURE 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. DESIGN Pareto Prensibi (80/20) Problemlerin, özelliklerin veya sonuçların %80'i, eforun veya kodun %20'sinden kaynaklanır. QUALITY İzcilik Kuralı (Boy Scout Rule) Kodu, ilk bulduğunuzdan biraz daha iyi durumda bırakın. Sistemin zamanla çürümesini engeller. ARCHITECTURE 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. ARCHITECTURE 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. ARCHITECTURE 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. ARCHITECTURE İ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. ARCHITECTURE 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. ARCHITECTURE 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. ARCHITECTURE Zawinski Kanunu Her başarılı program, e-posta/mesaj okuyabilene kadar özelliklerle şişirilme eğilimi gösterir. TEAMS 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. TEAMS Ringelmann Etkisi Bir gruba katılan insan sayısı arttıkça, bireylerin gruba sağladığı üretkenlik eforu azalır (Sosyal Kaytarma). TEAMS 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. TEAMS Putt Kanunu Teknolojiyi anlayanlar onu yönetemezler, teknoloji yönetiminde olanlar ise onu anlamazlar. TEAMS Peter Prensibi Bir şirkette her çalışan, artık işini iyi yapamayacağı (yetersiz kalacağı) bir pozisyona kadar terfi etme eğilimindedir. TEAMS 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. TEAMS Dilbert Prensibi Şirketler üretimi bozmamak için vasıfsız çalışanları sistemden atmak yerine üst yönetime terfi ettirirler. PLANNING 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. PLANNING 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. PLANNING Goodhart Kanunu Bir metrik veya ölçüm ana hedef haline geldiğinde, iyi bir metrik olmaktan çıkar. PLANNING Gilb Kanunu Sistemde ölçülmesi gereken her şey bir şekilde ölçülebilir, yeter ki gözlemlemeye çalışın. QUALITY Murphy Kanunu Ters gidebilecek her şey, bir gün mutlaka ters gidecektir. QUALITY Postel Kanunu (Sağlamlık Prensibi) Kendi çıktılarınızda çok katı kurallara uyun, başkalarından gelen girdileri kabul ederken esnek olun. QUALITY Linus Kanunu Yeterince göz (geliştirici incelemesi) olduğu sürece, hiçbir yazılım hatası gizli kalamaz. QUALITY 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. QUALITY Test Piramidi Projelerde çok fazla hızlı birim(unit) testi, az sayıda arayüz(UI) testi bulunmalıdır. QUALITY Pestisit Paradoksu Aynı testleri tekrar tekrar çalıştırırsanız, bir süre sonra sistemdeki yeni hataları bulamaz hale gelirler. QUALITY 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. QUALITY Sturgeon Kanunu Her şeyin (ve piyasadaki yazılımların, framework'lerin) %90'ı çöptür. ARCHITECTURE Amdahl Kanunu Sistemi ne kadar paralelleştirirseniz (thread, cpu) paralelleştirin, performans kazancı paralel yapılamayan dar boğaza takılır. ARCHITECTURE 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. ARCHITECTURE Metcalfe Kanunu Bir ağın veya sosyal medyanın değeri, kullanıcı sayısının karesi ile orantılı olarak artar. DESIGN 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. DESIGN 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. DESIGN Hanlon'un Usturası Yetersizlik veya aptallıkla açıklanabilen hataları asla kötü niyete veya komploya yormayın. DESIGN 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. DESIGN Batık Maliyet Yanılgısı Zaman veya para harcadığınız için yanlış bir kararda/mimaride ısrar etmeye devam etmek. DESIGN 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. DESIGN 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. DESIGN Hype Döngüsü ve Amara Kanunu Teknolojilerin kısa vadeli etkilerini inanılmaz abartırız, ancak uzun vadedeki devrimsel etkilerini küçümseriz. DESIGN Lindy Etkisi Bir teknoloji ne kadar eskiyse, gelecekte de o kadar uzun süre kullanılmaya ve var olmaya devam edecektir. DESIGN İ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. DESIGN 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. DESIGN Cunningham Kanunu İnternette en iyi doğru cevabı bulmanın yolu soru sormak değil, bilerek çok yanlış bir cevap yazmaktır.