Спагети код

от Уикипедия, свободната енциклопедия
It shows the attitude of the so-called „Spagetti code“

Спагети код е пейоративен израз за т.нар. изходен код, имащ комплексна и заплетена структурна подредба, особено тази използваща множество от GOTO изрази,[1] изключения, нишки, или други „неструктурирани“ разклонени конструкции. Наречен е по този начин, защото програмният му поток може да се възприеме като купа със спагети, тъй като е изкривен и заплетен. Спагети кодът може да бъде предизвикан от множество фактори, като продължителни модификации от няколко души в дълъг период от време. Структурното програмиране значително намалява шансовете за възникването на „спагети код“.

История[редактиране | редактиране на кода]

Не е ясно кога точно терминът „спагети код“ е влезнал във всеобща употреба, обаче няколко референции възникват през 1977 г., включващи Macaroni is Better Than Spaghetti[2] от Стийл, след като биват публикувани в бюлетина на проведения през 1977 симпозиум по изкуствен интелект и езици за програмиране. В публикуваната през 1978 книга „A primer on disciplined programming using PL/I, PL/CS, and PL/CT“[3], Ричард Конуей[4] е използвал терминът, за да опише видове програми, „имащи напълно същата логическа структура като чиния със спагети“ – израз, споменат повторно в книгата „An Introduction to Programming“[5], която той създава заедно с Дейвид Грийс.[6] В създадения през 1988 доклад „A spiral model of software development and enhancement[7] терминът е използван, за да характеризира старата практика на модела „код и корекция“, на който е липсвал планомерност и в края на краищата води до създаването на модела „Водопад“.[8] Авторът на създадената през 1979 книга „Structured programming for the COBOL programmer“[9] Пол Нол използва изразите „спагети код“ и „плъхово гнездо“ като синоними, за да даде характеристика за бедно структуриран изходен код.

В публикация на Американския национален институт за стандарти и технологии изразът „спагети код“ се използва да опише стари програми, имащи „фрагментирани и разпокъсани файлове“. Последствията от използването на goto изрази в програми, били описани в доклад през 1980, който изтъкнал, че били възприети за „чисто зло.“

По време на конференцията „Ada – Europe '93“Ada е описан като компютърен език, принуждаващ програмиста да „създава разбираем, вместо спагети код“, заради неговия, ограничаващ разпространението на изключенията, механизъм.

През 1981 в книгата „The Michigan Technic“[10], в шеговит текст относно езиците за програмиране, в глава, озаглавена „BASICally speaking…FORTRAN bytes!!“, авторът описва FORTRAN като „живо доказателство че, поради това че кооснователите на IBM били италианци, езикът се състоял изцяло от спагети код“.

Примери[редактиране | редактиране на кода]

Тук следва пример на спагети код в BASIC, който би бил считан за обикновен. Програмата отпечатва на екрана всяко едно от числата от 1 до 10, както и неговата стойност на квадрат. Забелязва се, че не се използва индентация, за да се разграничат различните действия, извършени от кода, и че GOTO изразите на програмата създават зависимост на номерация на редовете. Също така се наблюдава по-усложнен начин на предвидимост, по който потокът на изпълнение скача от една област в друга. Реалните явления на спагети кодове са по-сложни и могат значително да добавят към разходите за поддръжка на една програма.

10 i = 0
20 i = i + 1
30 PRINT i; " squared = "; i * i
40 IF i >= 10 THEN GOTO 60
50 GOTO 20
60 PRINT Program Completed.
70 END

Тук е същия код, написан в структуриран програмен стил:

10 FOR i = 1 TO 10
20 PRINT i; " squared = "; i * i
30 NEXT i
40 PRINT Program Completed.
50 END

Програмата скача от една област в друга, но това скачане е формално и по-лесно предвидимо, защото „for“ циклите и функциите осигуряват контрол на потока, докато изразът goto насърчава произволен контрол на потока. Въпреки че този пример е малък, програми с реална използваемост биват съставени от много редове код и е трудно да се поддържат, когато са написани в стил спагети код.

