Од почетка 2018. године сам на позицији главног/шефа/главног програмера у тиму – зовите то како хоћете, али поента је да сам ја у потпуности одговоран за један од модула и за све програмере који раде бацам се на посао. Ова позиција ми даје нову перспективу на развојни процес, јер сам укључен у више пројеката и активније сам укључен у доношење одлука. Недавно сам, захваљујући ове две ствари, одједном схватио колико мера разумевања утиче на код и на апликацију.
Оно што желим да нагласим је да је квалитет кода (и коначног производа) уско повезан са то колико су људи који дизајнирају и пишу код свесни онога што раде.
Можда тренутно размишљате: „Хвала, кап. Наравно, било би лепо да уопште разумете шта пишете. У супротном, могли бисте да унајмите групу мајмуна да притисну произвољне тастере и оставите то на томе.” И потпуно сте у праву. Сходно томе, узимам здраво за готово да схватате да је неопходна општа идеја о томе шта радите. Ово се може назвати нултим нивоом разумевања и нећемо га детаљно анализирати. Детаљно ћемо размотрити шта тачно треба да разумете и како то утиче на одлуке које доносите сваки дан. Да сам ове ствари знао унапред, уштедело би ми много изгубљеног времена и сумњивог кода.
Иако испод нећете видети ни један ред кода, и даље верујем да је све што је овде речено од велике важности за писање висококвалитетног, изражајног кода.
Први ниво разумевања: Зашто не функционише?
Програмери обично достижу овај ниво врло рано у својој каријери, понекад чак и без помоћи других – барем према мом искуству. Замислите да сте добили извештај о грешци: нека функција у апликацији не ради, треба је поправити. Како ћете даље?
Стандардна шема изгледа овако:
- Пронађите део кода који узрокује проблем (како то да урадите је посебна тема, покривам га у својој књизи о наслеђеном коду)
- Унесите измене у овај исечак
- Уверите се да је грешка исправљена и да није дошло до грешке регресије
Хајде да се сада фокусирамо на другу тачку - уношење измена у код. Постоје два приступа овом процесу. Први је да се удубимо у оно што се тачно дешава у тренутном коду, идентификује грешку и поправи је. Друго: померајте се по осећају - додајте, рецимо, +1 у условну изјаву или петљу, видите да ли функција ради у жељеном сценарију, затим покушајте нешто друго, и тако у недоглед.
Први приступ је исправан. Као што Стив Меконел објашњава у својој књизи Цоде Цомплете (коју, иначе, топло препоручујем), сваки пут када променимо нешто у коду, требало би да будемо у могућности да са поверењем предвидимо како ће то утицати на апликацију. Цитирам по сећању, али ако исправка грешке не функционише онако како сте очекивали, требало би да будете веома узнемирени и требало би да преиспитате цео свој акциони план.
Да резимирамо оно што је речено, да бисте извршили добру исправку грешке која не деградира квалитет кода, морате разумети и целокупну структуру кода и извор конкретног проблема.
Други ниво разумевања: Зашто функционише?
Овај ниво се схвата много мање интуитивно од претходног. Ја, док сам још био почетник, научио сам то захваљујући свом шефу, а затим сам новопридошлицама више пута објашњавао суштину ствари.
Овог пута, замислимо да сте примили два извештаја о грешци одједном: први се односи на сценарио А, други на сценарио Б. У оба сценарија, нешто се дешава погрешно. Сходно томе, прво се позабавите првом грешком. Користећи принципе које смо развили за разумевање нивоа XNUMX, копате дубоко у код релевантан за проблем, откривате зашто узрокује да се апликација понаша на начин на који се понаша у сценарију А и правите разумна прилагођавања која дају резултат који желите. . Све иде одлично.
Затим прелазите на сценарио Б. Понављате сценарио у покушају да изазовете грешку, али—изненађење! — сада све ради како треба. Да бисте потврдили своју претпоставку, поништите промене које сте направили док сте радили на грешци А, а грешка Б се враћа. Ваша исправка грешака решила је оба проблема. Луцки!
Ниси уопште рачунао на ово. Смислили сте начин да поправите грешку у сценарију А и немате појма зашто је то функционисало за сценарио Б. У овој фази, веома је примамљиво мислити да су оба задатка успешно обављена. Ово је сасвим логично: поента је била да се елиминишу грешке, зар не? Али посао још није завршен: још увек морате да схватите зашто су ваше акције исправиле грешку у сценарију Б. Зашто? Зато што можда ради на погрешним принципима, а онда ћете морати да тражите други излаз. Ево неколико примера таквих случајева:
- Пошто решење није скројено за грешку Б, узимајући у обзир све факторе, можда сте несвесно покварили функцију Ц.
- Могуће је да негде вреба и трећа грешка, везана за исту функцију, и од ње зависи ваша исправка грешака за исправан рад система у сценарију Б. Сада све изгледа добро, али једног дана ће ова трећа грешка бити примећена и исправљена. Тада ће се у сценарију Б грешка поново појавити, и добро је само тамо.
Све ово додаје хаос коду и једног дана ће вам пасти на главу - највероватније у најнеповољнијем тренутку. Мораћете да сакупите своју снагу воље да бисте се натерали да потрошите време на разумевање зашто се чини да све функционише, али вреди тога.
Трећи ниво разумевања: Зашто функционише?
Мој недавни увид се односи управо на овај ниво, и то је вероватно онај који би ми донео највише користи да сам раније дошао на ову идеју.
Да би било јасније, погледајмо пример: ваш модул треба да буде компатибилан са функцијом Кс. Нисте посебно упознати са функцијом Кс, али вам је речено да да бисте били компатибилни са њом морате да користите Ф фрамеворк. модули који се интегришу са Кс раде управо са њим.
Ваш код уопште није био у контакту са Ф оквиром од првог дана његовог живота, тако да његова имплементација неће бити тако лака. Ово ће имати озбиљне последице за неке делове модула. Међутим, бацате се на развој: проводите недеље писајући код, тестирајући, увођење пилот верзија, добијање повратних информација, исправљање грешака регресије, откривање непредвиђених компликација, непоштовање првобитно договорених рокова, писање још кода, тестирање, добијање повратне информације, исправљање грешака регресије – све то у циљу имплементације Ф оквира.
И у неком тренутку одједном схватите – или можда чујете од некога – да вам оквир Ф можда уопште неће дати компатибилност са функцијом Кс. Можда је сво то време и труд уложено потпуно погрешно у то.
Једном се десило нешто слично док сам радио на пројекту за који сам био одговоран. Зашто се то догодило? Зато што сам слабо разумео шта је функција Кс и како је повезана са оквиром Ф. Шта је требало да урадим? Замолите особу која додељује развојни задатак да јасно објасни како намеравани ток акције води до жељеног исхода, уместо да једноставно понавља оно што је урађено за друге модуле или да им верујете да је то оно што функција Кс треба да уради.
Искуство овог пројекта научило ме је да одбијем да започнем процес развоја све док не схватимо зашто се од нас тражи да урадимо одређене ствари. Одбијте директно. Када добијете задатак, први импулс је да га одмах преузмете како не бисте губили време. Али политика „замрзавања пројекта док не уђемо у све детаље“ може смањити изгубљено време за редове величине.
Чак и ако покушају да изврше притисак на вас, да вас натерају да почнете да радите, иако не разумете разлог за то, одуприте се. Прво схватите зашто вам се даје такав задатак и одлучите да ли је то прави пут до циља. Све сам ово морао да научим на тежи начин – надам се да ће мој пример олакшати живот онима који ово читају.
Четврти ниво разумевања: ???
У програмирању се увек може више научити, и верујем да сам само загребао површину теме разумевања. Које друге нивое разумевања сте открили током година рада са кодом? Које сте одлуке донели које су имале позитиван утицај на квалитет кода и апликације? Које су се одлуке показале погрешним и научиле су вас вредној лекцији? Поделите своје искуство у коментарима.
Извор: ввв.хабр.цом