От началото на 2018 година заемам позицията на лидер/началник/водещ разработчик в екипа — наречете го както искате, но сутьтта е, че цялостно отговарям за един от модулите и за всички разработчици, които работят над него. Тази позиция ми дава нова перспектива върху разработването, тъй като участвам в по-голям брой проекти и активно участвам в вземането на решения. Наскоро, благодарение на тези две обстоятелства, неочаквано осъзнах колко силно разбиране влияе на кода и на приложението.
Мисълта, която искам да изразя, е, че качеството на кода (и на крайния продукт) е тясно свързано с това, колко осъзнати са хората, които проектират и пишат кода, относно това, което правят.
Може би в момента мислите: "Благодаря, капитан. Разбира се, добре е да знаеш какво всъщност пишеш. В противен случай, с същия успех можеш да наемеш група маймуни да натискат произволни клавиши и да се успокоиш с това." И сте абсолютно прави. Съответно, приемам за даденост, че осъзнавате, че имате нужда от общо разбиране за това, което правите. Това може да се нарече нулево ниво на разбиране и няма да го разглеждаме подробно. Подробно ще разгледаме какво точно трябва да се разбира и как това влияе на решенията, които вземате всеки ден. Ако бях знаел тези неща предварително, щеше да ме спести много изгубено време и съмняващ се код.
Въпреки че по-долу няма да видите нито ред код, все пак смятам, че всичко казано тук е от голямо значение за писането на качествен и изразителен код.
Първо ниво на разбиране: Защо не работи?
Към това ниво разработчиците обикновено достигат в най-ранните етапи на кариерата си, понякога дори без никаква помощ от околните — поне по моите наблюдения. Представете си, че сте получили доклад за грешка: някаква функция в приложението не работи и трябва да бъде поправена. Как ще действате?
Стандартната схема изглежда така:
- Намерете фрагмента от кода, който предизвиква проблема (как точно се прави — отделна тема, която разглеждам в книгата си за остарял код)
- Направете промени в този фрагмент
- Уверете се, че грешката е отстранена и не се е появила отново
Сега ще се съсредоточим върху втория пункт - въвеждане на промени в кода. Има два подхода към този процес. Първият: да разберем какво точно се случва в текущия код, да открием грешката и да я коригираме. Вторият: да действаме на сляпо - да добавим, да кажем, +1 в условен оператор или цикъл, да видим дали функцията не е заработила в нужния сценарий, след това да пробваме нещо още и така до безкрайност.
Правилният подход е първият. Както обяснява в книгата си Code Complete Стив МакКоннел (между другото, много я препоръчвам), всеки път, когато променяме нещо в кода, трябва да можем уверено да предскажем какво ще повлияе на приложението. Цитирам по памет, но ако корекцията на грешка не сработи както очаквахте, това трябва да ви притесни и да поставите под въпрос целия си план за действие.
Обобщавайки казаното, за да извършите качествена корекция на грешка, която няма да влоши качеството на кода, трябва да разбирате както цялата структура на кода, така и източника на конкретната проблема.
Второ ниво на разбиране: Защо работи?
Това ниво се усвоява много по-малко интуитивно от предишното. Аз, като начинаещ разработчик, го усвоих благодарение на шефа си и по-късно многократно обяснявах същността на случая на новаците.
Този път нека си представим, че сте получили веднага два отчета за грешки: в първия става въпрос за сценарий A, а във втория - за сценарий B. В двата сценария нещо не е наред. Съответно, първо се заемате с първата грешка. Ръководейки се от принципите, които извлякохме за първото ниво на разбиране, се запознавате задълбочено с кода, свързан с проблема, разяснявате защо той кара приложението да се държи по определен начин в сценарий A и правите разумни корекции, които дават именно очаквания резултат. Всичко върви отлично.
След това се прехвърляте на сценарий B. Повтаряте сценария в опит да предизвикате грешка, но - изненада! - сега всичко работи както трябва. За да потвърдите предположението си, отменяте промените, направени по време на работа над грешка A, и грешка B отново се появява. Вашата корекция на грешка реши и двата проблема. Успех!
Не сте очаквали това. Измислихте начин да коригирате грешката в сценарий А и нямате представа защо той проработи и за сценарий B. На този етап изкушението да решите, че и двете задачи са успешно изпълнени, е много голямо. Това е напълно логично: целта всъщност беше да се отстранят грешките, нали? Но работата все още не е свършена: трябва да разберете защо действията ви коригираха грешката в сценарий B. Защо? Защото, може би, той работи на неверни принципи и тогава ще трябва да търсите друг изход. Ето няколко примера за такива случаи:
- тъй като решението не беше насочено конкретно към грешка B с оглед на всички фактори, вие, вероятно без да искате, счупихте функция C.
- не е изключено, че някъде се е скрил още и трети бъг, свързан с тази функция, и вашата корекция на бъг фиксира коректната работа на системата в сценарий B на него. В момента всичко изглежда добре, но в един прекрасен ден този трети бъг ще бъде забелязан и поправен. Тогава в сценарий B отново ще възникне грешка, и ще е добре, ако само там.
Всичко това внася хаос в кода и един ден ще се струпа върху вас — най-вероятно в най-неподходящия момент. Ще се наложи да съберете воля, за да накарате себе си да отделите време за разбиране на това, защо всичко изглежда, че работи, но си струва.
Трето ниво на разбиране: Защо работи?
Моето неотдавнашно осъзнаване е точно свързано с това ниво и вероятно именно то би ми дало най-много предимства, ако бях достигнал до тази мисъл по-рано.
За да стане по-ясно, нека разгледаме пример: необходимо е вашият модул да бъде съвместим с функция X. Не сте особено запознати с функция X, но ви казаха, че за съвместимост с нея трябва да използвате фреймуърк F. Другите модули, които интегрират с X, работят точно с него.
Вашият код от първия ден на живота си изобщо не е взаимодействал с фреймворка F, затова внедряването му няма да е толкова лесно. Това може да доведе до сериозни последствия за някои компоненти на модула. Въпреки това, вие се потапяте в разработката: седмици наред пишете код, тествате, пускате пилотни версии, получавате отзиви, коригирате регресионни грешки, откривате неочаквани усложнения, не успявате да се вместите в първоначално уговорените срокове, пишете още колко трябва код, тествате, получавате обратна връзка, коригирате регресионни грешки — всичко това, за да внедрите фреймворк F.
И в някакъв момент изведнъж осъзнавате — или може би чувате от някого — че, може би, фреймворк F изобщо няма да ви осигури съвместимост с функция X. Може би, всичките тези време и усилия са вложени напълно не в това.
Нещо подобно веднъж се случи по време на работа върху проект, за който отговарях. Защо стана така? Защото не разбирах добре каква е същността на функция X и как тя е свързана с фреймворка F. Как трябваше да постъпя? Да помоля човек, който поставя задачата за разработка, ясно да обясни как предложени действия ще доведат до желания резултат, вместо просто да повтарям това, което е правено за други модули, или да вярвам на думата, че така е нужно за работата на функция X.
Опитът от този проект ме научи да отказвам да започвам процеса на разработка, докато нямаме ясно разбиране защо ни искат да изпълняваме определени действия. Да отказвам с ясни думи. Когато получаваш задача, първоначалният импулс е незабавно да се захванеш с нея, за да не губиш излишно време. Но политиката „замразяваме проекта, докато не влезем в подробностите“ може да съкрати напразно загубеното време с цели порядки.
Дори ако на вас се опитват да натискат, да ви накарат да започнете работа, докато не разбирате защо — съпротивлявайте се. Първо се разберете с каква цел ви поставят такава задача и решете дали това е правилният път до целта. Наложи ми се да узная всичко това чрез горчив опит — надявам се, че на тези, които четат, моят пример ще улесни живота.
Четвърто ниво на разбиране: ???
В програмирането винаги има какво да се научи и смятам, че едва докоснах повърхността на темата за разбирателството. Какви други нива на разбиране открихте през годините, прекарани с кода? Какви решения взехте, които положително се отразиха на качеството на кода и приложението? Кои решения се оказаха погрешни и ви научиха на ценен урок? Споделете опити в коментарите.
Източник: habr.com
