Sign in Subscribe

Yazılım Mühendisliği Kanunları

CATEGORY
TEAMS

Conway Kanunu

Organizasyonlar, kendi iletişim yapılarını kopyalayan sistemler tasarlarlar. Sistem mimariniz şirket içi iletişimin bir aynası olur.
TEAMS

Inverse Conway Maneuver

İstediğiniz sistem mimarisine ulaşmak için organizasyon ve takım yapısını bilinçli olarak o mimariye göre tasarlayın.
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.
PLANNING

Bike-Shedding (Parkinson'un Önemsizlik Kanunu)

İnsanlar karmaşık ve önemli kararlar yerine, herkesin fikir söyleyebildiği önemsiz detaylarda daha çok tartışır.
PLANNING

Little Kanunu

Bir sistemdeki ortalama iş sayısı, geliş hızı ile sistemde geçirilen ortalama sürenin çarpımıdır. WIP arttıkça teslimat yavaşlar.
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

Wirth Kanunu

Yazılımlar, donanımın hızlanmasından daha hızlı şekilde yavaşlar. Yeni kaynaklar çoğu zaman yeni şişkinlikle tüketilir.
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

Nielsen Kullanılabilirlik Sezgileri

İyi arayüzler sistem durumunu görünür kılar, kullanıcıya kontrol verir, hataları önler ve gerçek dünya beklentileriyle uyumlu davranı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

Chesterton'ın Çiti

Bir kuralı, kodu veya mimari sınırı neden var olduğunu anlamadan kaldırmayın. Önce amacı öğrenin, sonra değiştirin.
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

Mooers Kanunu

Bilgiye ulaşmak, onu kullanmamaktan daha zahmetliyse insanlar o bilgiyi kullanmaz. Dokümantasyon kolay bulunmalıdır.
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

Yak Tıraşlama (Yak Shaving)

Asıl işi yapmak yerine, onu yapabilmek için çıkan zincirleme yan işlere gömülme halidir.
DESIGN

Rob Pike'ın Programlama Kuralları

Veri yapıları algoritmalardan önce gelir; ölçmeden optimize etmeyin ve basit, okunabilir çözümleri tercih edin.
DESIGN

Cunningham Kanunu

İnternette en iyi doğru cevabı bulmanın yolu soru sormak değil, bilerek çok yanlış bir cevap yazmaktır.

Ayrı Rehberler

Kanun formatına sığmayacak kadar kapsamlı konular için daha uzun, pratik kontrol listeleri ve kod örnekleri içeren ayrı bir rehber sayfası hazırladık.

Rehberlere Git →