ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: Використовуйте під час написання або зміни коду, перед тим як вважати завдання виконаним, коли зміна додає експортовану або імпортовану назву, створює модуль, клас, компонент, хелпер, хук, сервіс або обгортку, або централізує повторюваний код. Контрольний список для автора під час створення глибоких модулів: назвіть рішення, яке приховує межа, пройдіть тести на глибину та інваріантність, виправляйте проблеми замість їх переміщення, ніколи не розбивайте лише за розміром і завершуйте короткою нотаткою про дизайн. Компактний супутник ousterhout-quality-program, який залишається повним оглядовим інструментом.
---

# Build it deep (Ousterhout, author-time)

Ви пишете код, а не переглядаєте його. Запустіть це на власній зміні перед тим, як вважати завдання виконаним.

## 1. Відбір

Чи додає зміна експортоване/імпортоване ім'я, створює модуль, клас, компонент, хелпер, хук, сервіс або обгортку, чи централізує повторюваний код? Якщо ні, пропустіть цей навик. Перейменування, codemods, редагування конфігурації/даних та одно-рядкові виправлення не враховуються.

## 2. Перед тим, як писати межу

- Знайдіть, як цей репозиторій уже вирішує проблему такого типу, і дотримуйтеся цього, якщо не можете пояснити, чому ні. Читайте поточну документацію та типи залежності: API, згаданий з пам’яті,: це припущення, а не джерело.
- Спочатку напишіть коментар до інтерфейсу: що він обіцяє, що приховує. Якщо ви не можете назвати приховане рішення (формат, політика, правило, вибір схеми), межа не повинна існувати. Вбудуйте її.
- Називайте це мовою предметної області. Якщо єдина чесна назва: `utils`, `helpers` або `manager`, розріз зроблено не в тому місці.

## 3. Два тести

- **Глибина.** Інтерфейс має приховувати значно більше, ніж відкривати. Обгортка, що просто передає аргументи,: це витрати без користі; видаліть її.
- **Інваріант.** Витягуйте спільний код лише тоді, коли він захищає спільне правило. Доказ: спільна зміна: копії виправлялися або змінювалися разом у історії. Схожі, що змінюються незалежно, залишаються дубльованими.

## 4. Виправлення має усувати проблему, а не переміщувати її

- Шість приведень типів, зібраних в один універсальний хелпер, все одно залишаються шістьма приведеннями. Напишіть типізований мапер, який приховував ці приведення.
- Не додавайте параметр або прапорець, що перекладає рішення на виклики, якщо виклики справді не знають чогось, чого не знаєте ви. Візьміть складний випадок всередину.
- Віддавайте перевагу семантиці, де помилка не може виникнути, а не тому, щоб кожен виклик обробляв її.
- Переміщення суттєвої складності предметної області в інший файл: це не спрощення.

## 5. Під тиском "прибрати це" або "цей файл занадто великий"

Ніколи не розбивайте лише через розмір. Один модуль на 400 рядків, що приховує одне рішення, кращий за чотири модулі по 100 рядків, які протікають тими ж зв’язками. Запитайте, яке рішення приховує кожен розріз; якщо жодного: не розбивайте.

## 6. Безпека

Існуючий код: зафіксуйте поточну поведінку тестом перед поглибленням. Новий код: напишіть тест, що визначає бажану поведінку.

## 7. Звіт

Якщо відбір спрацював, завершіть фінальне повідомлення 2-4 рядками нотатки про дизайн: кожна додана межа і рішення, яке вона приховує; дублювання, залишене навмисно, і чому; все поверхневе, що прийняли, і чому.

Для спірного рішення або повного огляду завантажте `ousterhout-quality-program`.

Теги