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