Од почетокот на 2018 година, ја држам позицијата водечки/шеф/воден програмер во тимот - наречете го како сакате, но поентата е дека јас сум целосно одговорен за еден од модулите и за сите програмери кои работат на тоа. Оваа позиција ми дава нова перспектива за развојниот процес, бидејќи сум вклучен во повеќе проекти и поактивно вклучен во донесувањето одлуки. Неодамна, благодарение на овие две работи, одеднаш сфатив колку мерката за разбирање влијае на кодот и апликацијата.
Поентата што сакам да ја напоменам е дека квалитетот на кодот (и финалниот производ) е тесно поврзан со тоа колку луѓето што го дизајнираат и пишуваат кодот се свесни за она што го прават.
Можеби мислите токму сега: „Благодарам, кап. Се разбира, би било убаво да се разбере она што го пишувате воопшто. Во спротивно, можеби ќе ангажирате група мајмуни да удираат произволни клучеви и да го оставите тоа“. И ти си апсолутно во право. Според тоа, земам здраво за готово дека сфаќате дека е неопходно да имате општа идеја за тоа што правите. Ова може да се нарече нулто ниво на разбирање и нема да го анализираме детално. Ќе разгледаме детално што точно треба да разберете и како тоа влијае на одлуките што ги донесувате секој ден. Ако ги знаев овие работи однапред, ќе ми заштедише многу потрошено време и сомнителен код.
Иако нема да видите ниту една линија код подолу, сепак верувам дека сè што е кажано овде е од големо значење за пишување висококвалитетен, експресивен код.
Прво ниво на разбирање: Зошто не функционира?
Програмерите обично го достигнуваат ова ниво многу рано во нивните кариери, понекогаш дури и без никаква помош од други - барем според моето искуство. Замислете дека сте добиле извештај за грешка: некоја функција во апликацијата не работи, таа треба да се поправи. Како ќе продолжите?
Стандардната шема изгледа вака:
- Најдете го парчето код што го предизвикува проблемот (како да го направите ова е посебна тема, јас го покривам во мојата книга за наследниот код)
- Направете промени во овој фрагмент
- Проверете дали грешката е поправена и дека не се појавиле грешки при регресија
Сега да се фокусираме на втората точка - правење промени во кодот. Постојат два пристапи кон овој процес. Првиот е да истражувате што точно се случува во тековниот код, да ја идентификувате грешката и да ја поправите. Второ: движете се според чувството - додадете, да речете, +1 на условна изјава или циклус, видете дали функцијата работи во посакуваното сценарио, потоа обидете се со нешто друго, и така натаму до бесконечност.
Првиот пристап е точен. Како што објаснува Стив Меконел во својата книга Code Complete (која, патем, топло ја препорачувам), секој пат кога менуваме нешто во кодот, треба да можеме со сигурност да предвидиме како тоа ќе влијае на апликацијата. Цитирам од меморија, но ако поправката на грешки не работи како што очекувавте, треба да бидете многу вознемирени и треба да го преиспитате целиот ваш акционен план.
Да го резимираме она што е кажано, за да се изврши добро поправка на грешки што не го намалува квалитетот на кодот, треба да ја разберете и целата структура на кодот и изворот на конкретниот проблем.
Второ ниво на разбирање: Зошто функционира?
Ова ниво се сфаќа многу помалку интуитивно од претходното. Јас, додека сè уште бев почетник програмер, го научив тоа благодарение на мојот шеф и последователно постојано им ја објаснував суштината на работата на новодојденците.
Овој пат, да замислиме дека сте добиле два извештаи за грешки одеднаш: првиот е за сценариото А, вториот е за сценариото Б. Во двете сценарија, нешто не е во ред. Според тоа, прво се справувате со првата грешка. Користејќи ги принципите што ги развивме за разбирање на Ниво XNUMX, ќе копате длабоко во кодот релевантен за проблемот, ќе откриете зошто предизвикува апликацијата да се однесува како што се однесува во сценариото А и ќе направите разумни прилагодувања што го даваат посакуваниот резултат. . Се оди одлично.
Потоа продолжувате на сценариото Б. Го повторувате сценариото во обид да предизвикате грешка, но - изненадување! — сега сè функционира како што треба. За да ја потврдите вашата претпоставка, ги поништувате промените што сте ги направиле додека работите на бубачката А и бубачката Б се враќа. Вашата поправка на грешки ги реши двата проблеми. Среќа!
Воопшто не сметаше на ова. Најдовте начин да ја поправите грешката во сценариото А и немате поим зошто тоа функционираше за сценариото Б. Во оваа фаза, многу е примамливо да се мисли дека двете задачи се успешно завршени. Ова е сосема логично: поентата беше да се елиминираат грешките, нели? Но, работата сè уште не е завршена: сè уште треба да сфатите зошто вашите постапки ја коригираа грешката во сценариото Б. Зошто? Затоа што можеби работи на погрешни принципи, а потоа ќе треба да барате друг излез. Еве неколку примери на такви случаи:
- Бидејќи решението не е прилагодено на грешката Б, земајќи ги предвид сите фактори, можеби несвесно сте ја прекинале функцијата В.
- Можно е некаде да се крие и трета грешка, поврзана со истата функција, а вашата поправка на грешки зависи од тоа за правилно функционирање на системот во сценарио Б. Сега сè изгледа добро, но еден ден оваа трета грешка ќе биде забележана и поправена. Тогаш во сценариото Б грешката ќе се појави повторно, и добро е само таму.
Сето ова додава хаос во кодот и еден ден ќе ви падне на глава - најверојатно во најнеповолниот момент. Ќе треба да ја соберете вашата волја за да се присилите да потрошите време за да разберете зошто се чини дека сè функционира, но вреди.
Трето ниво на разбирање: Зошто функционира?
Мојот неодамнешен увид се однесува токму на ова ниво, и веројатно тоа е она што би ми донело најголема корист доколку дојдов до оваа идеја порано.
За да биде појасно, ајде да погледнеме пример: вашиот модул треба да биде компатибилен со функцијата X. Не сте особено запознаени со функцијата X, но ви беше кажано дека за да бидете компатибилен со неа, треба да ја користите рамката F. Друго Модулите кои се интегрираат со X работат токму со него.
Вашиот код воопшто не е во контакт со рамката F од првиот ден од неговиот живот, така што неговото спроведување нема да биде толку лесно. Ова ќе има сериозни последици за некои делови од модулот. Како и да е, се фрлате во развој: поминувате неколку недели пишувајќи код, тестирате, објавувате пилот-верзии, добивате повратни информации, поправате грешки во регресијата, откривате непредвидени компликации, не ги исполнувате првично договорените рокови, пишувате уште некој код, тестирате, добивате комуникација со повратни информации, корекција на грешки во регресијата - сето тоа со цел да се имплементира рамката F.
И во одреден момент одеднаш сфаќате - или можеби слушнете од некого - дека можеби рамката F воопшто нема да ви даде компатибилност со карактеристиката X. Можеби сето тоа време и напор се вложени сосема погрешно за тоа.
Нешто слично се случи еднаш додека работев на проект за кој јас бев одговорен. Зошто се случи ова? Бидејќи имав малку разбирање за тоа што е функцијата X и како таа е поврзана со рамката F. Што требаше да направам? Побарајте од лицето кое ја доделува задачата за развој јасно да објасни како планираниот тек на дејствување води до посакуваниот исход, наместо едноставно да го повторува она што е направено за другите модули или да го земе зборот дека тоа е она што треба да го направи карактеристиката X.
Искуството од овој проект ме научи да одбивам да го започнам процесот на развој додека не добиеме јасно разбирање зошто од нас се бара да направиме одредени работи. Одбијте целосно. Кога ќе добиете задача, првиот импулс е веднаш да ја преземете за да не губите време. Но, политиката „замрзнување на проектот додека не ги навлеземе сите детали“ може да го намали потрошеното време по редови на големина.
Дури и ако се обидат да ве притиснат, да ве натераат да започнете со работа, иако не го разбирате образложението за ова, пружете се. Прво, дознајте зошто ви е дадена таква задача и одлучете дали ова е вистинскиот пат до целта. Сето ова морав да го научам на потешкиот начин - се надевам дека мојот пример ќе им го олесни животот на оние кои го читаат ова.
Четврто ниво на разбирање: ???
Секогаш има повеќе да се научи во програмирањето и верувам дека само ја изгребав површината на темата за разбирање. Кои други нивоа на разбирање сте ги откриле во текот на годините на работа со код? Кои одлуки ги донесовте кои имаа позитивно влијание врз квалитетот на кодот и апликацијата? Кои одлуки се покажаа како погрешни и ве научија вредна лекција? Споделете го вашето искуство во коментарите.
Извор: www.habr.com