"... Леня, бедняга, сидит и день за днем мучительно, до
помутнения в мозгах, взвешивает на внутренних весах своих, как будет
точнее сказать: "она тронула его руку" или "она притронулась к его
руке"... И в отчаянии он звонит за советом Вале, и жестокий Валя
Демченко, не теряя ни секунды, отвечает ему знаменитым аверченковским:
"Она схватила ему за руку и неоднократно спросила, где ты девал
деньги..."
— Стругацкие, "Хромая судьба"
Последние пару месяцев веду проект по разработке с тремя очень талантливыми программистами. Иногда на архитектурных брифингах парни начинают яростно спорить о вещах, с моей точки зрения, яйца выеденного не стоящих. Например, можно ли в юнит тестах инициализировать тестовые данные при инициализации базы либо же в каждом из тестов нужно все заново удалять и пересоздавать. Или же - не стоит ли выбросить из стайл-чекера правило, запрещающее ПЕРЕМЕННЫЕ_ТИПА_ТАКИХ, чтобы можно было константы описывать по-старинке.
Стоят значит у доски четыре человека и до хрипоты спорят. Могут час-полтора так простоять, приводя друг другу всякие аргументы. Иногда меня тоже вовлекают и уже я с ужасом обнаруживаю себя, яростно чего-то доказывающего, ломающего копья. Как минимум раз в неделю такое. 16 человеко часов в месяц уходит, а за 16 человеко часов можно, в общем-то, дофига полезного сделать.
Обнаружил, что у меня в голове ползунок, стоящий между "Мега-красивый-идеальный-сверкающий-кодом" и "Кодом, прагматично реализующим требования" стоит процентах на 60
(и то, потому что мы пишем фреймворк, и API в нем - важен. В обычном же проекте, я придерживаюсь баланса где-то на 70-80 процентов, то есть ратую за код скорее прагматичный, чем красивый.
Почему? Потому что 2011 год на носу, все IDE умеют рефакторинг, за юнит-тестами мы
следим а времени на реализацию функционала, как всегда, не хватает. Поэтому тратить
4 часа в неделю на решение проблемы тысячелетия: как написать "притронулалсь" или "тронула", мне элементарно жалко. Потом переделать можно.
Постскриптум:
Есть при этом вещи, в которых я считаю дотошность при кодировании оправданной.
Навскидку,
- API сервисов (потому что язык API будет потом
сильно влиять на производительность прикладных программистов, он должен быть "в тему")
- Разделение кода на артефакты (потому что лишние зависимости порождают плохой код, а переделывать костяк системы дольше, чем нормально сделать сразу)
- Документирование нетривиальных и нечитаемых кусков кода (потому что таких кусков мало,
и всегда есть множество причин, по которым код сделан нечитаемым, и причины эти
нужно донести до людей, которым этот код в будущем придется менять)