Монтаж, скриптове и други езици[редактиране | редактиране на кода]

Kогато се използват многобройните форми на езиците за сглобяване(монтажните езици), (а също и основната машина код) опасността от написването спагети код е особено голяма. Някои скриптови езици имат същите недостатъци: това се отнася до езичната партида скриптове на DOS и DCL на VMS.

Независимо от това, приемането на същата дисциплина както в структурното програмиране може значително да подобри яснотата и ремонта (поправянето) на такъв код. Това може да бъде под формата на конвенции, които ограничават използването на goto, като съответстват на стандартните структури.

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

Някои широко използвани по-нови езици за програмиране, като Python и Java, нямат отчета за goto, затова силно се насърчи структурното програмиране.

Подобни фрази[редактиране | редактиране на кода]

Фразата спагети код е вдъхновена от други термини, които по подобен начин сравняват програмната структура с различни видове паста. Главната мета-фраза е „програмна паста“.

Равиоли код[редактиране | редактиране на кода]

Равиоли код е тип от компютърната програмна структура, характеризираща се от редица много малки и в идеалния случай свободно свързани софтуерни компоненти. Терминът произлиза от аналогия на равиоли (малки тестени торбички съдържащи сирене, месо или зеленчуци) с модули (които са идеално капсулирани, състоящи се от код и данни). Макар обикновено да е желателно свързване и сплотеност на пръв поглед, прекалено разделяне и капсулиране на кода могат да препълнят кол стека и да направят поддръжката на кода по трудна.

Лазаня код[редактиране | редактиране на кода]

Лазаня код, именувана в 1982 г. от Джо Селко[11] е всякаква програмна структура, характеризираща се с няколко добре дефинирани и разделени слоеве, където всеки слой код има достъп до услуги в долните пластове чрез добре дефинирани интерфейси. Аналогията идва от слоестата структура на лазанята, където различни съставки (например месо, сос, зеленчуци или сирене) са отделени на различни слоеве от пастата.

Една обща инстанция на лазаня кода е интерфейсът, който взаимодейства между различните подсистеми, както между код за уеб приложения, бизнес логика и релационна база данни. Друга често срещана техника за програмиране, алтернативни твърди и меки слоеве (използвайки различни програмни езици за различните нива на програмната архитектура), има тенденция да произвеждат лазаня код. Като цяло клиент-сървър приложенията са често лазаня код, с добре дефинирани интерфейси между клиент и сървър.

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

Подобно наслояване може да се види в комуникационните стекове, където протокола (подобен на OSI модел) се разделя на слоеве (в този случай седем), като изпълнението на всеки слой е ограничена и е добре дефинирана функцията, и комуникира с другите слоеве използвайки специфични и стандартизирани методи. Такъв дизайн улеснява еволюционно усъвършенстването на целия стек чрез специфични подобрения на отделни слоеве.

Отново, докато свободно свързаното наслояване е обикновено желателно в програмната архитектура, защото прави обектите на всеки слой повече взаимнозаменяеми със съществуващите или евентуално бъдещи реализации, други видове промени в кода също ще доведат до увеличаване на сложността като се добавят повече слоеве и така широко слоестата архитектура може да се види като добре познатия „anti-pattern“. Добавянето на нови полета в UI view, например изисква промяна на всеки обект на всеки слой в архитектура, така че е необходимо да има познания за тази нова област (обикновено самата гледка, всеки базов контролер / водещ клас, пренос на данни обекти SOA слоеве, обекти за достъп до данни или преобразувания и самата схема на база данни). Цитат, който обикновено се преписва или на David Wheeler или на Butler Lampson: „Няма проблем в компютърната наука, който да не можа да бъде решен чрез добавянето на още един слой индиректно, освен наличието на твърде много индиректни слоеве“.

Източници[редактиране | редактиране на кода]