Технический директор и разработчик вместе изучают legacy-код в попытках исправить баг. Мучениям нет конца, и они уже готовы сдаться. «Да кто вообще понаписал эту хрень?» — спрашивает технический директор. В раздрае чувств он смотрит в git blame. Оказывается, это он и понаписал.

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

После первых двух часов Джейк растерял весь энтузиазм, с которым приступал к делу. Он увяз в досаде, пытаясь разобраться во всех перепутанных иерархиях, которые оказались головоломнее, чем генеалогическое древо королевской семьи. Длинные методы, которые отвечают за всё понемногу. Коварные неявные параметры, таящиеся в темных углах. Он яростно сражался с порождениями мысли неизвестного гения, но всё напрасно. Сомнения и тревоги оросили его точно роса (или это просто в пот бросило?). Тот, кто это написал – незаурядный ум или просто сволочь какая-то? Legacy-код Джейку совсем не понравился. Его стиль программирования не вписывался в кодовую базу. Пока он пытался разобраться, что в ней происходит, прозвенели все известные звоночки. Просто ужас какой-то. Нужно немедленно всё переписать.

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

Что ж, такие чувства нормальны. И всё же, вы определенно не знаете контекста, в котором человек принимал эти решения. Постарайтесь понять его мотивы, прежде чем судить и ударяться в гордыню. Возможно, из-за сжатых сроков приходилось срезать углы. Если речь о стартапе, то техническим долгом команда займется, когда пройдет самая горячая пора. Не исключено, что для продолжения проекта нужны инвестиции, дело обычное. Бывает и другая причина: всё начиналось просто, но из-за требований пришлось сменить курс в сторону большей сложности – все другие варианты на тот момент были еще хуже, а этот представлялся оптимальным по скорости и затратам. Возможно, новомодные технологии не использовались, потому что тогда еще работали нестабильно, а альтернатив не было. Какие еще могут быть объяснения? Чье-то самомнение? Как ни печально, это распространенная причина. А может, человек просто не знал, как сделать лучше. Это тоже еще не преступление. Как говорил мой коллега:

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

Можно возмущаться сколько угодно, однако переписывать всё с нуля – слишком затратная и рискованная затея. На одном из проектов, в котором я был задействован, разработчики решили, что кодовая база – помойка, с которой нельзя мириться. Мы шумели, негодовали и отказывались брать на себя ответственность, пока нам не дадут всё полностью переписать. В любом баге оказывались виноваты кодовая база и жесткие сроки, но никак не мы. Мы наделали достаточно шума и получили разрешение всё переписать. Да, я, кажется, забыл упомянуть, что это был стартап, который отчаянно нуждался в инвестициях. Разумеется, на полпути денежный поток иссяк, и у нас кончилось финансирование. Но зато теперь мы делали всё по правилам и ко дну пошли тоже по правилам.

Конечно, с убогой кодовой базой работать утомительно и тяжело. Молодые разработчики редко обладают навыком сопротивления искушению переписать всё чужое. Вместо того, чтобы разобраться в проблеме и понять клиента, они хотят показать, на что способны, и забывают про назначение проекта.

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

Если всё правда очень плохо, укажите на конкретные недостатки и объясните, почему считаете их недостатками. Как их исправление повлияет на бизнес? Составьте краткосрочные и долгосрочные планы усовершенствований, которые приносили бы какую-то ценность. И не забывайте: следующий раз, когда придется в спешке тушить пожары, может наступить в любой момент. Не бойтесь срезать углы, здесь главное ясно дать понять, что нужно будет вернуться к этому фрагменту и внести правки. В конце концов, люди толстеют не от того, что едят много торта на праздниках, а от того, что немного его переедают каждый день.