ousterhout-kalite-programı

SKILL.md

---
name: ousterhout-kalite-programı
description: Kod yazılırken veya incelenirken bir sınır oluşturuluyorsa ya da değiştiriliyorsa — yeni bir modül, sınıf, bileşen, yardımcı, hook, servis veya sarmalayıcı; paylaşılan kodun herhangi bir çıkarımı veya merkezileştirilmesi; herhangi bir "bunu yeniden kullanılabilir yapalım" anı — ve özellikle bir modül incelenirken, yeniden düzenlenirken veya tasarlanırken kullanılır. Bir soyutlamanın karşılığını verip vermediğini değerlendirir: modül derinliği, bir tasarım kararını gizleyip gizlememesi, çoğaltılmış kodun paylaşılan bir değişmezliği koruyup korumadığı ya da sadece uyumlu olup olmadığı, bir arayüzün kararlı olup olmadığı. Çok sayıda sığ sınıf üreten mekanik SOLID/Temiz Kod uygulamalarına karşı koruma sağlar. Ayrıca okuyucu-maliyet testini tanımlar (insanlar ve ajanlar için okunması ve değiştirilmesi ucuz olan kod) ve mevcut bir kod tabanını bu standarda göre yeniden düzenleme prosedürünü belirler.
---

# Ousterhout Kalite Programı

## Genel Bakış

Bir modülün görevi, karmaşıklığı küçük bir arayüzün arkasına gizlemektir. Temel ölçüt **derinlik**tir: derin bir modül, önemli işlevsellik üzerinde basit bir arayüz sunar; sığ bir modülün arayüzü ise uygulaması kadar karmaşıktır, bu yüzden kendini hiçbir şeyle ödeyemez. Karmaşıklık, bir değişiklik beklemediğiniz kodu anlamanızı veya dokunmanızı zorunlu kıldığında hissettiğiniz şeydir — Ousterhout iki kaynaktan bahseder: **bağımlılıklar** (A'yı değiştirmeden B'yi değiştiremezsiniz) ve **belirsizlik** (önemli bilgi açık değildir).

Ousterhout yalnızca iyi bir modülün *hissettiği* şeyi söyler. En güçlü hali, sınırların nerede olması gerektiğini ve onlara güvenli şekilde nasıl yaklaşılacağını söyleyen birkaç başka bakış açısıyla birleştiğinde ortaya çıkar. Bu beceri, o birleşik bakış açısıdır.

## İncelemelerin Gerçekten Yanlış Gittiği Yer

Bu becerinin var olma nedeni olan iki hata — ajan tarafından yazılan kodda tekrar tekrar gözlemlenen — **çözüm** kısmındadır, böl/ayır kararında değil:

1. **Sığ çözüm.** Altı `as unknown as` dönüşümü verildiğinde, yardımsız inceleyen kişi bunları tek bir genel `castRows<T>()` yardımcı fonksiyonda toplar — daha düzenli ama belirsizlik devam eder. Derin çözüm, önce testleri sabitleyerek yazılan tipli satır→alan eşleyicileridir (Parnas uygular: bir dönüşüm eksik sınırın kokusudur; Beck: taşıma işleminden önce eşlemeyi kanıtla). Bir kokuyu düzeltmek onu ortadan kaldırmak değildir.
2. **Refleksif çıkarım.** Aynı güncelleme mantığı üç kardeş bileşende tekrarlandığında, her yardımsız inceleyen "paylaşılan bir yardımcı çıkar" dedi — DRY refleksi. Bu programın kuralı, Metz'i genişleterek: üçüncü benzer görünene değil, değişmezliğe (invariant) kadar bekle — kod paylaşılan bir kuralı koruduğunda merkezileştir, sadece benzer olduğunda değil.

Bir çözüm önerdiğinizde, ikisini de uygulayın: belirsizliği kaldırıyor mu yoksa sadece yer değiştiriyor mu, çıkarım bir değişmezliği koruyor mu yoksa sadece bir şekli çoğaltıyor mu?

## Orantısallık Kapısı

