Анастасия Ербанова

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

Анастасия Ербанова

Материалы автора

Selectel представил собственные серверы. Зачем и что внутри?

8 полезных сервисов для изучения Flask

Погружаемся в Kubernetes: полезные материалы от сотрудников Selectel

«Хватит программировать в YAML и JSON!»: проблемы шаблонизирования

5 идей для pet-проектов, которые помогут прокачать навыки в Python

Как работают сети: полезные материалы от сотрудников Selectel