Что такое спагетти-код (spaghetti code)

Так программисты говорят про сложный и непонятный код. Разобраться в нём могут только те, кто его писал… и то не всегда. Такой код напоминает вареные спагетти. Если их положить на тарелку, то непонятно, где начало, а где конец.

Как появился термин spaghetti-code

Ученый Эдсгер Дейкстра первым использовал этот термин. В 1968 году он написал статью «Доводы против оператора GOTO». Профессор смеялся, что программисты используют оператор GOTO и из-за этого получают неясный и запутанный код. В те времена IT-специалисты часто работали на языках Fortran, ассемблер и COBOL. Тогда не было стандартов или четкой структуры, как правильно писать код. Поэтому, программы были очень запутанными, их было трудно понять. Спагетти-код еще встречается в старых программах, но сейчас программисты стараются сразу писать чистый и понятный код.

Причины возникновения спагетти-кода

Есть несколько причин, почему получается спагетти-код.

• Спешка и дедлайны. Когда горят сроки, разработчик пишет код, просто «чтобы работало». О качестве думать некогда. Главное — запустить программу, а потом как-нибудь разберемся. Например, стартапу нужно срочно выпустить новую фичу и программист просто добавляет временные решения. И код выглядит так:
  

  def process_order(order):
if order["status"] == "new":
confirm_order(order)
elif order["status"] == "pending":
if order["payment"] == "ok":
confirm_order(order)
elif order["payment"] == "fail":
cancel_order(order)
else:
send_reminder(order)
elif order["status"] == "confirmed":
if order["shipping"] == "delivered":
complete_order(order)
else:
if order["status"] == "canceled":
refund(order)

  
  В итоге добавили логику, но, если ее чуть изменить, всё сломается.
• Нет плана. Если программист начинает писать код без четкой структуры, это превращается в хаос. Например, бэкенд-разработчик пишет API, но вместо четкой архитектуры просто накидывает обработчики в одном файле. Вот что получается:
  

  def calculate_price(price, discount, tax):
if discount:
price = price - (price * discount / 100)
if tax:
if discount:
price = price + (price * tax / 100)
else:
price = price + (price * tax / 100)
return price

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

  app.get("/users", get_users)
app.post("/users", create_user)
app.get("/orders", get_orders)
app.delete("/orders/", delete_order

• GOTO и бесконечные условия. GOTO — это оператор, который заставляет программу перескакивать с одной части кода на другую, минуя логические условия. Хотя такие логические прыжки уже почти не используют, эта команда всё еще встречается. Если фронтенд-разработчик обрабатывает формы и вместо нормального кода пишет цепочку if-else, логика становится запутанной. Выглядит это так:
  

  function validateForm(form) {
if (!form.username) {
showError("Введите имя");
return;
}
if (!form.email) {
showError("Введите email");
return;
}
if (!form.password) {
showError("Введите пароль");
return;
}
if (form.password.length < 6) { showError("Пароль слишком короткий"); return; } if (!form.agree) { showError("Вы должны согласиться с условиями"); return; } submitForm(form); }

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

  def check age(age): if age >= 18:
return True
elif age < 18:
if age == 17:
return "почти взрослый"
else:
return False

  
  Один if лишний, но специалист его добавил, потому что боялся сломать уже существующий код. Со временем этот код станет еще хуже. Лучше вынести проверки в отдельные функции и сделать код читаемым.

Учитесь сразу писать правильный и чистый код. На курсе «Веб-разработчик» в онлайн-университете Skypro разберетесь, как работать с JavaScript, React, Git, TypeScript и многими другими инструментами. Курс построен на практике, сразу начнете работать над реальными проектами будущих работодателей. Занятия проходят онлайн — не нужно рано вставать и ехать на занятия. Учиться можно в удобное для вас время и совмещать с основной учебой, работой и личной жизнью.

Последствия использования спагетти-кода

Неорганизованный код влияет на работу всей системы.

• Проблемы с производительностью

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

• Ошибки и баги

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

• Сложности в поддержке и развитии

  Чужой спагетти-код — это кошмар для любого программиста. Например, специалисту нужно немного изменить механизм отправки уведомлений. Он открывает код и не понимает, как это вообще работает. В одном месте написано одно, в другом — другое, несколько раз встречаются одни и те же проверки, а если попытаться что-то поменять, ломается всё. В итоге программист тратит кучу времени, чтобы разобраться. Либо просто добавляет еще одно временное условие, чтобы программа хоть как-то работала. Через несколько месяцев таких изменений код превратится в свалку и исправить это вряд ли кто-то решится.

Как избежать спагетти в коде

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

• Принцип инверсии зависимостей (Dependency Inversion Principle)

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

• Принцип открытости/закрытости (Open-Closed Principle)

  Код должен быть открыт для расширения и закрыт для модификации. Если нужно постоянно переписывать старый код, чтобы добавить новый функционал, это приведет к ошибкам или вообще сломает всю программу. Лучше заранее построить архитектуру так, чтобы можно было добавлять новые функции и не менять уже существующий код. Например, если систему уведомлений изначально разработали только для имейл-рассылок, но вдруг понадобились пуш-уведомления или SMS. С правильной архитектурой можно просто добавить новый модуль и не переписывать всю структуру.

• Принцип разделения интерфейса (Interface Segregation Principle)

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

• Принцип единственной ответственности (Single Responsibility Principle)

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

Главное: что такое спагетти-код (spaghetti code)

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