Един малък проблем, който може да доведе до големи проблеми
Не ме интересува дали кодът е объркан или не, ако работи, значи сме добре
Може би често имаме такъв принцип, особено точно преди крайния срок. Често просто се фокусираме върху това как да накараме кода да работи, без да осъзнаваме какъв е големият проблем зад него.
Ако сме само в началото на проекта или в първите си версии, вероятно няма да имаме значителни проблеми. Този проблем може да възникне едва когато сме в следващите версии. Ако сте програмист повече от 3 или 4 години, знаете какво е усещането да се забавите значително поради объркан код, направен от други хора.
Така че, без да го осъзнаваме, понякога прекарваме повече време в подреждане на предишния код, вместо да добавяме нови функции.
И така, защо се случва това?
Нека да разгледаме тази позната лъжа на разработчиците:
Можем да го почистим по-късно, просто първо трябва да стигнем до пазара!
Получих това изречение от Чиста архитектура на Робърт С. Мартин (Чичо Боб). Понякога осъзнаваме, че кодът ни е объркан, просто грешим да приоритизираме кой е по-важен. Разбира се, кодът никога не се грижи, защото пазарният натиск никога не отшумява.
Избирайки пазара като приоритет, сега имате конкурент зад себе си и трябва да останете напред, като бягате възможно най-бързо. И това ще ви попречи да се върнете, за да извършите почистването, защото трябва да завършите следващата функция, и следващата, и следващата, и следващата.
Никога няма да го поправите и той ще живее вечно
Повечето организации или компании не ценят рефакторинга и забавят скоростта, когато е необходимо. Единственият начин да се върнете е, когато сте на път да добавите нова функция и разберете, че функцията не може да бъде добавена, освен ако не промените предишния код, а понякога това пречи на други функции да работят.
Но какво го прави опасен?
От някои от нещата, споменати по-горе, може би не виждаме къде е опасността от объркан код. Нека разгледаме следната илюстрация.
От илюстрацията по-горе можем да видим сравнение на растежа между броя на инженерния персонал и нивото на производителност, измерено чрез броя на редовете код. Ако погледнем само растежа на нейния инженерен състав, може би можем да приемем, че компанията се увеличава много бързо, тъй като е белязана от набирането на много служители.
Въпреки това, ако погледнем графиката на производителността, въпреки че броят на служителите се увеличава, растежът е съвсем малък, дори не по-голям от предишното издание.
Оттам можем да видим признаци на хаос. Когато това, което прави програмистът, е свързано с изхода и чистотата на кода или структурата на дизайна, това не е основен приоритет. Тогава ще видим лош край.
Ако сме виждали от страна на разработчиците, тогава тук ще погледнем от страна на изпълнителната власт.
Колкото повече служители, разбира се, толкова повече разходи трябва да бъдат изразходвани. Ако погледнете трите съществуващи класации, с такъв ръст. Няма значение колко печеливша е компанията в момента. С такъв растеж ще източи печалбата от бизнес модела и ще доведе компанията до застой, ако не и до пълен колапс.
Та какъв е проблема?
Чичо Боб в своята книга казва, че всяка софтуерна система предоставя две различни ценности на заинтересованите страни: поведение и структура. И разработчиците на софтуер са отговорни да гарантират, че и двете стойности остават високи. Проблемът е, че често се фокусират върху едното и забравят за другото.
Често приемаме, че когато програмата, по която работим, работи и отговаря на изискванията, тогава нашата работа е приключила. И в това е грешката.
Думата „софтуер“ е сложна дума, съставена от „софт“ и „изделия“. Думата “ware” означава продукт, а “soft” означава лесен за смяна. Ако искаме машина, която е трудна за промяна, тогава я наричаме хардуер.
Да приемем, че ще построим къща. Където ще построим къщата постепенно. В началния етап ще построим проста едноетажна къща. На втория етап ще създадем гараж. И третият етап ще надстроим къщата до двуетажна къща.
Ако наблюдаваме тази илюстрация, разбира се, първо трябва да проектираме архитектурата на къщата, която ще направим. Определено не искаме, първо трябва да унищожим части от къщата, за да добавим към нашия гараж. Или трябва да разрушите къщата, която направихме, за да добавите етажи, защото основната основа не е достатъчно здрава. Освен да губим време, трябва да изразходваме и много повече разходи и много повече усилия.
По същия начин с разработката на софтуер. Когато създаваме софтуер, ние трябва да гарантираме, че софтуерът може да бъде разширен, без да се налага да правим промени от предишния етап.
Но все още имаме проблем
Ако попитаме бизнес мениджърите, те със сигурност ще кажат, че е по-важно софтуерната система да работи, а разработчиците често се съгласяват с това отношение.
Но ние не сме бизнес мениджър, ние сме разработчици. Нашата работа не е просто да се уверим, че една програма може да работи добре. Но също така изградете добра структура на кода.
Обичам простата логика от книгата.
Ако ми дадете програма, която работи перфектно, но е невъзможно да се промени, тогава тя няма да работи, когато изискванията се променят, и аз няма да мога да я накарам да работи. Следователно програмата ще стане безполезна.
Ако ми дадете програма, която не работи, но е лесна за промяна, тогава мога да я накарам да работи и да я продължа да работи, когато изискванията се променят. Следователно програмата ще остане винаги полезна.
— Робърт К. Мартин
В заключение можем да кажем, че за да формираме добра система, се нуждаем от архитектура или дизайн. Целта? За минимизиране на човешките ресурси, необходими за изграждане и поддръжка на системата.
С други думи, може да се каже, че ако усилието е ниско и ще продължи да бъде ниско през целия живот на системата, тогава дизайнът е добър. Обратно, ако усилията продължават да нарастват с всяко ново издание, тогава дизайнът е лош.
