Главные злодеи в программировании: как их победить. Рассказываем об антипаттернах при написании кода

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

Используйте навигацию, чтобы выбрать интересующий раздел:

→ Spaghetti Code

→ God Object

→ Boat Anchor

→ Golden Hammer

→ Copy-Paste

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вы замечали какие-то антипаттерны в своем коде? Поделитесь ответами в комментариях.