Bir değişiklik yeni bir dışa aktarılabilir/içe aktarılabilir isim eklemiyor, yeni modül/sınıf/bileşen/yardımcı/kanca/hizmet/sarmalayıcı yaratmıyor ve hiçbir şeyi merkezileştirmiyorsa bu bakış açısını atlayın. Saf yeniden adlandırmalar, mekanik kod değişiklikleri, yapılandırma/veri düzenlemeleri ve tek satırlık düzeltmeler muaf tutulur. Şüphede kalırsanız, sadece iki temel testi (derinlik, değişmezlik) çalıştırın ve orada durun.

## Tam Kural

Oluşturulan veya incelenen her kod parçası, görev tamamlanmadan önce Ousterhout bakış açısından geçer — sadece açık tasarım incelemeleri değil — orantısallık kapısının altındaki değişiklikler hariç (yeni sınır yok, merkezileştirme yok: yeniden adlandırmalar, kod değişiklikleri, yapılandırma düzenlemeleri). İki test: (1) **Derinlik** — yeni bir arayüz, ortaya çıkardığından çok daha fazlasını gizlemelidir; sarmaladığı kadar karmaşık bir arayüz hiçbir şey kazandırmaz. (2) **Değişmezlik** — paylaşılan kod, sadece paylaşılan bir kuralı koruduğunda çıkarılmalıdır, üç yer benzer diye değil; ve bir düzeltme belirsizliği kaldırmalı, sadece yerini değiştirmemelidir (altı dönüşümü bir yardımcıda toplamak hâlâ altı dönüşümdür). Bir değişiklik bir sınır yaratıyor veya şekillendiriyorsa, önce yerleşik bir ürünün bu şekil ve ölçekteki bir problemi nasıl çözdüğünü bulun ve açık bir neden yoksa onun kurallarını benimseyin (eğitimden hatırlanan bir desen iddia, kaynak değildir), sonra aşağıdaki kontrolleri yapın.

## Ne Zaman Kullanılır

- Yeni bir sınıf/fonksiyon/kanca arayüzünün değerli olup olmadığını, yoksa sadece sığ bir geçiş olup olmadığını karar verirken.
- Bir dosya boyut eşiğini aştığında ve sadece bölünmesi gerektiğine değil, *nasıl* bölüneceğine karar verirken.
- Tekrarlanan kod sizi paylaşılan bir yardımcı çıkarmaya teşvik ettiğinde.
- Bir iş kuralı etrafında sınır tasarlarken veya incelerken (bir yetkilendirme kapsamı kontrolü, para/yuvarlama kuralı, durum makinesi geçiş koruması, veri saklama kuralı).
- Bir arayüz parametre veya özel durum eklemeye hazırlanıyorsa.
- Mevcut bir kod tabanını bu standarda getirmek — aşağıdaki "Mevcut Bir Kod Tabanını Bu Standarta Refaktör Etmek" bölümüne bakın.

**Uygun değil:** önemsiz mekanik düzenlemeler veya bir proje kuralı zaten yapıyı belirtiyorsa — yukarıdaki Orantısallık Kapısına bakın. Cerrahi değişiklik disiplini için `karpathy-guidelines` ve refaktör güvenliği için test odaklı geliştirme becerisine öncelik verin, bunlar mevcutsa.

## Bakış Açıları

Her bakış açısı tam olarak bir soru ekler. Ousterhout omurgadır; diğerleri onun kör noktalarını düzeltir.

