Крошечная привычка, которая тихо убивает баги до релиза

Большинство багов возникает не из‑за незнания.

Они возникают из‑за спешки.

Вы знали, что нужно обработать пустой массив. Вы собирались добавить проверку ошибки. Вы планировали написать ещё один тест. Но вовремя пришло сообщение в Slack, начался стендап — и ваш недоделанный коммит уехал в main.

Этот пост — про смешно маленькую практику, которая служит последним «quality gate» перед тем, как ваш код попадёт в репозиторий:

Одно-заметочный толчок перед коммитом — субминутный, одно‑заметочный ритуал перед коммитом, который заставляет вас притормозить, пробежаться по типовым источникам багов и облегчить жизнь себе в будущем.

Это не инструмент, не фреймворк и не реформа процесса. Это крошечный чек‑лист + чуть более медленный поток коммита, которые тихо могут урезать ваш дефект‑рейт очень заметно — во многих командах подобные практики убирают более половины предотвращаемых багов.

Зачем вам ритуал перед коммитом (даже если вы «и так всё это знаете»)

Вы уже видели эти «best practices»:

• Обрабатывать null и пустые входные данные
• Думать об edge‑case’ах
• Проверять ошибки и неуспешные сценарии
• Писать осмысленные сообщения к коммитам

Проблема не в том, что вы их не знаете. Проблема в том, что вы о них не вспоминаете в момент, который важен больше всего — прямо перед тем, как ваш код становится частью истории репозитория.

Ритуал перед коммитом делает три важных вещи:

1. Создаёт паузу. Ломает автопилот «написал → закоммитил → запушил».
2. Вытаскивает на поверхность то, что вы забыли. Короткий чек‑лист напоминает о невидимых сценариях отказа.
3. Оставляет след. Нормальные сообщения к коммитам документируют ваши допущения, компромиссы и потенциально рискованные места.

В разрезе одного дня это выглядит мелочью. В разрезе месяцев это складывается в заметно более чистую кодовую базу.

Одно-заметочный чек‑лист: ваш последний фильтр багов за секунду до коммита

Вам не нужна wiki, PDF или корпоративная инициатива.

Вам нужна одна заметка.

Откройте приложение для заметок или создайте PRE_COMMIT.md в репозитории и добавьте короткий список, например такой:

Pre-Commit Nudge

1. Inputs & edge cases checked?
   - null / undefined / None
   - empty string / list / collection
   - weird sizes (0, 1, max, huge)

2. Errors & failures handled?
   - what happens on network/db/IO failure?
   - do we log or surface meaningful errors?

3. Performance okay for realistic scale?
   - any obvious N+1 loops or O(n^2) on big sets?

4. Clean code pass?
   - names clear?
   - functions small and focused?
   - responsibilities well-separated?

5. Quick debug/verification?
   - targeted tests run?
   - invariants asserted?
   - failure paths walked through mentally?

6. Commit message ready?
   - clear “why”, assumptions, trade-offs?

Вот и всё. Это и есть ритуал.

Перед каждым коммитом загляните в эту заметку и мысленно пройдитесь по каждому пункту. На мелкие изменения должно уходить меньше минуты, на крупные — пару минут.

Речь не о перфекционизме. Речь о том, чтобы отловить те самые 20% проблем, которые создают 80% боли в проде.

Заставляем редактор включать вам «тормоза»

Проще всего выработать привычку, если инструменты начинают вас чуть‑чуть замедлять.

Вместо того чтобы коммитить с сообщением прямо в командной строке, используйте поток через редактор:

git commit

Git откроет ваш настроенный редактор (VS Code, Vim и т. д.) и создаст пустой файл для сообщения коммита. Это даёт два эффекта:

1. Вы вынуждены остановиться и подумать. Больше никакого git commit -m "fix" на мышечной памяти.
2. Вы уже в редакторе. Значит, проще держать ваш одно-заметочный чек‑лист открытым в соседней вкладке или сплите.

Рекомендуемая раскладка:

• Левый экран: diff ваших изменений
• Правый экран: ваш PRE_COMMIT.md (или заметка) + файл с сообщением коммита

Теперь ваш поток выглядит так:

1. Проиндексировать изменения (git add).
2. Запустить git commit.
3. Бегло пройтись глазами по чек‑листу.
4. Написать понятный заголовок и описание коммита.
5. Сохранить файл и закрыть редактор, чтобы завершить коммит.

Это небольшое трение — фича, а не баг. Вы покупаете себе несколько секунд на размышления в обмен на часы будущего дебага.

Относитесь к сообщению коммита как к мини‑код‑ревью

Большинство сообщений к коммитам бесполезны:

• fix bug
• update stuff
• changes

Они ничего не говорят о том, почему изменился код, чего вы опасались и где спрятаны неочевидные допущения.

Вместо этого относитесь к каждому сообщению как к короткому, одиночному код‑ревью:

Заголовок (50–72 символа):

«Обработать пустой поисковый запрос без вызова API»

Тело:

• Зачем понадобилось изменение
• Какой подход вы выбрали
• Допущения и компромиссы
• Возможные зоны риска или отсутствующие тесты

Пример:

Handle empty search queries without calling API

- Short-circuit search handler when query is empty
- Return empty result set immediately instead of API call
- Assumes empty query should not hit backend (confirmed with PM)
- Trade-off: we no longer log empty queries in analytics
- Missing: edge-case test for whitespace-only queries (TODO)

