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

Затова в тази статия ще говоря за някои важни моменти, които биха били полезни за всички начинаещи софтуерни специалисти, които все още не са участвали в други проекти, освен образователни. Специализиран съм в .NET, но тези съвети са доста приложими за работещите с всеки програмен език, било то Java или Python.

1. Отделете си време, за да разберете изискванията на проекта

Спомням си себе си като студент: веднага щом получих задачата, сядах да пиша код. Мисля, че това е нормално и е съвсем естествено в академична среда. Но е по-добре първо да помислите какво искат от вас. Важно е  внимателно да прочетете условията на проблема и да изслушате коментарите на мениджъра или колегите с повече опит.

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

2. Не  се колебайте да задавате въпроси 

За съжаление в нашите училища и университети хората свикват: ако попитате нещо, всички си мислят, че нищо не разбирате. Но на работа е критично важно да се изяснява всичко, дори на пръв поглед очевидни подробности.

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

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

3. Използвайте графики

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

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

4. Обърнете внимание на конвенция за именуването и стила на кода

Основният въпрос е: как да пиша код? Един ръководител на проекта го каза съвсем точно: „винаги трябва да пишете без грешки“. И тук е най-важното: конвенция за именуване и стил на кода.

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

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

Var  е добра практика, която позволява на всеки разработчик да чете код с един поглед. Въпреки това, много компании правят свои собствени конвенции за проекти.

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

5. Придържайте се към писането на прост код

Ето един пример, при който Microsoft продава велосипеди и програмата изчислява данъци:

Това е прост съвет, които обаче се оказва труден за изпълнение. Ако разработчикът не е обмислил напълно решението на проблема, не е разбил задачата на съставните й части, в примера по-горе можем да видим 500 реда код. Не е толкова страшно, но е важно да се върнете назад и да помислите отново.

Защо кодът трябва да е прост?

Защото когато работите в голям екип е важно всеки от колегите ви да разбере написаното в подробности възможно най-бързо. За да улесните кода, трябва да въведете свободно свързване на компоненти.

Какво е IoC?

Този модел се нарича  Инверсия на контрола (Inversion of control). В микроуслугите лошото свързване води до мащабиране на системата. След като имаме интерфейс, можем да изолираме основния си клас с логика и да го тестваме.

Тук все още няма достатъчно коментари. Коментарът обаче е важен и полезен компонент. Когато пишете сложен алгоритъм, коментарите ще ви помогнат да разберете какво се случва там. Може да се окаже, че пишете регекс и след 15 минути сте забравили какво сте правили.

Аргументи за проверка  - това е често срещан проблем за младите инженери: те са сигурни, че всичко е написано ясно и че написаното от тях не трябва да се проверява. Но това не е така!

В този пример използваме изключение (exception), но то не винаги ни е нужно.

Като цяло изключението е специална тема. За да разберете какво да правите с него, можете да прочетете  „The Pragmatist Programmer“ от  Дейв Томас и Анди Хънт. Книгата е стара, но много интересна и съдържа добри и устойчиви идеи. Но нашият данъчен оценител = null е ключова функционалност и не можем да работим без него, така че премахваме изключението.

6. Използвайте модулни тестове

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

Тъй като разделянето на подзадачи е първата стъпка към започването на писане на модулни тестове, самите тестовете сами ще ви насочат към раздробяване.

7. Придържайте се към схемата „Bulld-Store-Deploy”

Какво правим, след като напишем нещо? Билдваме го, след това съхраняваме компилираните елементи някъде, след което разполагаме (т. нар. “Deploy”).

Това е жизненият цикъл от създаването до внедряването и този код ще се използва от крайния потребител. Можете да създадете автоматична компилация с помощта на PowerShell и msbuilt; store - в ProGet и след това да разположите получените пакети.

Полезни ресурси:

• Книгата на Брайън в. Керниган, Денис М. Ричи „Програмният език C” е стара, но полезна. Тя ми направи голямо впечатление. Дори не толкова за изграждане на умения за програмиране, а за правилното мислене.<
• McConnell "Code Complete" е главно четиво.<
• Дейв Томас, Анди Хънт "Прагматичният програмист".<
• John Vlisidis, Ralph Johnson, Richard Helm, “Erich Gamma Design Patterns” е книга за тези, които планират да пишат на обектно-ориентирани езици за програмиране. Тя също така задава правилния начин на мислене. Когато четях, не разбирах нищо, но когато започнах да работя, го препрочетох и книгата започна да помага.<
• Patterns of Enterprise Application Architecture на  Martin Fowler. Фаулър направи огромен принос за индустрията, написвайки различни модели, въз основа на които се създава софтуер.<