| Lens | Eklediği temel soru | Ne zaman geçersiz kılar |
|---|---|---|
| **Ousterhout** — derin modüller | Bu arayüz, ortaya koyduğundan daha fazlasını mı gizliyor? | Varsayılan omurga. |
| **Parnas** — bilgi gizleme | Bu modül hangi (muhtemelen değişecek) tasarım kararını gizliyor? | Bir modülün derin olması *sebebi*. Eğer değişen hiçbir şeyi gizlemiyorsa, derinlik kozmetiktir. |
| **Brooks** — temel ve tesadüfi | Bu, tesadüfi karmaşıklığı ortadan kaldırıyor mu yoksa temel alan karmaşıklığını sadece başka yere mi taşıyor? | Karmaşayı küçültmeden sadece yer değiştiren "refaktörleri" öldürür. |
| **Evans** — Domain-Driven Design | Bu sınır, genel yardımcı dil değil, alan dilinde mi adlandırılmış? | `utils`/`helpers` yeniden adlandırılmalı — sınır, bu depo gerçekten sahip olduğu değişmezlik adına adlandırılmalı. |
| **Fowler** — refaktör / kokular | Daha derin tasarıma doğru en küçük güvenli adım nedir? | "Daha derin olmalı"yı, geçen testlerin arkasındaki somut adımlara dönüştürür. |
| **Beck** — basit tasarım, test-öncelikli | Derinleştirmeden önce mevcut davranışı kanıtladım mı? | Erken mimariyi frenler. Önce çalıştır ve test et, sonra doğru dikişi derinleştir. |
| **Hickey** — basit ve kolay | Bu, ilgisiz kavramları karıştırıyor mu yoksa gerçekten tek bir kavram mı? | Sığ bir yardımcı genellikle *kolay*dır (yakın, hızlı), *basit* değil (az sayıda iç içe kavram). Basiti tercih et. |
| **Metz** — yanlış soyutlamadan çok çoğaltma | Bu tekrar eden kod paylaşılan bir değişmezliği mi koruyor yoksa sadece benzer mi görünüyor (bu programın kuralı, Metz'i genişletiyor)? | Metz: yanlış soyutlamadan çok çoğaltma daha ucuzdur — yanlış soyutlamayı geri satır içi yap, bükme. Bu program genişletiyor: tekrar ettiği için **merkezi hale getirme**; sadece gerçek bir değişmezliği koruyorsa merkezi hale getir. Değişmezlik ortaya çıkana kadar çoğaltmaya tolerans göster. |
| **Hyrum Yasası** — gözlemlenebilir davranış | Çağıranlar bu arayüzün sözleşmesinin ötesinde davranışa mı bağımlı olacak? | Küçük, stabil arayüzler için argüman: her gözlemlenebilir davranış sonunda yük taşıyıcı olur. |

## Birleştirme Tarifi

Bu sırayla uygula — sonraki lensler ancak önceki geçerse önemlidir:

1. **Metz — kabul kapısı.** Bu sınır/soyutlama varlığını hak ediyor mu? Bu programın kuralı, Metz'i genişletiyor: kod paylaşılan bir kuralı koruyorsa çıkar — üç benzer, ortaya çıkmış bir değişmezlik değildir. Hayırsa, burada dur.
2. **Parnas / Ousterhout** — Değişken kararı (yetkilendirme kapsamı, yuvarlama kuralı, geçiş koruması, saklama kuralı) derin bir modülün arkasına gizle.
3. **Evans** — O modülü alan dilinde adlandır, `utils` değil.
4. **Beck / Fowler** — Mevcut kod için, mevcut davranışı testlerle sabitle, sonra küçük güvenli adımlarla refaktör yap. Yeni oluşturulan kod için sabitlenecek mevcut davranış yok — bunun yerine amaçlanan davranışı tanımlayan testi yaz.
5. **Hickey** — İş akışları benzer göründüğü için ilgisiz kavramları karıştıran arayüzleri reddet.

## Yapısal Anti-Desen

**Mekanik SOLID / Clean Code sığ modüller üretir.** Dogmatik bir okuma —
her sorumluluk için bir sınıf, her fonksiyonu çıkar, her şeyi küçük tut —
bedenleri kadar karmaşık arayüzlere sahip bir sınıf sürüsü verir. Bir kural "böl" diyorsa, bölmenin hangi *kararı* gizlediğini (Parnas) ve ortaya koyduğundan daha fazlasını gizleyip gizlemediğini (Ousterhout) sor. Değişen hiçbir şeyi gizlemiyorsa bölme. Bu koruma en çok refaktör baskısı altında önemlidir ("bunu temizle", "bu dosya çok büyük") — sakin analizde inceleyenler zaten karşı çıkar; refaktör ortasında, görünür değişiklik üretme zorunluluğuyla, sığ dosya sürüsü yazılır.

## Yaygın Hatalar

- **Sadece boyuta göre bölme.** Bir karar gizleyen 400 satırlık sorgu modülü, aynı birleşimleri sızdıran dört 100 satırlık modülden daha derin olabilir.
- **Bölmeyi `helpers`/`utils` olarak adlandırma.** Alan dilinde adlandıramıyorsan (Evans), sınır muhtemelen yanlıştır.
- **İkinci ortaya çıkışta çıkarma.** Bu programın kuralı, Metz'i genişletiyor: değişmezliği bekle, üçüncü benzer değil.
- **Davranışı sabitlemeden derinleştirme.** Beck: mevcut davranışı kanıtlayan test olmadan "derinleştirme" refaktörü yeniden yazmadır.
- **Geçiş olarak modül sayma.** Argümanlarını ileten bir sarmalayıcı arayüz ekler ama hiçbir şey gizlemez — tanım gereği sığdır.
- **Kafiye ile değişmezliği karıştırma.** Paylaşılan değişmezliğin en iyi kanıtı birlikte değişimdir: kopyalar tarih boyunca birlikte düzeltilmiş veya değiştirilmiş (aynı hata iki yerde düzeltilmiş). Bağımsız değişen benzerler kafiyedir; çoğaltılmış bırak.
- **Kokuyu temizlemek yerine düzenlemek.** Altı dönüşümü tek bir genel dönüşüm yardımcısında merkezileştirmek aynı belirsizliğin düzenli versiyonudur. Derin çözüm, dönüşümün üzerini kapattığı sınırı adlandırır.

## Okuyucu Maliyeti: Üçüncü Test

Derinlik ve değişmezlik bir sınırın var olup olmayacağını belirler. Okuyucu maliyeti ise etrafındaki kodun değiştirilmesinin ucuz olup olmadığını belirler. Sonraki okuyucu, insan veya ajan, bir şeyi güvenle değiştirmek için yüklemesi gereken her satır için ödeme yapar. Ajanlar token ile öder ve metin araması, kısmi okuma ve tip kontrol/test döngüleriyle gezinir, bu yüzden aynı kusurlar onlar için daha maliyetlidir. Sor:

- **Bulunabilir mi?** Her kavram için bir isim, her yerde aynı şekilde yazılmış, düz metin aramasıyla ulaşılabilir. Kusurlar: dizilerden oluşturulan isimler, import yan etkisiyle bağlantı, tanımı gizleyen yeniden ihracat zincirleri, bir kavram için iki isim.
- **Okuyucu erken durabilir mi?** Sözleşme dosyanın en üstünde veya ihracatın üstünde yer alır: neyi vaat ettiği, neyi gizlediği, asla ne yapmadığı. Kusur: sözleşme ancak gövde okunarak çıkarılabilir.
- **Makine tarafından kontrol edilebilir mi?** Her sınırın giriş ve çıkışında kesin türler, böylece tür kontrolü çağıranları okumayı yerine geçer. Kusurlar: `any`, çıplak sözlükler, anlamı gövdede yaşayan boolean bayraklar.
- **Bağlantı görünür mü?** Birlikte değişmesi gereken yerler zorlanır (paylaşılan bir tür, bir test, tek bir kaynak) veya başarısız olursa, her iki yerde işaretlenir. Gizli bağlantının kanıtı, kodda hiçbir şeyin bahsetmediği geçmişte birlikte değişmedir.
- **Gürültüsüz mü?** Kodu tekrar eden yorum yok, yorum satırı haline getirilmiş kod yok, ölü dallar yok, değişiklik geçmişi yorumları yok, yerine konulan eski yol yanına konmamış.
- **Öngörülebilir mi?** Düzen depo mevcut desenini takip eder; test okuyucunun arayacağı yerde ve kendi başına çalışır.

Dosya boyutu kasıtlı olarak yok. Çok büyük bir dosya ikinci gizli kararı aramak için bir neden olabilir, asla kesmek için değil: okuyucular arama yapabilir ve bir aralığı okuyabilir, ve hiçbir şeyi gizlemeyen bir bölme yükü kaldırmadan arayüzler ekler.

Kod içi işaretler ve depo kod haritası için, mevcutsa `context-audit` kullanın: onun `AIDEV-NOTE:` çapa (bir kurtarılamaz gerçek artı bir kaynak referansı, en fazla iki satır, yerde) zorlanamayan bağlantı için konvansiyondur.

## Mevcut Bir Kod Tabanını Bu Standarta Yeniden Düzenleme

Bir retrofit yeni kodla aynı şekilde değerlendirilir; farkı sıra ve ölçüdür. Kod tabanının çoğu olduğu gibi bırakılmalıdır.

1. **Sayım, salt okunur.** Sınırları listeleyin (modüller, servisler, paylaşılan yardımcılar). Her kayıt için: gizlediği karar veya "yok"; arayüz boyutu ile gövde; geçmişten birlikte değişen ortaklar; okuyucu maliyeti kusurları. Henüz hiçbir şeyi değiştirmeyin.
2. **Çirkinliğe değil, değişime göre sıralayın.** Öncelik, kodun ne sıklıkla değiştiği ile okunma maliyetinin çarpımıdır. Çalışan soğuk kod olduğu gibi kalır, ne kadar sığ olursa olsun. Temel alan karmaşıklığı olduğu yerde kalır (Brooks).
3. **Her bulgu için bir çözüm atayın:**
   - hiçbir şeyi gizlemeyen geçiş katmanı veya sarmalayıcı: silin, çağıranlar sarmaladığı şeyi kullanır;
   - bayraklar ve özel durumlarla bükülmüş yanlış soyutlama: geri satır içine alın (Metz), sonra gerçek değişmez arayın;
   - bir kararı paylaşan sığ kardeşler: onları tek bir arayüz arkasında birleştirin;
   - sızan karar (çağıranlar formatı, kuralı, şemayı biliyor): onu sahip olan modüle çekin;
   - genel isim (`utils`, `helpers`, `manager`): gizlediği karara göre yeniden adlandırın veya çağıranlarına çözün;
   - türsüz sınır: tür verin ve dönüşümleri kaplayan haritayı kullanarak değiştirin;
   - gizli bağlantı: zorlayın veya her iki yeri işaretleyin;
   - gürültü: silin.

   Bağımsız değişen uyaklara çözüm yok.
4. **Davranışı önce sabitleyin.** Hiçbir çözüm, dokunduğu kodun mevcut davranışını test kanıtlamadan başlamaz (Beck). Yeniden düzenlemeler davranışı korur; davranış değişikliği ayrı bir commit'tir.
5. **İşi bir ajanın tek başına bitirebileceği birimlere bölün.** Birim başına bir sınır. Her birim sahip olduğu dosyaları, koruması gereken sözleşmeyi ve bunu kendi başına kanıtlayan komutu adlandırır. İki eşzamanlı birim aynı dosyayı yazmaz; paylaşılan dosyalar (barrel, kayıtlar, rota tabloları) tek bir sahip alır veya entegrasyon bekler. Birden fazla birimin bağlı olduğu arayüz değişiklikleri önce kendi birimi olarak yapılır.
6. **Sonucu ölçün.** Başlamadan önce temsilci bir değişiklik seçin ve okuyucunun onu yapmak için yüklemesi gereken dosya ve satır sayısını sayın; sonra tekrar sayın. İhraç edilen isimler ve toplam satırlar düşmeli veya sabit kalmalıdır. Arayüz ekleyen bir yeniden düzenleme belirtilmiş bir sebep borçludur.
7. **Durun** kalan soğuk, temel veya uyak olduğunda.

İlgili beceriler, mevcutsa: `repo-review` (tasarım türü) sayımı sadece tavsiye amaçlı üretir; `design-cleanup` kazara karmaşıklık için düzelt ve yeniden tara döngüsünü çalıştırır; `context-audit` çapalar ve kod haritası ekler; `ousterhout-build-deep` birimlerle ilgilenen ajanlar için yazar zamanı kontrol listesidir.

## Bu Nerede Duruyor

Bu beceri inceleme ve yargı katmanıdır: bir soyutlamanın derin olup olmadığını, doğru karar için adlandırılıp adlandırılmadığını ve çıkarılmaya değer olup olmadığını karar vermek için kullanın. `find-shared-code` bunu, paylaşmaya değer kod için yakın geçmişi tararken kabul testi olarak kullanır. Aşağıdaki Ek her yazarın gerekçesini verir.

---

## Ek: Derinlemesine Mercekler

Her yazarın yakaladığı hata modu ve her birinin size verdiği tek hamle. Yukarıdaki tablo hızlı başvuru; bu onun arkasındaki mantıktır.

### Ousterhout — Derin Modüller (omurga)

*Bir Yazılım Tasarımı Felsefesi.*

- **Derinlik** = fayda (gizlenen işlevsellik) ÷ maliyet (arayüz karmaşıklığı). Derin bir modül azın arkasında çok şeyi gizler. Sığ bir modülün arayüzü gövdesi kadar karmaşıktır, bu yüzden hiçbir şey kazanmaz.
- **Karmaşıklık** sistemi anlamayı veya değiştirmeyi zorlaştıran her şeydir. İki kaynak:
  - **Bağımlılıklar** — bir parçayı değiştirmek diğerine dokunmayı gerektirir.
  - **Belirsizlik** — önemli bilgi koddan açık değildir.
- **Belirtiler:** değişiklik çoğalması (bir karar, birçok düzenleme), bilişsel yük (kafanızda tutmanız gereken miktar), bilinmeyen bilinmeyenler (bir değişikliğin hangi kodu etkileyeceğini söyleyemezsiniz).
- **Ana hamle:** karmaşıklığı *aşağı çekmek* — modül zor durumu absorbe eder, böylece çağıranlar yapmak zorunda kalmaz. Yapılandırma parametreleri ve geçişler karmaşıklığı *yukarı* çağırana iter; bu sığlıktır.

Yakalar: uygulamasını sızdıran arayüzler; yardımcılar yardım etmeyen.

### Parnas — Bilgi Gizleme (derinliğin önemi)

*Modüllere Ayrılmada Kullanılacak Kriterler Üzerine (1972).*

- **Değişmesi muhtemel tasarım kararları** etrafında parçala, bir hesaplama adımları etrafında değil. Her modül böyle bir kararı gizler.
- Bu, derin modülün doğrudan atasıdır. Bir modül, çağıranlar arasında yayılacak bir kararı gizlediği için derindir.

Tuzağı: Hiçbir değişkenliği gizlemeyen bir "modül" — derinliği sadece görünüştedir. Sor: Bu arayüzün arkasında çağıranların asla görmediği ne değişiyor? Cevap "hiçbir şey" ise, sınır sadece süslemedir.

### Brooks — Temel ve Kazara Karmaşıklık

*Hiçbir Mucize Çözüm Yok.*

- **Temel** karmaşıklık alana özgüdür (değerlendirme gerçekten bu kadar karmaşıktır). **Kazara** karmaşıklık ise araçlarımızın ve yapımızın dayattığı şeydir.
- Sadece kazara karmaşıklık kaldırılabilir. Temel alan karmaşıklığını bir dosyadan diğerine taşıyarak "temizleyen" bir yeniden düzenleme hiçbir şey yapmamıştır.

Tuzağı: Basitleştirme kılıfına bürünmüş yeniden düzenlemeler. Sor: Toplam karmaşıklık azaldı mı yoksa sadece yer mi değiştirdi?

### Evans — Alan Odaklı Tasarım

*Domain-Driven Design.*

- Sınırlar, alanın **yaygın dili** ile adlandırılmalıdır, genel yardımcı terimlerle değil. `helpers` adlı bir modül hiçbir şey adlandırmaz; `AccessScope` veya `PricingPolicy` adlı bir modül ise bir değişmezliği adlandırır.
- Sınırlı bağlamlar, iş değişmezliklerinin dikişlerden sızmasını engeller.

Tuzağı: Doğru parçalama ama anlamsız isimler. Modülü alan dilinde adlandıramıyorsanız, muhtemelen sınırı yanlış yerde kesmişsinizdir.

### Fowler — Yeniden Düzenleme ve Kod Kokuları

*Refactoring.*

- Mevcut tasarımdan daha derin olana geçmek için somut, güvenli, adlandırılmış hareketler verir (Fonksiyon Çıkar, Alan Taşı, Koşullu Yapıyı Polimorfizmle Değiştir).
- Her hareket davranışı korur ve küçüktür, böylece geri alınabilir kalır.

Tuzağı: "burası daha derin olmalı" ile sonraki commit'i bilmek arasındaki boşluk. Ousterhout hedefi belirler; Fowler yol gösterir.

### Beck — Basit Tasarım, Test-Öncelikli

*Test-Driven Development; XP.*

- Beck'in yayımladığı sırayla basit tasarımın dört kuralı: testleri geçer, tekrar yok, niyeti ortaya koyar, en az öğe. Bu program, Fowler/Haines'in daha sonraki sıralamasını takip eder — niyet tekrardan önce — çünkü bu programın Metz'i genişleten değişmezlik kuralına hizmet eder (aşağıya bakınız): koruduğu niyeti adlandırana kadar tekrara müdahale etme.
- Test-öncelikli, erken mimariye karşı bir fren görevi görür. Önce çalıştır ve davranışı kanıtla, sonra testlerin koruduğu dikişi derinleştir.

Tuzağı: Davranış sabitlenmeden önce inşa edilen mimari. Mevcut davranışı kanıtlayan bir test olmadan, "derinleştirme" yeniden düzenlemesi doğrulanmamış bir yeniden yazmadır.

### Hickey — Basit ve Kolay

*Simple Made Easy.*

- **Basit** = karışmamış: tek bir kavram, diğerleriyle iç içe değil (nesnel).
- **Kolay** = el altında, tanıdık, hızlı erişilebilir (sana göre göreceli).
- İkisi bağımsızdır. Sığ bir yardımcı genellikle *kolay*dır — yazması hızlı, yakındır — ama ilgisiz konuları karıştırıyorsa *basit* değildir.

Tuzağı: Tasarım kılıfına bürünmüş kolaylık. Yazması daha hızlı olsa bile kavramları karıştırmayan yapıları tercih et.

### Metz — Yanlış Soyutlamadan Çok Tekrarı Tercih Et

*"The Wrong Abstraction" (2016).*

- Yanlış soyutlama, tekrar etmeye göre çok daha maliyetlidir. Çok erken çıkarılan bir soyutlama, gelecekteki her çağıranın asla hepsi için doğru olmayan varsayımlara uymasını zorunlu kılar.
- Bir soyutlama yanlış çıktığında, Metz'in çözümü onu tekrar satır içine almak ve tekrarın geri dönmesine izin vermektir; asla yapılmadığı bir duruma uydurmaya çalışmak değil.
- **Bu programın Metz'i genişleten kuralı: kod tekrar ettiği için merkezileştirme yapma. Gerçek, paylaşılan bir değişmezliği koruduğunda merkezileştir.** Değişmezlik ortaya çıkana kadar tekrarı tolere et.

Tuzağı: aşırı merkezileştirme — herkesin şimdi etrafından dolaşmak zorunda olduğu sığ ortak yardımcı. Bu, mekanik "her ne pahasına olursa olsun DRY" anlayışına karşı dengeleyicidir.

### Hyrum Yasası — Gözlemlenebilir Davranış Sözleşmeye Dönüşür

*"Yeterince kullanıcı olduğunda, sisteminizin her gözlemlenebilir davranışına birisi bağımlı olur."*

- Bir arayüzün *rastgele* yaptığı her şey — sıralama, zamanlama, hata metni — sonunda birisi tarafından güvenilir hale gelir. Bu yüzden açtığınız yüzey, belgelenen yüzeyden daha büyüktür.
- Bu, Ousterhout'un **küçük, stabil arayüzler** tercihine destek olur: ne kadar az açarsanız, kazara o kadar az yük taşıyıcı olur.

Tuzağı: sertleşecek geniş arayüzler. Her ekstra gözlemlenebilir, gelecekte bir kısıtlamaya dönüşür.

### Birlikte Nasıl Uyarlarlar

- **Parnas → Ousterhout:** değişken bir kararı gizle → modül derindir.
- **Brooks:** derinliğin karmaşıklığı kaldırdığını, sadece yer değiştirmediğini doğrula.
- **Evans:** sınırı alan dilinde adlandır.
- **Beck → Fowler:** davranışı sabitle, sonra küçük güvenli hareketlerle yeniden düzenle.
- **Metz:** değişmezlik gerçek olana kadar merkezileştirmeye diren.
- **Hickey:** arayüzü tek bir kavrama indir.
- **Hyrum:** o arayüzü küçük tut ki stabil kalabilsin.

Tehlike, Ousterhout'u SOLID veya Clean Code'un mekanik bir okumasıyla karıştırmaktır: bu, sığ arayüzlü çok sayıda küçük sınıf ve fonksiyon üretir — derin modüllerin tam tersi. Ousterhout, Metz'in dengeleyicisiyle birlikte, panzehirdir.

Etiketler