«Кто написал это дерьмо?», спросил СТО, глядя на свой старый код. Или как работать над «хромой» кодовой базой и не выгореть

На Medium вышел философский блог о сложностях рефакторинга, отчаянии, порывах переписать «говнокод» с нуля и прочих сопутствующих трудностях, а также практические советы, как привести кодовую базу в порядок. Публикуем перевод.

Кто написал это дерьмо?

СТО и разработчик изучают устаревшую кодовую базу, чтобы исправить ошибку. Мучения уже стремятся к бесконечности, они готовы сдаться.

«Кто написал это дерьмо?», — спросил технический директор. Взволнованный, он проверил, кто этот мерзавец. Им оказался он сам.

***

Познакомьтесь с нашим героем Джейком. Он разработчик, только что нанятый на проект, которому уже шесть лет. Джейку дали задачу исправить ошибку, для чего придется погрузиться в глубины устаревшего кода. Он вооружился знаниями и контекстом и нырнул в кодовую базу. Все должно решаться легко. В конце концов, это же задача для адаптации на проекте. Что может пойти не так? (Звучит адский смех).

После первых двух часов Джейк исчерпал весь свой энтузиазм. Он увяз в паутине разочарования, пытаясь разобраться во всех смешанных иерархиях — сложнее, чем королевское фамильное древо в средневековой Европе, длинных методах, которые делают много разных вещей, и калечащих implicits, спрятанных в темных углах.

Он яростно боролся со всей этой гениально нагроможденной свалкой кода, но тщетно. Сомнение и тревога покрыли его, как утренняя роса, или это все-таки был пот? Тот, кто это написал, гений или просто мудак? Джейку совсем не нравился этот код. Кодовая база не соответствовала его стилю кода.

«Это ужасно. Надо переписать это немедленно», — решил Джейк.

Все мы немного Джейк

Большинство разработчиков были там, где и Джейк. Они испытывали желание переписать что-то, что не соответствует их представлениям о коде. Все, что вы видите в базе, это кощунство над чистым кодом. Вам не терпится бросить еще один камень в уже разбитое окно – не для чего, просто назло. Ведь как вообще возможно адаптировать этот ужасный стиль кода и внести исправления?

Это нормально – чувствовать себя таким образом. Но нужно учитывать факт, что вы не знаете контекста, почему разработчик принял именно такие решения. Постарайтесь понять, что скрывается за мотивом, прежде чем строго судить, уймите свое эго. Возможно, у команды был плотный график, из-за которого пришлось срезать путь. Если это стартап, разработчики могли оставить технический долг, чтобы закрыть его позже, после «горячей фазы» работы, когда срочно нужно что-то показать инвесторам для продолжения проекта (это распространенное явление).

Другая причина может заключаться в том, что команда разработки начинала с простого, но нарастающие требования заставили их приблизиться к чему-то более сложному. И она использовала самый простой на тут момент подход, оптимизированный по стоимости и скорости. Может быть, разработчики не использовали какую-то сверхпопулярную технологию, потому что в то время она была недостаточно стабильной, не было альтернатив.

Что еще может быть причиной? Чья-то самоуверенность и желание испортить настроение тому разработчику, который в будущем будет копаться в этом коде? Как ни печально, не высокомерие является общей причиной «хромой» кодовой базы. Разработчики просто не знали выхода лучше. Ведь это не грех. Каждый пишет лучший код, который может на данный момент, учитывая все обстоятельства.

Спасет ли переписывание ситуацию?

Обычно переписывать все с нуля слишком дорого и рискованно. Можно получить шанс все переделать, написать по правилам, и тут же потерпеть неудачу, потому что тратил много времени не на то, что проекту действительно нужно.

«Я работал над проектом, который мы, разработчики, считали невыносимым из-за хаоса в кодовой базе. Мы плакали, жаловались и отказывались брать на себя ответственность, просили полностью переписать систему. В каждой ошибке мы винили кодовую базу, плотный график, но не себя. Мы достучались до руководителей и получили возможность все переписать. Я забыл сказать вам, что это был стартап, который отчаянно нуждался в инвестициях? Конечно, на полпути стартап потерял импульс для привлечения инвестиций, и у проекта закончилось финансирование», — рассказывает автор.

Конечно, работа над хромой кодовой базой сложна и утомительна. Сопротивляться желанию переписать то, что писали не вы, — навык, которым редко обладает молодой разработчик. Вместо того, чтобы понять проблему или запрос клиента, вы хотите доказать что-то себе вроде «а я бы сделал лучше». Просто примите ситуацию: что бы вы ни делали, в кодовой базе всегда будет дерьмо.

Чек-лист при работе с кодовой базой

Итак, что вы можете сделать, чтобы улучшить ситуацию?

• Для начала: не жалуйтесь. Никто вокруг не хочет это слушать, как и разработчики не хотят слушать, что они устроили бардак в базе. Вам бы это тоже не понравилось.
• Возьмите за правило оставлять после себя порядок после каждого посещения. Почините «разбитое окно», когда есть время, научите это делать и других.
• Добавьте тест перед исправлением ошибки, и через какое-то время вы будете более уверенно что-то менять или рефакторить. Покажите всем пример, что вот так по крупицам, но вы все можете внести свой вклад и сделать кодовую базу лучше, опрятнее. Это не произойдет в одночасье, но через какое-то результат станет заметнее.
• Мотивируйте коллег — объясните, что это упростит вам дальнейшую работу, будет полезнее для бизнеса в целом и т. д.
• Составьте краткосрочный и долгосрочный план того, что вы могли бы улучшить в базе.
• «Пожар» на проекте, когда срочно нужно что-то зарелизить и для этого потребуется «срезать путь», может произойти в любое время. Поставьте перед собой (и командой) задачу вернуться и навести в коде порядок после того, как «пожар» закончится.

Что думают айтишники

Разработчики на Reddit признались, что у всех были такие моменты, когда смотришь на свой код и понимаешь — «ну ересь какая-то». Однако, когда писали его, он не казался таким странным и непонятным. А теперь даже подсказки, оставленные «себе будущему», не помогают.

Они начали активно делиться историями из своего опыта.