Здравей свят. Надявам се да си добре. Тази статия не е техническа, а по-скоро за четене за удоволствие. Идеята е да погъделичкате мислите си, за да можете да вземете смислени решения напред. Следват някои аналогии с примери от реалния живот, които ще ви помогнат да мислите за програмиране.
Код за днес
Представяли ли сте си някога да тръгнете по пътя със затворени очи. Път непознат за вас. Някои могат да опитат късмета си и да успеят да поемат този риск, но много не могат. Въпреки че ходенето и самоносенето е нашата ежедневна дейност, ние сме свикнали с това и имаме практика стотици пъти. Сигурни сме, когато направим крачка напред. Но когато се опитваме да ходим в плитка река, тогава се опитваме да намерим стабилна повърхност, едва след това поставяме крака си.
Това е много подобно на писането на нашия код. Можете да кодирате само ако изискването е ясно в главата ви. Дори и най-малката единица трябва да бъде много ясна и човек трябва да може да си я визуализира. Ако можете да си го визуализирате и да не намерите свободни краища, тогава кодирането е доста добро за начало.
Трябва да кодирате само изискванията, които са ясни днес. Всяко неясно изискване трябва да премине през мозъчна атака със заинтересованите страни. Не забравяйте, че ако изискванията са трудни за обяснение, това е индикация, че те не са ясно определени. Един подход може да бъде разделяне на изискванията на подизисквания, идентифициране и адресиране на размита част.
Софтуерът е все по-добър портрет
Виждали ли сте художник да работи върху портрет на живо? Той/тя успява ли да създаде краен резултат наведнъж? Не, процесът се основава на техника на итеративно напредване по систематичен начин за постигане на желаната цел.
Същото е и с разработката на софтуер, програмирането е изкуство и трябва да мислите като художник. Сложните проблеми могат да бъдат решени само като се разделят на по-малки проблеми и след това се преодолее всеки.
Всяка разработка на софтуер започва със скициране на минимална структура чрез създаване на абстракции, създаване на интерфейси, мислене за данните и тяхната структура. След като това бъде направено, следващата итерация включва реализиране на тези абстракции чрез писане на реализации, навлизане все по-дълбоко в реализациите и кодиране за възможно най-малката единица. Свържете ги заедно и тествайте и така нататък.
Повторното повторение като скица е пътуването на разработката на софтуер и за това човек трябва да овладее The Art Of Refactoring.
Рефакторингът просто означава организиране и реорганизиране на кода, без да се променя поведението му. Те могат да бъдат нещо като Извличане на метод, ако кодът се повтаря повече от веднъж или извличане, защото някои редове от код конкретно правят само едно нещо, Идентифициране на зависимоститечрез просто чертане значението или свързването им с обекти от реалния свят (като Cycle зависи от Tire, а не обратното) и все още запазване на поведението на Cycle или Tire и т.н.
Бих препоръчал да прочетете книга за рефакторинг. Ето няколко книги, с които можете да започнете.
1. Рефакторинг: Подобряване на дизайна на съществуващ код — Мартин Фаулър
2: Ефективна работа с наследен код – Майкъл С. Феърс
Тестова сбруя
Тъй като софтуерът расте, света на нещата ще се случи с него. Тестовете ще ви помогнат да следите поведението на вашия софтуер. Софтуерът е резултат от различни Въображаеми правила, които решават определен човешки проблем. С напредването на времето ще бъде много трудно да запомните всички тях. Може да искаме да добавим функции и да проверим дали останалата част от софтуера се държи според очакванията. Това може да е повтаряща се задача и може да се случва ежедневно и затова се нуждаем от някои мерки, за да се погрижим за това. Тестовете са тези мерки. Компютрите могат да продължават да повтарят и изпълняват тестови случаи срещу нашия софтуер всеки ден или на всеки два часа, без да се изтощават за разлика от Human.
Като цяло по време на нашето обучение много по-малко се наблягаше на писането на Unit Test и повечето от нас познават Unit Test само теоретично. Понятия като Unit testing е вид допълнително усилие, защо трябва да управляваме две кодови бази? Ако правим грешки при писането на код, каква е гаранцията, че този така наречен „тестов код“ ще бъде без грешки? Това е любимото ми „Вече пишем перфектно работещи кодове, защо имаме нужда от тестове?“. Всички тези понятия създават бариери и правят още по-трудно разбирането на важността на тестовете.
Нека си призная, ние също преминахме през всички тези неохотни мисли. Едно странно преживяване, ако започнете да учите тестове много късно в кариерата си, е, че дори и да четете статии, четете книги, ще разберете какво се опитва да ви накара авторът да разберете, но въпреки това по някакъв начин първоначално няма да има смисъл. Концепциите ще звучат много очевидно, но все пак няма да „щрака“. Много е подобно на постигането на „вътрешен мир“. Всичко останало, което научихме, беше знание, но тази част е Мъдрост.
И така, какво да направим, за да попием тази мъдрост? Е, отговорът на него също е мъдър.
Повярвайте. Предайте се на вашите тестове
Ще трябва да забравиш, че си перфектен програмист. Напишете тест, дайте малко информация на класа, който тествате, и очаквайте някакъв резултат. Това трябва да е още преди да напишете нещо в споменатия клас. Тестът ще се провали. След това напишете код само за да преминете този тест, точно толкова, колкото да преминете теста. Оставете следващото поведение за предстоящия следващ тест. Не мислете отвъд този клас и продължавайте да пишете тестове и да ги преминавате, докато не се постигне желаното поведение на споменатия клас. Не прескачайте между други класове. Може да има ситуации като споменатият клас да трябва да си сътрудничи с други класове, но отново тези класове не съществуват. Все още можем да продължим да пишем тестове и да ги издържаме за текущия клас, като използваме техники за подиграване и фалшифициране.
Може да научите тези неща в интернет, има много библиотеки за тестване, подигравки, достъпни за почти всеки вид платформа за програмиране.
За Java можете да проверите Junit4, Junit5, Mockito. По същия начин за Kotlin да назове някои Kotest, Mockk
Не преоткривайте
Програмирането и програмистите се развиват от 60-те години на миналия век. Те са се сблъскали с различни препятствия и са се справили с повечето от тях. Подобно на истинските проблеми в живота, няма едно решение за всеки проблем, по подобен начин има категоризации на такива решения, които са лежали в сценарии, книги, публикувани статии и т.н. Трябва да се учим от такива документи, това ще ни превърти бързо напред и ще можем да се поучим от техните грешки и от техните открития и от техните решения.
Един от начините да започнете е като научите модели на програмиране. Има 3 категории модел на програмиране.
Творчески
Структурен
Поведенчески
Проверете всичко това подробно с пример, направете бърза справочна бележка, така че да можете да прегледате отново във всеки един момент.
Освен това научете за архитектурни модели като MVC, MVVM, MVP, MVI… и т.н.. Описването на тези модели е извън обхвата на тази статия, тъй като ви обещах, че това няма да е технологично.
Като каза това, разбирам намерението на архитектурния модел. Тези модели са приети, за да улеснят комуникацията между разработчиците. Накратко, той определя повече или по-малко какъв код къде ще отиде и ако търсите нещо, как трябва да отидете до него. Когато работите в екип, това ви спестява от сериозни преработки.
Научете за някои философии като DRY (не повтаряйте себе си) и SOLID принципи. С намерение да придобиете мъдрост, същото като изучаването на тестове. Нещо повече, всички тези неща ще ви помогнат да пишете отделен и повторно използваем код. След като хванете тези неща, вие вече няма да сте същият човек. Вашият подход към проблемите ще бъде различен. Вашето разбиране за това, което не е важно, ще се промени драстично и в крайна сметка ще ви спаси от прекомерното инженерство. Ще разберете разликата между Framework кода и бизнес логиката, това разграничение ще ви позволи да отложите или забавите дадено решение до по-късен етап от разработката на софтуер.
Всички тези неща ще ви позволят да се насладите на софтуерното инженерство. Точно като едно еспресо, ще ви отнеме известно време, за да го харесате. Заслужава си.
Развивайте емпатия
Както научихме, идеалното е да търсите решение за проблем, ако това вече е било разгледано от някой преди, може да ви спести от повторно изобретяване на същото. Това означава, че ние сме заедно в това и общността е тази, която допринася за вашата работа и вие сте този, който ще допринесе за общността рано или късно. Така че бъдете съпричастни. Това е най-важното средство за напредък на програмиста в кариерата и живота.
Тъй като сме в преход всеки път, по подобен начин всеки друг е в съответните си области. Важно е да поискате и да оцените всички. Не се колебайте да кажете Благодаря, дори ако смятате, че това е просто формалност. Уважавайте времето и усилията на всеки. Ако работите в многофункционален екип и сте благословени с QA (инженери за осигуряване на качество), дори ако регистрират грешки вместо вас, това някак си ви помага и се опитва да спаси вас и компанията от сериозни проблеми.
Един бърз начин да разберете обратната връзка е да се опитате да разберете тяхната роля. Проведете приятелска дискусия и се опитайте да разберете с какви ежедневни предизвикателства се сблъскват и при какви ограничения работят.
В крайна сметка вашата емпатия ще създаде някои скромни приятели около вас. Оттук и добра работна култура.
Накрая бих ви помолил винаги да сте полезни. Бъдете активисти. Нашето съществуване винаги трябва да е от полза за хората около нас.
Кажете ми вашите мисли. Ако смятате, че има място за подобрение в тази статия, винаги можем да ги настаним тук.
