Чек-листы. Как Ничего не Забыть
Основная проблема разработки ПО в том, что происходит огромное количество процессов, а наш мозг не способен решать несколько задач одновременно.
Проблема не в том, что вы не знаете, как сделать, а в том, что вы забываете это сделать, хотя знаете, что должны. Простое решение - чек-листы.
Контрольный список поможет вам сосредоточиться на сложных частях вашей задачи, отвлекая внимание от разных мелочей. Однако он не должен ограничивать вас — он существует, чтобы помочь вам не забывать выполнять тривиальные, но важные действия.
Чек-листы бывают двух видов:
- Прочитал—сделал. Цель — читать каждый пункт и выполнять действия строго друг за другом.
- Сделал—отметил. Цель - выполнять действия, а затем проверять и подтверждать завершённые действия отметкой.
Например, чек-лист для новой кодовой базы:
1. Использовать Git.
2. Автоматизировать сборку.
3. Включить все сообщения об ошибках.
1. Использовать Git.
Первое, что нужно сделать в новой кодовой базе, — инициализировать локальный репозиторий Git. Рекомендация – делать это для любой кодовой базы, которая должна прожить больше недели. Вы всегда можете всё отменить, просто удалив папку .git.
2. Автоматизировать сборку.
Создайте минимальный объём кода, который сможете развернуть. Даже если у вас нет конвейера развёртывания или доступа к производственной среде. Создайте файл сценария, выполняющего сборку, и тоже отправьте коммит в Git. Например, простой .bat файл с командой:
dotnet build --configuration Release
Обратите внимание на сборку в режиме Release. Автоматизированная сборка должна отражать то, что в итоге будет запущено в производство. По мере добавления шагов сборки их следует добавлять и в скрипт.
3. Включить все сообщения об ошибках.
Старайтесь использовать предупреждения компилятора и другие автоматические инструменты — они способны находить разные проблемы с кодом. Быстро устранить сотню существующих предупреждений может быть сложно. Гораздо проще реагировать на предупреждение в момент его появления. Поэтому первое, что нужно сделать в новой кодовой базе, — включить параметр «Представлять предупреждения как ошибки». Это поможет избежать накопления любых предупреждений компилятора.
Кроме того, добавьте статические анализаторы кода, такие как Roslyn. Статический анализ кода похож на автоматизированный код-ревью. В отличие от предупреждений компилятора, статические анализаторы часто дают ложные срабатывания, но обычно предлагают разные варианты их подавления, так что не стоит их игнорировать.
Добавление проверок в существующую кодовую базу
Часто вы можете включить один тип предупреждений за раз. В существующей кодовой базе уже могут быть сотни предупреждений. Извлеките список и сгруппируйте его по типам. Выберите конкретный тип предупреждений, исправьте их, пока они ещё являются предупреждениями, чтобы можно было продолжать работу с кодом. А после превратите эти предупреждения в ошибки. Затем перейдите к другому типу предупреждений или другой части кодовой базы.
Ключевой момент — правило бойскаута: оставлять код в лучшем состоянии, чем вы его нашли.
Преимущество обработки предупреждений как ошибок в том, что вы переходите на новый уровень качества. При рассмотрении предупреждений как ошибок и включении статического анализа кода вы теряете часть контроля. Это звучит неприятно, но может стать вашим преимуществом.
Когда сверху от вас требуют «просто сделать побыстрее», т.к. «нет времени делать как положено», представьте, что вы отвечаете: «Если я сделаю так, код не скомпилируется». Даже если это будет не очень честно, вы всегда сможете утверждать, что конечная цель — это качественное ПО. Это должно быть выгодно для всей организации.
Источник: Марк Симан “Код, который умещается в голове”. СПб.: Питер, 2023. Глава 2.