Почему скорость написания кода обманчива
Программа — не разовая задача, а часть системы, которую потом приходится проверять, исправлять и менять. Поэтому результат работы разработчика — не только новые строки кода. Важны ещё и затраты на то, чтобы понять, как эти строки связаны с остальным продуктом.
Когда решение записано запутанно и его замысел нигде не объяснён, следующему человеку приходится восстанавливать его по косвенным признакам: читать соседние участки, запускать тесты, выяснять, какие случаи автор учёл. Даже сам автор со временем может забыть детали. Сэкономленные сегодня минуты способны превратиться в часы работы при следующем изменении.
Как одна спешка задерживает всю команду
Сложный участок кода становится узким местом: исправить его или добавить новую функцию может только тот, кто разбирается в его устройстве. Остальные ждут ответа или избегают трогать рискованную часть программы. Если автор недоступен, задержка увеличивается, а ошибка может остаться незамеченной.
Это не значит, что каждой строке нужны подробные комментарии. Хорошо названные функции, простая структура и тесты часто объясняют поведение лучше длинных пояснений. Документация особенно полезна там, где решение неочевидно: например, почему выбран именно такой способ обработки данных или какое ограничение нельзя нарушать.
Что считать настоящей производительностью
В разработке важно оценивать не только, как быстро человек завершил задачу, но и сколько усилий понадобится команде, чтобы поддерживать результат. Короткий срок может быть оправдан для прототипа или временного инструмента; для кода, от которого зависит дальнейшая работа продукта, читаемость и проверяемость — часть самой задачи.
Иначе команда получает не десять сэкономленных зарплат, а участок системы, который трудно менять без риска: его скорость измерялась до того, как началась работа над следующей функцией.
