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