Ако не работите в сферата на софтуерната разработка, може би ще ви звучи странно, че програмистите биват наричани и софтуерни инженери. А в това има много сериозна логика, знаят го всички, които са натрупали определен опит в тази област. Защото писането на компютърен код си е инженерен процес, който може да изглежда лесен и дори хаотичен, но, ако се прави както трябва, събира в себе си всички важни инженерни изисквания.
И ето че стигаме до това „ако се прави както трябва“. През последните десетилетия се създават все по ясни стандарти за това „както трябва“ и именно те се крият зад определението „качествен код“. Защото дългите редове думички, на който и да било от модерните компютърни езици, определено могат да бъдат изписвани по много различен начин, който предопределя и това доколко добре изпълнен е наборът от концепции, които се крият зад това определение.
Пенчо, бре, чети
За да продължим към детайлите, трябва да погледнем малко по-отдалеч към днешния софтуерен свят.
В него почти няма да намерите проекти, които са малки като обем или сложност. Които се създават от малко на брой хора и имат ограничени функционалности, които почти не се променят. Точно обратното: съвременните софтуерни решения са комплексни, многопластови, постоянно биват обновявани. Дори за малки промени, които стигат до потребителя, понякога са нужни доста редове код и обмисляне от страна на програмиста.
Е, това прави задължително да се акцентира върху четимостта на кода. Той да бъде написан по единен стандарт, който по някакъв начин е въведен от програмистите, работещи по един и същи проект.
Например, където е необходимо, е редно да се оставят коментари, така че да бъде ясно защо е направена дадена не толкова очевидна програма.
Бързай бавно
Така не само е по-лесно за всички, които са вече в екипа, но и за всяко следващо ново попълнение.
Ключов фактор в това отношение е и добре организираната документация на проекта. Тя трябва да е ясна, изчерпателна и разбираема за всеки следващ програмист.
Много често добрите практики са свързани и с конкретни измерения, що се отнася до съответния програмен език, който се използва. Нерядко някои от най-големите в този бранш предлагат свободен достъп до своите стандарти за код. Така например, ако програмирате на JavaScript, можете да разгледате и изберете най-доброто от правилата, които са въвели в работата си различни екипи на Google или Facebook. Като се започне от това дали да се слага задължително точка и запетая на края на реда (което самият език позволява, но често може да доведе до проблеми) и се стигне до цялостни архитектурни решения.
Извън шаблона
Да се мисли извън шаблона е важно във всяка професия, но при програмирането е добре да стоим колкото можем повече в едни конкретни шаблони. Споменавайки архитектурата, задължително условие за създаването на качествен код е познаването и прилагането на шаблони за дизайн (или design patterns).
Те представляват набор от архитектурни решения, които описват някои от най-честите случаи от ежедневната практика. Темата е по-обширна и важна, със сигурност ще се спрем на нея скоро отново, но все пак, с няколко думи, това са стандартни решения, зад които не стои конкретен код или имплементация. Както издава и названието им, те са по-скоро шаблони, които обаче е важно да се познават, за да има по-лесна комуникация, а и за по-лесното решаване на изникнали проблеми.
Най-общо се делят на три групи в зависимост от проблема, който решават. Първите са тези, свързани със създаването на обектите – създаващите шаблони. Те описват най-честите варианти за програмни решения, които се използват за създаването на различни класове в рамките на проекта. Втората група е на структурните шаблони. Както издава името им, те отговарят за това как е структуриран самият клас. Често са свързани и с това как точно си взаимодействат помежду си различните обекти. Последната група е на поведенческите шаблони, които определят начина, по който класовете вършат основната си работа.
Конкретният списък с различни шаблони, които влизат в някоя от трите групи, е доста дълъг, понякога относителен, защото различните школи включват или пропускат някои от решенията. Но и, без съмнение, важен затова скоро ще му посветим допълнителен материал.
Солидни и солидарни
Разбира се, едва ли не закон, с който ще се съгласят огромна част от специалистите в бранша, е при програмирането да се използват 5-те правила, които се крият зад абревиатурата SOLID. Те са кратки, ясни и много важни, а вече сме ви разказвали доста подробно за основите, които се крият зад тях. Формулира ги Робърт „Боб“ Мартин и днес са златен стандарт по отношение на генералните принципи. Основният им проблем е… че всъщност са доста абстрактни, заради което и не е възможно винаги да се прилагат на 100%.
Доста по-прости, ясни, но също полезни за качествения код са правилата, криещи се зад принципите YAGNI, DRY и KISS, които също сме ви представяли. Идеята им е да не оставяме код, който просто си мислим, че някога си ще ни трябва, да не повтаряме много пъти един и същи код, като вместо това го преизползваме, а също и да се грижим да поддържаме функциите си колкото може по-прости и четими.
Разбира се, качественият код е абстракция и в този смисъл никога не можем да постигнем съвършенството. Но всяко усилие в тази посока може да ни се изплати многократно в бъдеще, да ни улесни живота дългосрочно. Тъй като често в софтуерния свят се налага нещо да се случва с бързане и спешност, важно е след това да се отдели и достатъчно време за „изплащане“ на натрупания технически дълг. За „проветряване“ и корекции там, където кодът „мирише“, както на програмистки жаргон казваме на проблемните и рискови места.
Бягай, бъг, бягай!
Във всичко това важна роля имат и код ревютата. Смята се, че програмистите са с около 50% по-неспособни да открият грешки в кода, който сами са написали. Както е и с човешките текстове, затова ги има все още и винаги ще ги има редакторите, ако търсим качествено четиво.
На последно място: задължителна част от изискванията е и тестването. Тъй като това обаче е не съвсем пряко свързана с днешната ни среща тема, ще се спрем скоро и на нея по-подробно.
И така, нека се опитаме да обобщим. Качественият код:
– Прави това, което се очаква от него;
– Следва консистентен стил;
– Лесен е за разбиране;
– Добре документиран е;
– Може да бъде тестван.
Уви, няма как да има сложни програми без никакви бъгове. Но пък винаги е добре да залагаме на превенцията, която в случая до голяма степен е качественият код. Рефакторирането е безценна дейност, стига да се прави обмислено и според стандартите.
Програмирането е перспективна и много приятна професия, само че последното определение може много лесно да изчезне от дефиницията, ако не обръщаме внимание на качествения код.
