ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: Kod yazarken veya değiştirirken, görevi tamamlamadan önce, değişiklik bir dışa aktarılabilir veya içe aktarılabilir isim ekliyorsa, bir modül, sınıf, bileşen, yardımcı, hook, servis veya sarmalayıcı oluşturuyorsa ya da tekrarlanan kodu merkezileştiriyorsa kullanın. Derin modüller oluşturmak için yazar zamanı kontrol listesi: sınırın gizlediği kararı adlandırın, derinlik ve değişmezlik testlerini geçin, sorunları taşımak yerine düzeltin, yalnızca boyuta göre bölmeyin ve kısa bir tasarım notu ile bitirin. ousterhout-quality-program için kompakt bir tamamlayıcıdır, o ise tam inceleme merceği olarak kalır.
---

# Derin İnşa Et (Ousterhout, yazar-zaman)

Kod yazıyorsunuz, inceleme yapmıyorsunuz. Görevi tamamlamadan önce kendi değişikliğinizde bunu çalıştırın.

## 1. Kapı

Değişiklik, dışa aktarılabilir/içe aktarılabilir bir isim ekliyor mu, bir modül, sınıf, bileşen, yardımcı, hook, servis veya sarmalayıcı mı oluşturuyor ya da tekrarlanan kodu merkezileştiriyor mu? Hayırsa, bu beceriyi atlayın. Yeniden adlandırmalar, kod değişiklikleri, yapılandırma/veri düzenlemeleri ve tek satırlık düzeltmeler muaf tutulur.

## 2. Sınırı yazmadan önce

- Bu depo zaten bu şekilli bir problemi nasıl çözüyor bulun ve neden yapmadığınızı açıklayamazsanız onu takip edin. Bağımlılığın mevcut dokümantasyonunu ve tiplerini okuyun: hafızadan çağrılan bir API iddiadır, kaynak değil.
- Önce arayüz yorumunu yazın: neyi vaat ediyor, neyi gizliyor. Gizli kararı (bir format, politika, kural, şema seçimi) adlandıramıyorsanız, sınır olmamalı. Satır içi yazın.
- Alan dilinde adlandırın. Tek dürüst isim `utils`, `helpers` veya `manager` ise, kesim yanlış yerde demektir.

## 3. İki test

- **Derinlik.** Arayüz, ortaya koyduğundan önemli ölçüde daha fazlasını gizlemeli. Argümanlarını ileten bir sarmalayıcı faydasız bir maliyettir; silin.
- **Değişmezlik.** Paylaşılan kodu yalnızca paylaşılan bir kuralı koruduğunda çıkarın. Kanıt, birlikte değişimdir: kopyalar geçmişte birlikte düzeltilmiş veya değiştirilmiştir. Bağımsız değişen benzerler çoğaltılmış kalır.

## 4. Bir düzeltme problemi taşımamalı, çözmeli

- Altı dönüşümün tek bir genel dönüşüm yardımcısına taşınması hâlâ altı dönüşümdür. Dönüşümlerin üstünü kapattığı yazılı tipli eşleyiciyi yazın.
- Çağıranlara bir kararı iten parametre veya bayrak eklemeyin, çağıranlar gerçekten sizden farklı bir şey bilmiyorsa. Zor durumu içinde emin.
- Hata durumunun ortaya çıkamayacağı semantiği tercih edin, her çağıranın bunu ele almasını sağlamaya kıyasla.
- Temel alan karmaşıklığını başka bir dosyaya taşımak basitleştirme değildir.

## 5. "Bunu temizle" veya "bu dosya çok büyük" baskısı altında

Sadece boyuta göre asla bölmeyin. Bir karar gizleyen 400 satırlık modül, aynı birleşimleri sızdıran dört 100 satırlık modülden iyidir. Her bölmenin hangi kararı gizlediğini sorun; yoksa bölmeyin.

## 6. Güvenlik

Mevcut kod: Derinleştirmeden önce mevcut davranışı bir testle sabitleyin. Yeni kod: amaçlanan davranışı tanımlayan testi yazın.

## 7. Rapor

Kapı tetiklendiyse, son mesajınızı 2-4 satırlık bir tasarım notuyla bitirin: eklediğiniz her sınır ve gizlediği karar; kasıtlı bıraktığınız çoğaltmalar ve nedenleri; kabul ettiğiniz yüzeysel olan her şey ve nedenleri.

Tartışmalı bir karar veya tam inceleme için `ousterhout-quality-program` yükleyin.

Etiketler