Или почему не стоит жаловаться на старый код

Я часто слышу жалобы, особенно от новичков, по поводу кода, в котором они находятся. Все они обычно сводятся к тому, что старый разработчик был глуп, а этот код - отстой. Или иногда они больше похожи на Мы должны выследить старого разработчика и сжечь его на костре. Пишу это, чтобы спасти старого разработчика от ужасной участи.

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

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

Понять, почему старый код был плохим

«Ого, посмотрите на этот код, он ужасен. Он преобразует X в Y и помещает его в коллекцию типа Z ».

«Почему он это делает?»

"Я понятия не имею."

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

Решить проблемы контекста легко, если вы используете систему управления версиями, такую ​​как Git. Git винит этот код и выясняет, как он выглядел, когда был написан. Изменения со временем могут превратить необходимый код в лишний или совершенно запутанный. Часто добавление контекста того, как выходные данные этой функции используются в другом месте, может помочь вам понять, является ли это важным, и может помочь устранить класс ошибок, проистекающих из «Я думал, что строка xx больше не нужна».

На мой взгляд, отсутствие понимания доставляет гораздо больше удовольствия, потому что это означает, что мы узнаем что-то новое. Если вы не знаете, что делает строка кода, то сейчас отличное время, чтобы поискать в Google и выяснить это. Если код находится на критическом пути к тому, над чем вы работаете, то это абсолютно важнее, чем сэкономить час, замалчивая детали кода. Если вы новичок в кодовой базе, это может быть шаблон, который вы увидите в будущем, или, даже если вы не новичок, вы можете увидеть его элементы, повторно используемые в будущем. Понимание сейчас - это строительный блок для быстрой итерации вашего следующего проекта.

Но что, если вы уверены, что код плохой?

Исправить неверный код

Это должно быть довольно очевидно, но это определенно непросто. Если код, который вы видите, на самом деле представляет собой крушение поезда, это может быть довольно интересно наблюдать, но вы не хотите садиться туда и собирать поезд. Это самая сложная часть. Но это заставит вас расти. Может быть, это даже приблизит вас к тому мифическому 10-кратному разработчику.

Оставьте после себя поток хорошего кода. Иногда исправление плохого или устаревшего кода - очень быстрая победа. Вы даже можете просто удалить его (в этом случае это, вероятно, действительно хороший код).

Я не говорю вам, что вы должны стараться изо всех сил и проводить рефакторинг целых проектов, чтобы исправить ошибку за один час. Я просто призываю вас прекратить вторжение энтропии в кодовую базу, чтобы вы могли, надеюсь, предотвратить возможную тепловую смерть всех ваших сервисов.

Не забывайте, что вы старый разработчик

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

Это может быть одно из мест, где можно применить мантру «младший разработчик на всю жизнь». Не решайтесь делать выводы о компетенции старого разработчика и предполагайте добрые намерения. Да, иногда код плохой, а его автор неквалифицирован, потому что компании могут упустить разработчиков, но часто этот мерзавец указывает на кого-то из ваших коллег. (Кроме того, используйте git blame, чтобы получить контекст кода, а не обязательно отслеживать ошибки всех ваших коллег).

Предположение, что весь плохой код является признаком некомпетентности, - быстрый способ вызвать недоверие среди разработчиков. «Разработчик Джек написал эту ужасную ошибку в 2012 году, поэтому он, должно быть, не очень хорош» - это просто нездорово. Ваши коллеги заботятся о написании хорошего кода. Они не являются частью какого-то зловещего заговора, чтобы разбудить вас посреди ночи 5 лет спустя, когда что-то сломается.

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