5 антипаттернов, которые превращают разработку в кошмар

Spaghetti Code

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

Как правило, этот макаронный монстр появляется из-за плохо продуманной архитектуры. Разработчик пишет код, спешит его протестировать и не особо следует правилам кодирования. Программа растет, и вы видите неряшливую структуру: разбросанные повсюду глобальные переменные, перегруженные методы и хаотично расположенные строки. Это как читать роман, в котором главы расположены не по порядку. 

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

Как избежать?

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

God Object 

Если работа значительной части кода зависит от одного объекта, то перед вами God Object, или «божественный объект». Он появляется, когда один класс «отвечает за все и сразу» — например, за имя пользователя, его фамилию, ID, сумму перевода, список покупок. В результате в системе начинает орудовать сущность, которая отвечает за все и вся.

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

Как избежать?

• Следуйте принципу единственности ответственности (англ. SRP, Single Responsibility Principle), где каждый класс решает только одну задачу. Как разделять функции, мы уже рассказывали в статье «Что такое принципы SOLID? Объясняем на котиках».
• Разбейте код на части, где подзадачами могут заниматься разные люди. Это снизит риск, что у какого-то объекта будет слишком много обязанностей.
• Постоянно обновляйте документацию. Пишите комментарии к коду. Тогда другие разработчики будут понимать, что должен и не должен делать каждый объект.
• Проводите код-ревью. Это поможет быстро заметить, если один объект отвечает за слишком многое. 
• Если «божественный объект» уже появился, проведите рефакторинг. Так вы определите конкретные обязанности объекта и сможете разделить их между разными методами. 

Boat Anchor

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

В таком подходе больше вреда, чем пользы: Boat Anchor тормозит работу и путает других разработчиков. Непонятно, какой код использовать, а какой трогать не нужно. Можно потратить часы на чтение и отлаживание бесполезных строк. В итоге время сборки увеличивается. И самый страшный вариант: если код «на всякий случай» по ошибке отправится в продакшен. Это увеличит технические риски в приложении.

Как избежать?

• Делайте рефакторинг. Самое лучшее средство борьбы с «лодочным якорем» — просто удалять неактуальные фрагменты. 
• Оставьте время для чистки таких хвостов. Учитывайте это, когда планируете разработку. 

Golden Hammer

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

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

Ну и последняя ловушка Golden Hammer: — если использовать одно и то же решение раз за разом, то можно перестать разбираться в новых методах и технологиях. В итоге Golden Hammer не упрощает работу, а лишь добавляет новых проблем. 

 Как избежать? 

• Изучите несколько решений. Сравните их между собой и выберите самый «рабочий» вариант. 
• Проводите код-ревью. Так вы заметите, если используете какой-то метод слишком часто.

Copy-Paste

Появляется, когда программист копирует когда-то написанный код — свой или чужой — и бездумно вставляет его в файл. Обычно таким методом пользуются джуниоры или интерны, которым сложно написать код с нуля или создать некоторые функции. Именно поэтому они «заимствуют» нужные куски у своих коллег или просто лезут в интернет в поиске примеров. Иногда копипастом пользуются и более опытные разработчики, которым нужно быстрее закончить проект.

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

Еще одно последствие копипаста: появляются избыточные ветви кода, которые увеличивают его размер без всякой пользы. Читать и обслуживать такую громадину будет крайне неудобно. 

Как избежать? 

• Проводите код-ревью. Чем раньше получится поймать копии фрагментов кода, тем ниже шанс, что они расползутся по всей системе. 
• Следуйте принципу Don’t Repeat Yourself (DRY). Иными словами, избегайте повторений одного и того же кода. Лучше используйте универсальные свойства и функции. 
• Проводите рефакторинг. Если видите дублированный код, вынесите его в отдельную функцию. В результате любые изменения или исправления ошибок нужно будет менять только в одном месте. 

Универсальные советы против антипаттернов 

Антипаттерн в программе — это не приговор. Если заметить проблемы в самом начале, то, как правило, код можно исправить. А чтобы и вовсе защитить свою работу и избежать ошибок, есть много способов и инструментов. Вот несколько примеров:

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