Какво е спагети код

Спагети код (spaghetti code) — това е метафора за описание на код, чиято структура наподобява чиния спагети: отделните нишки (логически блокове) са объркани, слепени и неотделими една от друга. В такъв код е невъзможно да се отделят слоеве, модули или компоненти — всичко е смесено в една голяма маса.

За разлика от лошия код, който може просто да е небрежен, спагети кодът е фундаментален архитектурен проблем. Дори идеално форматираният код с добри имена на променливи може да бъде спагети код, ако архитектурата му е хаотична. Проблемът е на нивото на структурата на програмата, а не на стила на писане.

Според IEEE (2022), около 35% от всички грешки в големи проекти са причинени именно от обърканата структура на кода, а не от логически грешки на разработчика. Разработчикът допуска грешка не защото е разбрал погрешно задачата, а защото не е могъл да проследи потока на изпълнение в спагети кода.

Ключовата разлика от другите антимодели

Ако лошият код е лош код в мащаба на една функция или файл, то спагети кодът е лоша архитектура в мащаба на цялото приложение. Фидето може да се състои от отделни добре написани функции, но тяхното взаимодействие е хаотично и непредсказуемо.

История на термина и епохата на goto

Терминът „спагети код“ се появява през 70-те години на XX век заедно с критиката към оператора goto. В ранните езици за програмиране (BASIC, FORTRAN, COBOL) goto беше основният начин за управление на потока на изпълнение. Програмата представляваше последователност от номерирани редове, а goto позволяваше преминаване към всеки от тях. Това създаваше „кълбо“ от преходи, което беше невъзможно да се разплете.

През 1968 г. Едсгер Дейкстра публикува известното писмо „Go To Statement Considered Harmful“, което поставя началото на епохата на структурното програмиране. Дейкстра доказа, че всеки алгоритъм може да се реализира без goto, използвайки само три конструкции: последователност, разклонение (if) и цикъл (while). Това става основа на съвременното програмиране.

Структурното програмиране не елиминира проблема напълно. Спагети кодът премина на ново ниво — вместо физически goto, разработчиците започнаха да създават логически „goto“: глобални променливи, callback hell в JavaScript, сложни вериги от извиквания и неявни зависимости между компоненти. Проблемът остана, промени се само формата.

Съвременни форми на goto

Callback hell в JavaScript, дълбоко вложени Promise, async/await без обработка на грешки, събития, за които не е ясно кой и кога ги инициира — всичко това са съвременни разновидности на спагети кода. Антимоделът е жив и процъфтява, просто сега вече не използва оператора goto.

Признаци на спагети кода в проекта

Липсата на слоеве — първият и основен признак. В спагети кода бизнес логиката, работата с базата данни, HTML изгледите и мрежовото взаимодействие са смесени в един файл или дори в един метод. Промяната на заявка към базата данни може да счупи визуализацията на UI, защото кодът на тези слоеве не е разделен.

Глобалните променливи и сингълтъните — вторият явен признак. Когато състоянието на приложението се съхранява в глобални обекти, потокът на изпълнение става непредсказуем. Всяка функция може да промени глобалното състояние и проследяването къде и кога е станало това е практически невъзможно.

God-класовете и god-функциите — третият признак. Клас с 2000+ реда, който отговаря и за бизнес логиката, и за визуализацията, и за работата с данни — това е типичен спагети код. Функция, която приема 10 параметъра и прави 5 различни неща, също.

Диагностика чрез тестове

Ако не можете да напишете unit тест за функция без да създадете 15 mock обекта — това е спагети код. Ако тестването на един модул изисква стартиране на цялата инфраструктура на приложението — това е спагети код. Нетестируемостта е обективен индикатор за объркана архитектура.

Защо се появява фиде в кода

Липсата на архитектурно проектиране — най-честата причина. Когато екипът започне да пише код без план, избирайки архитектурата „по хода на нещата“, резултатът неизбежно се превръща в спагети. Всяка нова функция се добавя там, където „е удобно сега“, а не там, където е нейното логическо място.

Еволюционното развитие — втората причина. Проектът започва като малък скрипт, после обраства с функции, после става приложение, а след това — монолит. При това архитектурата не се преразглежда. Това, което е работело за 100 реда код, става катастрофа за 100 000 реда.

