Когда электрик заканчивает работу в квартире, Вы видите аккуратные розетки и выключатели. Свет горит, чайник кипит, всё работает. Но настоящее качество его работы спрятано в стенах. Там может быть аккуратная разводка с правильным сечением кабеля, распределительные коробки и схема, по которой любой другой электрик через десять лет найдёт нужный провод. А может быть клубок скруток, замотанных изолентой, который однажды загорится. Снаружи обе квартиры выглядят одинаково.
С программным кодом то же самое, только стены ещё толще. Заказчик видит экраны и кнопки. Если они работают, кажется, что всё хорошо. Менеджеры, которые немного разбираются в разработке, знают волшебные слова: DRY, SOLID, тесты. Их требуют, и это правильно. Но это как требовать от электрика «использовать провода». Очевидно, необходимо, недостаточно. Ниже я расскажу, что требую от разработчиков сам, кроме очевидного, и почему.
Сначала про очевидное, и почему его мало
DRY, «не повторяйся», хороший принцип. Но я видел, как его доводят до абсурда: два похожих куска кода объединяют в одну хитрую универсальную функцию с десятью параметрами, а потом любое изменение в одном месте ломает другое. Иногда небольшое дублирование дешевле неудачной абстракции. Тесты тоже бывают для галочки: покрытие девяносто процентов, а проверяют они то, что и так никогда не сломается. Поэтому сами по себе эти слова ничего не гарантируют. Важно, понимает ли команда, зачем это нужно.
Код пишется для следующего человека
Первое, что я требую: код должен быть понятен человеку, который придёт после. Не автору, автор и так всё помнит, по крайней мере первые пару месяцев. А новому разработчику, который откроет проект через год, когда автор уже уволился. Понятные названия, понятная структура, комментарии там, где логика неочевидна, и особенно там, где решение странное, но на то были причины.
Отличная проверка: может ли новый человек развернуть проект у себя и запустить его за пятнадцать минут, читая только README? Если для этого нужно неделю ходить за старожилами и выяснять, какую версию чего поставить и какой файл где взять, то проект держится на устной традиции. Как племя, у которого нет письменности: пока жив шаман, всё в порядке.
То, что не видно, пока не случится беда
Есть вещи, которые не замечаешь, пока всё хорошо, и без которых катастрофически плохо, когда что-то идёт не так. Я отношу к ним:
- Логи. Когда клиент говорит «вчера в обед всё сломалось», должна быть возможность посмотреть, что именно произошло, а не гадать.
- Мониторинг. О проблеме должна узнавать команда, а не клиент. Если о падении сайта Вы узнаёте из звонка покупателя, мониторинга нет.
- Миграции базы данных. Любое изменение структуры данных оформлено как воспроизводимый шаг, а не как ручной запрос, который кто-то когда-то выполнил на сервере.
- Резервные копии, которые проверяли. Бэкап, из которого ни разу не пробовали восстановиться, это не бэкап, а надежда.
- Секреты не в коде. Пароли и ключи доступа не лежат в репозитории, даже в приватном.
Обо всём этом я подробно писал в статье про нефункциональные требования, о которых все забывают. Коротко: это фундамент и проводка. Их не видно, но именно от них зависит, простоит ли дом.
Хороший код отличается от плохого не тогда, когда всё работает, а тогда, когда что-то сломалось.
Гигиена процесса
Повар в хорошем ресторане убирает за собой по ходу работы, а не в конце смены. На кухне это называется mise en place: всё на своих местах. В разработке есть своя гигиена, и она многое говорит о команде.
Небольшие коммиты с осмысленными сообщениями, по которым через год можно понять, что и зачем менялось. Ревью кода, где хотя бы ещё один человек посмотрел изменения до того, как они попали в рабочую версию. Записанные архитектурные решения: почему выбрали эту базу данных, а не другую, почему этот сервис отделили. Через два года никто не вспомнит, а без этого знания любая переделка превращается в археологию.
Человеческие требования
И последнее, о чём редко пишут в стандартах. Я требую от разработчиков честности в оценках и ранних сигналов о проблемах. Фраза «я застрял, нужна помощь», сказанная на второй день, стоит в десятки раз дешевле, чем «не успел», сказанное в день дедлайна. Это не про код, но это влияет на проект сильнее любого паттерна.
И ещё я ценю, когда разработчик думает о продукте, а не только о задаче. Когда он может сказать: «Эту функцию можно сделать, но вот так будет проще для пользователя и дешевле в поддержке». Такой человек стоит дороже, и он того стоит.
Что сделать завтра
Задайте своей команде или подрядчику пять вопросов. Сколько времени нужно новому человеку, чтобы запустить проект? Где посмотреть, что произошло в системе вчера в 14:00? Как мы узнаем, если сайт упадёт ночью? Когда последний раз проверяли восстановление из резервной копии? Где записано, почему архитектура устроена именно так? Если на большинство вопросов ответы уверенные и короткие, у Вас хорошая проводка. Если в ответ звучит «ну, это надо у Саши спросить», самое время вскрыть стену, пока ничего не загорелось.
