simplicity-discipline

--- name: simplicity-discipline description: Дисциплина простоты при кодировании/дизайне (Karpathy) — think-before-coding, simplicity-first, surgical-changes, goal-driven. ИСПОЛЬЗУЙ когда правишь существующий код, рефакторишь, ловишь over-engineering, или решение разрастается. Триггеры 'упростить', 'проще', 'не усложняй', 'минимальная правка', 'surgical', 'refactor', 'over-engineering', 'over-engineered', 'clean code', 'слишком сложно', 'YAGNI', 'KISS'. НЕ для запуска тестов (→ code-verify), НЕ для архитектурного исследования (→ architecture-research). metadata: adr: ADR-013 source: forrestchang/andrej-karpathy-skills (260613 Tooling Adoption Этап 2.2) --- # simplicity-discipline — дисциплина простоты (Karpathy) Применять при ЛЮБОЙ правке кода (Шаг 3 Кодирование) и при выборе подхода (Шаг 2 Дизайн). 4 правила; перед изменением — прогнать чеклист. ## 1. Think before coding (думай до кода) - Сначала сформулируй: **что именно** меняем и **зачем** (1-2 предложения). - Найди корень, а не симптом ([[feedback-root-cause-over-symptom]]): после 2-3 неудачных итераций на одной строке — STOP, спроси «почему эта строка вообще нужна?». - Прочитай существующий код/контекст ПЕРЕД правкой; не угадывай API — проверь (Context7 / live-доки, ADR-014). ## 2. Simplicity first (простота прежде всего) - KISS/YAGNI: не добавляй абстракцию/параметр/слой «на будущее». Решай задачу, что есть. - Меньше кода > больше кода. Удаление > добавление, если эффект тот же. - Переиспользуй существующее (искать через `framework-search`/grep) прежде чем писать новое. - Один способ сделать вещь, не три. ## 3. Surgical changes (хирургические правки) - Минимальный diff: трогай ровно то, что нужно для цели. Не «заодно отрефакторю рядом». - Сохраняй поведение (behavior-preservation) при рефакторе — дефолты == старое, проверяй числом/тестом (как Фаза C/B1 roadmap 260613: pooled F1 не изменился). - Не переписывай рабочий компонент — дополняй рядом (non-breaking, additive, reversible). - Один логический коммит на одно изменение. ## 4. Goal-driven (от цели, не от процесса) - Каждое изменение привязано к явной цели/критерию приёмки. Нет цели — не пиши. - Останавливайся на достижении цели (плато), не «дотачивай» бесконечно (анти-оверфит). - Verify решает цель, а не «код красив»: измеримый критерий > вкусовщина. ## Чеклист перед правкой (быстрый) - [ ] Сформулировал что+зачем (1-2 предложения)? - [ ] Это корень, а не симптом? - [ ] Можно проще / меньше кода / переиспользовать? - [ ] Diff минимальный, поведение сохранено, рабочее не сломано? - [ ] Есть измеримый критерий «готово»? ## Антипаттерны | Плохо | Правильно | |-------|-----------| | «Заодно отрефакторю соседний код» | только целевой diff; рефактор — отдельной задачей | | Абстракция «на будущее» (YAGNI-violation) | конкретное решение под текущую задачу | | 3-я итерация type:ignore на dead-code | STOP → корневой вопрос «зачем эта строка» | | Переписать рабочий модуль ради «чище» | additive рядом + behavior-preservation проверкой | | Дотачивать после достижения цели | остановиться на плато, зафиксировать критерий | Связь: [[feedback-root-cause-over-symptom]], [[feedback-sdd-4step-auto-adr]], ADR-013. Дополняет (не заменяет): `code-verify` (верификация), `/simplify` (built-in cleanup), `architecture-research` (дизайн-решения).