Обратите внимание, что это даёт:

• Будущий вы мгновенно видит намерение.
• Скрытые допущения задокументированы.
• Известные пробелы честно помечены.

Через несколько недель, когда всплывёт баг («Почему пустые запросы не попадают в аналитику?»), вы не начинаете расследование с нуля. У вас уже есть контекст решений и компромиссов.

Вшиваем best practices прямо в чек‑лист

Лучшее время, чтобы применять практики качественного кода, — прямо перед тем, как ваш код станет частью истории.

Добавьте в свой одно-заметочный ритуал проход по «clean code»:

• Именование

  • Каждое имя функции/переменной понятно говорит, что оно представляет?
  • Используете доменную лексику, а не расплывчатые data, info, handle?

• Маленькие функции

  • Нет ли функции, которая пытается сделать 3–4 вещи сразу?
  • Можно ли вынести одну маленькую, хорошо названную helper‑функцию?

• Чёткие зоны ответственности

  • Не делает ли модуль/функция одновременно I/O, бизнес‑логику и форматирование?
  • Можно ли разнести ответственность по более ясным границам?

Не нужно на каждом коммите рефакторить всю систему. Важно, чтобы ваши изменения не добавляли нового хаоса и сложности.

Подход такой: никакого нового мусора.

Проактивный проход по отладке: сначала упадите в голове

Большинство разработчиков мысленно проигрывают счастливый путь.

Ваш ритуал перед коммитом — напоминание уделить такое же внимание путям отказа:

• Что если здесь вернётся null?
• Что если API подвиснет или вернёт битые данные?
• Что если вход — гигантский (10 000 элементов, а не 10)?
• Что если эту функцию вызывают в плотном цикле?

Превратите это в быстрый проактивный отладочный проход:

1. Запустите целевые тесты

   • Юнит‑тесты затронутых функций
   • Пару интеграционных тестов, которые задействуют новое поведение

2. Добавьте или проверьте инварианты

   • Ассерты вроде: id никогда не null, длины массивов совпадают, состояние консистентно
   • Guard‑клаузы в начале функций для невалидных входных данных

3. Мысленно пройдитесь по путям отказа

   • Представьте, что БД недоступна — что увидит пользователь?
   • Представьте, что не хватает конфига — вы падаете или деградируете плавно?

Это занимает 30–60 секунд, но работает удивительно эффективно:

• Вы находите пропущенные проверки раньше пользователей.
• Вы осознаёте, каких тестов ещё не хватает.
• Вы усиливаете код в самых слабых местах, а не там, где проще всего.

Как субминутный ритуал приводит к меньшему количеству багов

Потратить лишние 30–60 секунд на каждый коммит вроде бы звучит как оверхед.

На практике это один из самых выгодных вложений в качество кода:

• Многие команды обнаруживают, что простые чек‑листы + нормальные коммиты режут количество дефектов на 50–80%.
• Те баги, что всё же прорываются, проще отследить, потому что сообщения к коммитам фиксируют ваши допущения.
• Код остаётся более поддерживаемым, потому что вы на каждом коммите переосмысливаете имена, структуру и зоны ответственности.

Это компаундинг в действии:

• Сегодня вы предотвращаете один null‑pointer.
• Завтра избегаете N+1‑проблему с производительностью.
• На следующей неделе ваша ясная история коммитов превращает трёхчасовое расследование в 10 минут.

Никакого нового инструмента. Никакого тяжёлого процесса. Просто маленькая, но постоянная пауза.

Как начать уже сегодня (и не слиться через два дня)

Внедрить одно-заметочный толчок перед коммитом можно за 10 минут:

1. Создайте свой одно-заметочный чек‑лист

   • Возьмите пример выше или адаптируйте под типичные источники багов в вашей команде.

2. Переключитесь на коммиты через редактор

   • Настройте редактор: git config --global core.editor "code --wait" (или ваш любимый).
   • Начните использовать git commit без -m, чтобы всегда открывался редактор.

3. Держите заметку на виду

   • Закрепите её в редакторе.
   • Или держите PRE_COMMIT.md открытым в сплите.

4. Обещайте себе 7 дней

   • В течение недели используйте ритуал перед каждым коммитом.
   • В конце недели выпишите баги и недочёты, которые вы поймали только потому, что притормозили.

Почти наверняка вы найдёте хотя бы один баг или дизайн‑изъян, который иначе бы уехал в репозиторий. Это и будет вашим доказательством, что метод работает.

Итог: минимальный процесс с максимальной отдачей

Чтобы писать более качественный код, вам не нужен новый методологический фреймворк.

Вам нужна крошечная, повторяемая пауза, которая задаёт вопросы:

• Обработал ли я странные и пограничные входные данные?
• Подумал ли я об ошибках и отказах?
• Этот код ясен, небольшой и читаемый?
• Я проверил критические пути?
• Я объяснил, зачем вообще это изменение?

Одно-заметочный толчок перед коммитом — это именно такая пауза.

Одна заметка. Одна минута. Одна маленькая привычка, которая со временем не пускает в ваш репозиторий поразительно много будущих багов — и спасает будущего вас от проклятий в адрес прошлого себя в git blame.

Начните со следующего коммита.