ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: Gunakan saat menulis atau mengubah kode, sebelum menandai tugas selesai, kapan pun perubahan menambahkan nama yang diekspor atau dapat diimpor, membuat modul, kelas, komponen, helper, hook, layanan, atau pembungkus, atau memusatkan kode yang berulang. Daftar periksa saat penulisan untuk membangun modul yang mendalam: beri nama keputusan yang disembunyikan oleh batas, jalani tes kedalaman dan invarian, perbaiki masalah daripada memindahkannya, jangan pernah membagi hanya berdasarkan ukuran, dan akhiri dengan catatan desain singkat. Pendamping ringkas untuk ousterhout-quality-program, yang tetap menjadi lensa tinjauan penuh.
---

# Build it deep (Ousterhout, author-time)

Anda sedang menulis kode, bukan meninjaunya. Jalankan ini pada perubahan Anda sendiri sebelum
menganggap tugas selesai.

## 1. Gerbang

Apakah perubahan menambahkan nama yang diekspor/diimpor, membuat modul, kelas,
komponen, helper, hook, layanan atau pembungkus, atau memusatkan kode yang berulang?
Jika tidak, lewati skill ini. Penggantian nama, codemods, pengeditan konfigurasi/data dan perbaikan satu baris dikecualikan.

## 2. Sebelum Anda menulis batasan

- Temukan bagaimana repo ini sudah menyelesaikan masalah dengan bentuk ini dan ikuti
  kecuali Anda bisa menyatakan alasannya tidak. Baca dokumentasi dan tipe dependensi saat ini:
  API yang diingat dari memori adalah klaim, bukan sumber.
- Tulis komentar antarmuka terlebih dahulu: apa yang dijanjikan, apa yang disembunyikan. Jika
  Anda tidak bisa menamai keputusan tersembunyi (format, kebijakan, aturan, pilihan skema), batasan itu tidak boleh ada. Sisipkan di dalamnya.
- Namai dengan bahasa domain. Jika nama jujur satu-satunya adalah `utils`,
  `helpers` atau `manager`, pemisahannya salah tempat.

## 3. Dua tes

- **Kedalaman.** Antarmuka harus menyembunyikan jauh lebih banyak daripada yang diungkapkan. Sebuah
  pembungkus yang meneruskan argumennya adalah biaya tanpa manfaat; hapus itu.
- **Invarian.** Ekstrak kode bersama hanya ketika melindungi aturan bersama.
  Buktinya adalah perubahan bersama: salinan diperbaiki atau diubah bersama dalam
  sejarah. Yang mirip tapi berubah secara independen tetap diduplikasi.

## 4. Perbaikan harus menghilangkan masalah, bukan memindahkannya

- Enam cast yang dipindahkan ke satu helper cast generik tetap enam cast. Tulis
  pemetaan bertipe yang ditutupi oleh cast tersebut.
- Jangan tambahkan parameter atau flag yang mendorong keputusan ke pemanggil kecuali
  pemanggil benar-benar tahu sesuatu yang Anda tidak tahu. Serap kasus sulit di dalamnya.
- Utamakan semantik di mana kasus error tidak bisa muncul daripada membuat setiap
  pemanggil menanganinya.
- Memindahkan kompleksitas domain penting ke file lain bukanlah penyederhanaan.

## 5. Di bawah tekanan "bersihkan ini" atau "file ini terlalu besar"

Jangan pernah membagi hanya berdasarkan ukuran. Satu modul 400 baris yang menyembunyikan satu keputusan lebih baik
 daripada empat modul 100 baris yang membocorkan sambungan yang sama. Tanyakan keputusan apa yang disembunyikan setiap pemisahan; jika tidak ada, jangan pisah.

## 6. Keamanan

Kode yang ada: kunci perilaku saat ini dengan tes sebelum memperdalamnya. Kode baru: tulis tes yang mendefinisikan perilaku yang diinginkan.

## 7. Laporan

Jika gerbang aktif, akhiri pesan akhir Anda dengan catatan desain 2-4 baris: setiap
batasan yang Anda tambahkan dan keputusan yang disembunyikannya; duplikasi yang Anda tinggalkan dengan sengaja dan alasannya; apa pun yang dangkal yang Anda terima dan alasannya.

Untuk panggilan yang diperdebatkan atau tinjauan penuh, muat `ousterhout-quality-program`.

Tag