Уеб Разработване 10 Кодиращи Antipatterns трябва да се избягват
Проектирането на архитектурата на уебсайт или приложение, или създаването на ефективен работен поток за кодиране често ни карат да се справяме с повтарящи се проблеми. Не е задължително да решаваме тези проблеми, свързани с дизайна на софтуера, от самото начало решения на архитектурно ниво могат да бъдат използвани повторно по същия начин като кодови фрагменти на микрониво.
Моделите на проектиране обикновено са решения за многократна употреба за някои сценарии, които могат по-удобни за решаване на често възникващи проблеми, и може да ни помогне да оптимизираме нашия код.
Въпреки че моделите на проектиране са чудесни средства за подобряване на нашия процес на разработване с помощта на добре изпитани формули, понякога можем да се объркаме и с тях. Те се наричат антипатерни.
Какво представляват антипатерните?
Терминът “antipattern” е измислена в книга, наречена AntiPatterns през 1998 г. Тя се отнася до повторно използвани решения, които първоначално изглеждат полезни, но по-късно се оказва да направи повече вреда, отколкото полза.
Това може да се случи по различни причини, например, ако не използваме моделите в правилния контекст, настройка или време (решения, които са били ефективни в миналото не винаги работят в настоящето), или в други случаи цялата парадигма беше само лошо от самото начало.
Често се наричат и антипатерни модели на неуспех. Добрата новина е, че това е да ги разпознаете и избегнете.
В този пост ще разгледаме 10 обикновени кодиращи антипетарги в уеб разработката, които могат да ни заблудят, че имаме добре оптимизиран код. (Имайте предвид, че несъответствията, изброени в тази публикация, не са задължително същите като това, което можете да намерите в споменатата по-горе книга.)
1. Преждевременна оптимизация
Доброто синхронизиране е решаващ фактор в оптимизацията на кода. Лесно можем да възпроизведем антипатента на “преждевременна оптимизация”, ако обърнем внимание на малки ефективности и оптимизираме за тях твърде рано в процеса на разработване, преди да знаем точно какво искаме да правим.
Според известния цитат на Доналд Кнут “Преждевременната оптимизация е коренът на всяко зло“, което може да е преувеличение, но все още показва колко сериозни проблеми могат да предизвикат преждевременната оптимизация.
Ако оптимизираме производителността преди да създадем ефективна архитектура, можем по-ниска четливост на кода, правя отстраняване на грешки и поддръжка по-трудно, и добавете излишни части към нашия код.
За да се предотврати преждевременната оптимизация, е добра идея да следвате принципа на програмиране YAGNI (Вие не се нуждаете от него), който съветва “винаги изпълнявайте нещата, когато всъщност имате нужда от тях, никога, когато просто предвиждате, че имате нужда от тях.”
2. Преоткриване на колелото
Най- “преоткриване на колелото” понякога се споменава и като антипатерн “проектиране във вакуум”. Това се случва, когато искаме направете всичко сами и напишете всичко от нулата, без да търсите вече съществуващи методи, API или библиотеки.
Преоткриването на колелото не е просто нещо, което губи време, а индивидуалните решения, особено за основните функционалности, рядко са толкова добри, колкото стандартните които вече са тествани от много разработчици и потребители.
3. Зависимост Ада
Обратното на “преоткриване на колелото” antipattern е друг често срещан антипатерн “зависим ад”.
Ако вместо да пишем всичко от нулата, използваме твърде много библиотеки на трети страни, които разчитат на специфични версии на други библиотеки, лесно можем да се сблъскаме с трудно управляема ситуация, когато искаме да актуализираме, тъй като в много случаи тези субсидиарни зависимости несъвместими помежду си.
Зависимостта ад може да бъде решена с помощта на пакетни мениджъри, които са в състояние да интелигентно актуализирайте взаимозависими зависимости. Ако сме претоварени твърде много от проблема, рефакторингът също може да бъде добра идея.
4. Код за спагети
“Спагети код” вероятно е най-известният кодиращ антипатерн. Той описва приложение, което е трудно за отстраняване на грешки или модифициране поради липсата на подходяща архитектура.
Резултатът от лошия дизайн на софтуера е куп код, който е сходен по структура с купа спагети, т.е.. заплетена и заплетена. Четливостта на кода на спагети е много ниска и обикновено е почти невъзможно да се разбере как точно работи.
Спагети код обикновено произтича от комбинация от различни практики за лошо кодиране, като например кода, който не съдържа блокове с подходящи условия, съдържащ много изявления, изключения и нишки, съдържащи части, които принадлежат на друго място, има минимални връзки между обектите, има функции или методи, които не могат да бъдат използвани повторно, или не са документирани правилно или изобщо.
5. Програмиране чрез превключване
“Програмиране чрез пермутация” или “случайно програмиране” се случва, когато се опитваме да намерим решение на проблема, като експериментираме с малки модификации, тестваме и оценяваме един по един, и накрая реализираме този, който работи първоначално.
Програмирането чрез пермутация може лесно въведете нови грешки в нашия код, още по-лошо, те са грешки, които не е задължително да разпознаваме веднага. В много случаи е невъзможно да се предвиди дали решението ще работи за всички възможни сценарии или не.
6. Копиране и поставяне на програмирането
“Копиране и поставяне на програмиране” възниква, когато не следваме принципа "Не повтаряй себе си" (DRY) и вместо да създаваме общи решения, вмъкваме вече съществуващи кодови фрагменти на различни места и след това ги редактираме, за да се впишат в дадения контекст.
Тази практика води до много повтарящ се код, тъй като вмъкнатите кодови части обикновено се различават само в малки несъответствия.
Копиране и поставяне на програмиране се извършва не само от начинаещи разработчици, но и от опитни програмисти, тъй като много от тях са склонни да използват собствените си предварително написани, добре изпитани кодови фрагменти за конкретни задачи, което лесно може да доведе до това неочаквани повторения.
7. Програмиране на товари и култури
Името на “програмиране на култови товари” идва от специфичен етнографски феномен, наречен “товарен култ”. Карго култовете се появяват в южната част на Тихия океан след Втората световна война, когато принудителният контакт с напредналите цивилизации води местните жители да мислят, че произведените продукти, като Coca-Cola, телевизори и хладилници, донесени с товарни кораби на островите, са създадени от свръхестествени методи; и ако изпълняват магически обреди, подобни на обичаите на западняците, товарът, пълен със стоки, ще дойде отново.
Когато се ангажираме с антипаттерна на програмирането на култови товари, ние по принцип правим същото. Ние използваме рамки, библиотеки, решения, дизайнерски модели и т.н., които са работили добре за другите, без да разберем защо го правим, или как точно работят споменатите технологии.
В много случаи разработчиците просто ритуално правете това, което е хип по това време, без някаква реална цел. Тази практика е не само лоша, защото прави нашето приложение излишно раздуто, но също така може лесно да въведе нови грешки в нашия код.
8. Lava Flow
Ние говорим за “поток от лава” антипатерн, когато трябва се справят с код, който има резервни или нискокачествени части че изглеждат неразделни към програмата, но ние не разбираме напълно какво прави или как влияе на цялото приложение. Това го прави рисковано да го премахнете.
Това обикновено се случва с наследствен код, или когато код е написан от някой друг (обикновено без подходяща документация), или когато проектът се премести твърде бързо от разработването към фазата на производство.
Името на антипаттерна идва от неговото сходство с лава, идваща от вулкани, т.е. първоначално тя се движи бързо и плавно, без да взима прекалено много предпазни мерки, но по-късно се втвърдява и става трудно да се отстрани..
На теория можем да се отървем от потоците лава обширни тестове и рефакториране, но на практика, изпълнението е често трудно или дори невъзможно. Тъй като потоците лава обикновено имат високи разходи за производителност, по-добре е да ги предотвратите, като създадете добре проектирана архитектура и звуков работен процес от самото начало.
9. Твърдо кодиране
“Твърдо кодиране” е добре познат антипатерн, срещу който повечето книги за уеб разработки ни предупреждават точно в предговора. Твърдото кодиране е нещастната практика, в която съхраняваме конфигурационни или входни данни, като път на файл или име на отдалечен хост, в изходния код вместо да я получават от конфигурационен файл, база данни, потребителски вход или друг външен източник.
Основният проблем с твърдия код е това работи правилно само в определена среда, и в по всяко време, когато условията се променят, ние трябва да променим изходния код, обикновено в няколко отделни места.
10. Меко кодиране
Ако се опитаме много трудно да избегнем капанът на твърдото кодиране, лесно можем да се натъкнем на друг антипаттерн “меко кодиране”, което е точно обратното.
При меко кодиране, поставяме нещата, които трябва да бъдат в изходния код, във външни източници, например съхраняваме бизнес логиката в базата данни. Най-честата причина, поради която го правим, е страхът, че бизнес правилата ще се променят в бъдеще, затова ще трябва да пренапишем кода.
В екстремни случаи може да има програма с меко кодиране станете толкова абстрактни и заплетени, че е почти невъзможно да го разберете (особено за новите членове на екипа) и изключително трудно за поддържане и отстраняване на грешки.