Нарушаването на принципите SOLID — третата причина. Особено принципа за единствена отговорност (S) и принципа за инверсия на зависимостите (D). Когато класът отговаря за всичко, зависимостите са твърди, а модулите са здраво свързани — получава се спагети код.

Факторът време

Крайните срокове и hotfix културата — катализатори за спагети кода. Когато „трябваше да е готово още вчера“, разработчиците вмъкват код на първото попаднало място, без да мислят за архитектурата. Десет такива hotfix-а — и архитектурата на приложението е разрушена.

Последици от спагети кода

Основната последица — загуба на контрол над кодовата база. Разработчиците престават да разбират как работи приложението като цяло. Промяната на едно място чупи друго, привидно несвързано. Всеки пач създава два нови бъга. Екипът влиза в състояние на „страх от промените“.

Производителността на екипа пада експоненциално. Изследване на Microsoft Research (2023) показа, че времето за добавяне на нова функция в спагети кода расте по квадратичен закон спрямо размера на кодовата база. При чиста архитектура този ръст е линеен. Разликата става критична при 50 000+ реда код.

Сигурността — още една жертва. В спагети кода е лесно да се пропусне необработено изключение, грешна валидация на входа или изтичане на данни. Одитът за сигурност в проект с объркана архитектура е практически невъзможен — да се намерят всички места, където се използва потребителски вход, е нереалистично.

Влияние върху екипа

Текучеството в проекти със спагети код е над средното. Опитните разработчици си тръгват, защото не искат да работят с „фиде“. Новите служители не могат да разберат кода и напускат през първите месеци. Проектът губи експертиза, което още повече влошава качеството на кода — порочен кръг.

Как да рефакторираме спагети код

Първо — започнете с разделяне на слоевете. Разделете кода на три нива: presentation (UI, контролери), business logic (услуги, use cases) и data access (репозитории, DAO). Дори частичното разделяне веднага подобрява структурата и прави кода тестируем.

Второ — въведете dependency injection. Заменете директното създаване на зависимости с предаване през конструктор или параметри. Това прекъсва твърдите връзки между компонентите и позволява тестване на всеки модул изолирано.

Трето — отделете god-класовете и god-функциите. Разбийте ги на малки класове и методи с единствена отговорност. Използвайте модела Facade за опростяване на сложни подсистеми. Помнете: клас с 20 реда е по-разбираем от клас с 2000 реда.

// спагети — всичко в един метод
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// чиста архитектура — разделени слоеве
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

Стратегия за рефакторинг: методът на хирургията

Не се опитвайте да пренапишете цялата кодова база наведнъж — това е гарантиран провал. Изберете един модул, напишете за него тестове (characterization tests), които фиксират текущото поведение, и едва тогава рефакторирайте. Постепенно, модул по модул, ще разплетете спагетито.

Превенция на появата на фиде

Архитектурното планиране — основата на превенцията. Преди започване на разработката одобрете архитектурния стил: MVC, MVVM, Clean Architecture, VIPER или друг. Напишете ADR (Architecture Decision Record) с обосновка на избора. Изисквайте спазване на архитектурата при код ревюто.

Принципът за инверсия на зависимостите (DIP) — мощен инструмент за борба със спагети кода. Модулите от високо ниво не трябва да зависят от модули от ниско ниво. И двата вида трябва да зависят от абстракции. Dependency Injection — практическата реализация на този принцип.

Тестването — най-добрата превенция. Ако пишете тестове преди кода (TDD), вие неизбежно проектирате слабо свързани компоненти. Тестируемият код е добре структуриран код. Нетестируемият код — почти винаги спагети код.

• Архитектура преди кода: одобрете схемите на слоеве и зависимости
• Dependency Injection като основен модел на свързване
• TDD или поне високо покритие с тестове
• Code review с проверка на архитектурата, а не само на стила
• Редовен рефакторинг като част от процеса на разработка

Инструменти за борба със спагети кода

SonarQube — проследява цикломатичната сложност, дълбочината на наследяване, размера на методите. JDepend (Java) — измерва зависимостите между пакетите. PhpMetrics — дава индекс за поддръжка (maintainability) за PHP проекти. Следете метриките в CI/CD — предупреждавайте появата на фиде, а не се борете с него постфактум.