Самый ужасный код, который когда либо встречал

Когда мне говорят, что нужно рефакторить какой-то плохой участок кода, мне интересно, насколько сильно он подходит под определение мной однажды виденного и ставшего образцом, скажем так совершенного и идеально ужасного кода. Этот образчик наблюдал в средней известности компании и проекте, последний в своём роде был очень даже ничего по популярности. Но секрет его популярности был в том, что он один из первых занял нишу и в ней удерживался. Он был изначально сделан на Symfony 2 и какой-то древней версии PHP, кажется пятой, но далее перечислю нюансы по которым его почти невозможно было перевести на другую версию фреймворка и языка программирования.

• Огромные контроллеры. Когда открываешь такой файл в редакторе на обычном мониторе, то справа малюсенькая черточка, показывающая область текущего окна, а остальное крутить можно почти бесконечно. Это был не один или два файла, а принцип создания контроллеров в проекте.

• Если так же рассматривать код в IDE, то кроме удручающе маленькой полоски, описанной выше, можно наблюдать вертикальный частокол красных линий и даже областей. Это ошибки в неиспользуемых методах и частях кода, ими пестрили также неиспользуемые ответвления if, которых было множество, порой даже было удивительно, как это работало.

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

• Легаси. За восемь лет даже заставший те времена программист уже не помнил, что там было задумано, так что обратиться к нему за консультацией не вышло бы. Кроме того, отсутствовали какие-либо практики ревью и код отправлялся сразу на рабочий сервер.

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

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

• Разумного размера контроллеры. Желательно не размещать там логику.

• В коде не должно быть закомментированных частей (историю проекта лучше хранить в git), неиспользуемых участков и видимых в IDE ошибок (по крайней мере ошибок компиляции, тут IDE редко ошибается).

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

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

• Задумки по новым продуктовым усовершенствованиям должны проходить сравнение своей полезности по отношению к дополнительной нагрузке на сайт, которые они окажут.

PS Сейчас не знаю, насколько упомянутый сервис популярен, пробыл в компании недолго. В то время у меня было мало опыта работы с производственным кодом, а еще учитывая, что коллеги работали давно и воспринимали такой код как данность, казалось, что это везде так, ну плюс-минус. Но потом взяли еще одного программиста со стажем, он денёк посмотрел на это всё, глаза округлились и он к вечеру покинул компанию. С этого момента я и задумался, что-то тут не так)