Софтуер

Сорс код – може ли да бъде разбираем?

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

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

Какво става, ако кодът не е добре написан?

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

Поставя се началото на модел, който води до все по-голямо влошаване на качеството на кода. Програмистът, който се опитва да дописва неразбираем код, губи много време в опити да разбере как работи кодът. Вместо да го направи по-ясен и лесен за четене, той прави съвсем малки промени (за да не счупи нещо) и резултатът е дори още по-неразбираем код. Следващият програмист губи още повече време да разбере какво прави кодът, изнервя се, преписва кода или го пренаписва изцяло. Така се появяват нови грешки или старите биват преписани. Работата на екипа се забавя, спира развитието.

Какво означава разбираем сорс код и как да го постигнете?

Вероятно всеки програмист има свой отговор на този въпрос. За Code Academy и CODIX това означава код, който е лесен за четене и ясен, който може лесно да се дописва и модифицира от други програмисти, освен от автора си. Можете да го постигнете и ние ще ви научим как.

Принципи, които ще ви помогнат да пишете разбираем сорс код

Те са безброй, тук ще се спрем само на най-основните:Единична отговорност. Всички градивни елементи на кода – класове, методи, променливи – следват принципа „един елемент прави едно единствено нещо“. По този начин за четящия е по-лесно да разбере какво именно е това нещо. Съответно е по-ясно, при евентуален проблем, коя част от кода трябва да се промени.

Добра структура

Кодът е лесен за четене, ако е логично структуриран и последователен – с функции, класове, модули.

Имената са красноречиви

Имената на класовете, функциите и променливите улесняват четенето и разбирането на сорс кода. Имайте предвид, че код с добри имена е плод на много усилия от страна на програмисти, отделили много време за постигането им.

Простота и конкретност

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

Коментарите обясняват „защо“, а не „как“

Повечето код би трябвало да се разбира от самосебе си. А коментарите да запълват само евентуални празноти.

Рефакторинг (преработка на код)

Базите с код растат. Когато простият клас получи повече отговорности, той също пораства и става по-сложен. Разбираемите бази са такива заради постоянно рефакториране. Новият сложен клас може да бъде разделен на няколко части или променен така, че да остане лесен за четене.

Добре изтестван

Добре изтестваният код може да бъде променян лесно и без страх, че нещо в него може да спре да работи. Тестването с автоматизирани тестове помага на кода да остане разбираем. Без тестове, рефакторирането става много рисковано и програмистите може да спрат да го правят. С тестове няма причина да не бъдат правени дори и големи и рисковани рефакторирания, благодарение на които кодът да остава все така разбираем и лесен за разчитане.

Най-добрата проверка дали сорс кодът ви е лесно четим, е да го покажете на други програмисти за мнение. Помолете ги да споделят дали го намират за ясен. Нека могат да ви задават въпроси. Ако кодът е разбираем, ще има малко или никакви въпроси. Обърнете специално внимание, ако забележите, че някой изобщо не е разбрал какво сте написали и задава много въпроси. Всеки въпрос или нещо неясно ви отваря възможности да направите сорс кода си по-разбираем.

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

Нашите курсове:

Курс по програмиране за професия Back-end Junior Developer със SQL, PL/SQL, Pro*C и C

Курс по програмиране за професия Back-end Junior Developer със SQL, PL/SQL, Embedded SQL и Java

Как се създава компютърна програма – 2 част. Софтуерните архитекти

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

Софтуерните архитекти

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

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

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

Например къде ще има бутони, къде ще извежда отчети, какви прозорци ще се отварят, къде ще се въвеждат данните. Може да напишат и някакъв съвсем груб прототип на системата на uml език.

UML e специализиран стандарт за описване на софтуер от архитектурна гледна точка.

Това също все още не е програмиране.

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

Софтуерните архитекти дават първата версия на програмата с възможност за развитие на софтуера на базата. Те могат да кажат:

“Нашият софтуер ще е трислоен. Ще има front-end офис, който ще е уеб базиран и достъпен през браузър. Ще има server middleware и от него ще има връзка с базата данни.”

За всеки от тези елементи архитектите казват как и къде да бъдат написани и изпълнени. Уеб частта ще се пише в Angular на Javascript. Middleware частта ще се пише на Embedded SQL, C и Pro*C. A back-end ще бъде в база данни с хора-процедури.

Софтуерните архитекти описват и обясняват спецификацията така, че програмистите да я разберат и да могат да напишат кода.

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

Как се създава компютърна програма – 1 част

Нашите курсове:

Курс по програмиране за професия Back-end Junior Developer със SQL, PL/SQL, Pro*C и C

Курс по програмиране за професия Back-end Junior Developer със SQL, PL/SQL, Embedded SQL и Java

Абонирай се за нашия бюлетин

Последвай ни: