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

02 Мая 2023 (ред)

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

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

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

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

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

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

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

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

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

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

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

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

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

3 Ответа

  1. BahtSim BahtSim 03 Мая 2023

    A вот в интерпретации ChatGpt

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

    Первое, что я делаю при получении кода, это провожу его анализ. Я проверяю, соблюдены ли основные принципы ООП в коде, существуют ли DRY (Don't Repeat Yourself) и SOLID (Single Responsibility Principle, Open-closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle) принципы, как проводится работа с БД, как реализованы операции вывода и ввода данных, насколько грамотно использованы переменные, как организованы структуры данных и т.д. Если код содержит ошибки и нарушения, я начинаю вносить исправления, используя правильные методы и стандарты.

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

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

    В конце концов, я предлагаю всегда оставаться на связи со своими коллегами и клиентами, чтобы получать обратную связь и советы. Будьте готовы к конструктивной критике и признавайте свои ошибки. Программирование – это процесс обучения и постоянного самосовершенствования. Берите на себя ответственность за качество своего кода и не останавливайтесь на достигнутом.

    Таким образом, важно понимать, что работа со сложным, плохо написанным кодом – это не проблема, а возможность для развития и приобретения новых знаний. Следуя некоторым простым правилам и советам, можно значительно улучшить свои навыки и стать настоящим профессионалом в области программирования на PHP.

  1. fomiash fomiash 03 Мая 2023

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

  1. fomiash fomiash 07 Октября 2023

    Недавно читал перепалку программистов, что преимущество Symfony перед другими PHP-фреймворками как раз в том, что Symfony не позволяет писать "плохой" код. Как раз описанный выше проект на этом фреймворке, что показывает, что фреймворк не может повлиять на качество кода разработчика, и дело совсем не в инструментах, а какие руки эти инструменты держат.



Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.