Недавно на работе получил в личку занятный вопрос по одной из встреч: «А что там час обсуждать? Там же всего одна апишка».
Помню, что этот вопрос меня ошарашил. Даже опуская риски и скрытую сложность, я сам навскидку мог задать три спорных вопроса об этой «всего одной апишке». Потому что в прошлом я был хорошим разработчиком. А хороший разработчик должен быть дотошным.
Почему разработчики такие душные
Разработчик — это алхимический перегонный куб бизнеса. Он превращает бизнес-требования в работающий продукт, который, я надеюсь, приносит деньги.
Чтобы корректно реализовать нужное пользователям поведение, приходится задавать сложные вопросы и собирать полную картину. Код требует детерминированной логики: неясность в требованиях не исчезает после начала разработки, а превращается в случайно выбранное поведение, переделки или баги.
Быстрый груминг не всегда хороший знак
Меня настораживают ситуации, когда обсуждение задачи пролетает под лозунгом «да тут всё понятно». Часто проблемы обнаруживаются уже после того, как решение написано и цена уточнения выросла.
Само отсутствие вопросов ничего не доказывает: причин может быть много. Точно так же и длинный груминг не является автоматическим признаком профессионализма. Если команда часами обсуждает несущественные детали и не приближается к решению, процесс нужно чинить.
Профессионализм не в том, чтобы душнить как можно дольше. Он в том, чтобы найти именно те детали, от которых зависят поведение системы, стоимость решения и риск переделки. Поэтому куча вопросов на груминге может быть признаком сильной команды — при условии, что ответы действительно помогают принять решение.
«Просто добавим параметр»
Один из моих любимых примеров микрорешения - новый параметр функции для особого случая. Иногда параметр действительно остаётся самым простым вариантом. Но он должен заставить инженера остановиться и проверить последствия.
Новый флаг может означать, что функция теперь отвечает за два разных поведения. Компонент начинает обслуживать ещё один сценарий, обрастает зависимостями, ветвлениями и дополнительными тестами. Если такие случаи продолжают накапливаться, маленькая уступка постепенно превращается в хрупкую универсальную абстракцию.
Проблема не в любом параметре. Проблема начинается, когда фраза «там всего один параметр» заменяет разговор об ответственности компонента и о том, как разные сценарии будут развиваться дальше.