Како разумети било који програмски задатак

Напокон је стигао дан. Да ли вам је то први дан на послу или то радите десет година? Нема везе. Сви се на крају нађемо пред задатком који једноставно не разумемо.

Па шта треба да радите? Да ли бисте требали само започети и надати се да ће успети? Да ли бисте требали одмах рећи шефу да то не можете учинити јер не разумете?

Претпостављам да знате да одговор није ни један ни други!

У програмирању, као и у било којој другој професији, открио сам да је готово немогуће проћи кроз недељу (а понекад ни један дан) а да не нађем неки проблем који не разумем.

Али не брините! Имам сјајне вести. Не само да можете да решите овај проблем, већ може бити и добра ствар.

То значи да на неки начин проширујете своје умеће и знање изван онога што сте раније радили и знали.

У следећих неколико параграфа ћу детаљно објаснити како можете премостити јаз између захтева који су вам постављени и знања потребног за извршавање задатка који сте добили.

О „захтевима“

Можда сте приметили да сам користио реч „захтеви“. Та реч може имати одређене конотације у зависности од тога где радите.

Према мом искуству, велике компаније воле захтеве, а мале компаније понекад „не испуњавају захтеве“. Мислим да је ово сасвим у реду за наше овде сврхе.

То је зато што на крају све што радимо као софтверски инжењери решавамо проблеме.

Могли сте да добијете опсежан извештај на сто страница о томе како да решите тај проблем (једном сам имао сат времена састанак око текста за дугме). Или ће можда ваш извршни директор завијати до вашег стола и лежерно питати можете ли решити проблем до петка.

У сваком случају - добили сте задатак и морате бити сигурни да у потпуности разумете тај проблем да бисте га исправно решили!

О степеницама

Нису потребни сви доле наведени кораци за сваки проблем. Само најтежи проблеми за разумевање могу захтевати да пажљиво наставите кроз све кораке о којима ће бити речи у овом чланку.

На многа питања можда нећете одговорити у складу са захтевима које сте добили или само на основу личног искуства.

Можда ћете морати да питате друге програмере, вођу вашег тима, власника производа, пословног аналитичара или чак баку. Можда ћете све морати да питате док завршите!

То је у реду. Значи да ћете раштркано знање узимати и сажимати да бисте боравили на једном месту. То место је у вама самима и сада ћете моћи да постигнете најбољи могући резултат!

Последње упозорење пре него што научите кораке: немојте превише формализовати овај процес. Поента је у томе да вам помогну да брзо разумете проблем. Не би требало да ствара препреке или бирокрацију! Уместо тога, требало би да вам пружи систематски план за решавање проблема који не разумете.

Први корак: Анализа задатка

У овом кораку ћете покушати да разумете шта је од вас тражено. Још не покушаваш да смислиш како то да урадиш!

Овде је важна разлика. Може бити опасно ускочити право у имплементацију без размишљања о свим последицама, или још горе, без прецизног идентификовања онога што је од вас тражено.

Разврстај задатак

Класификовање задатка значи утврђивање врсте посла који ћете радити на решавању овог проблема. Ево неколико примера типова задатака:

  • Исправка грешке
  • Нова карактеристика
  • Нова апликација
  • Задатак истраживања
  • Побољшање перформанси

Запамтите да ово нису све могуће опције.

Циљ је да се утврди шта врсту посла се очекује да уради. Ово је важно јер има директан утицај на оно што раде ти.

Овај корак је посебно важан за нејасне захтеве. Пример нејасног захтева је: „Треба нам начин да очистимо кеш меморију наших клијената након ажурирања веб локације.“

Може бити неколико могућих тумачења.

  1. Морате одмах применити неки механизам за прочишћавање кеша, тако да клијенти увек виде најновија ажурирања.
  2. Морате да истражите све начине на које се меморишу кеш меморије клијената и одредите најбољи начин или начине за њихово уништавање након сваког ажурирања веб локације.
  3. Кеш меморије клијената већ би требало да буду очишћене и треба да пронађете и исправите грешку која их спречава да се очисте.

У овом тренутку, ако нисте потпуно сигурни које се значење користи, требало би да затражите појашњење пре него што наставите.

Наведи шта је задатак у једној или две просте реченице.

Резимирајте сложене захтеве као да су вас питали на чему данас радите. Можда то неће бити тако једноставно, али требали бисте то свести на реченицу или две.

Ако не можете да резимирате задатак, то вероватно значи да ћете га морати поделити на више задатака. Дакле, у основи овај корак постаје лакмус тест да бисте утврдили да ли сте своје задатке организовали у довољно мале делове.

Ево доброг примера резимеа: „Када ажурирамо веб локацију, додајемо јединствени број датотекама како би прегледач знао да треба да користи најновији код.“

Овај задатак пролази лакмус тест једноставности и вероватно вам није потребно да креирате више задатака.

Лош пример може изгледати овако: Када ажурирамо локацију, додајемо јединствени број датотекама тако да прегледач зна да треба да користи најновији код. Такође морамо да пошаљемо поруку нашем ЦДН-у обавештавајући га да треба да ажурира датотеке. Такође ће апликације ИОС и Андроид морати да пошаљу ажурирање у продавницу апликација. Такође ... ”

Овај очигледно пада на тесту. Много је посла и можда ће га требати засебно идентификовати и пратити.

Опишите главне делове

У било ком облику који вам је најпогоднији, сада бисте требали направити листу главних ствари које се морају урадити.

Ово би и даље требали бити врло једноставни сажеци сваког већег корака.

То не би требало да буде корак по корак или детаљан водич за решавање проблема.

Запамтите да још увек анализирате задатак који сте добили. Препоручио бих да их некако запишете. Лично их снимам у својој апликацији Нотес.

Наш задатак кеширања је врло једноставан и можда му заправо није потребан контура. У овом примеру размотрићемо сложеније питање.

Наш следећи задатак је нова карактеристика: „Сваком кориснику треба показати циљани оглас за интерни производ. Овај оглас треба прилагодити њиховим индивидуалним потребама на основу података које смо прикупили. “

Да бисте истакли главне делове, мораћете да размислите јасно шта ће сваки део захтева учинити.

  • Наши тренутни огласи мораће да буду рашчлањени на такав начин да се могу повезати са неком специфичном корисничком метриком.
  • Требаће постојати начин да наш маркетиншки тим мапира нове рекламе на комад или делове корисничких података (без кодирања!)
  • Систем ће морати да обједини показатеље о кориснику који су релевантни за наше огласе.
  • Коначно, морате створити неку врсту система који прима кориснички ИД и приказује оглас.

Лепота овакве листе је та што се може користити за брзу верификацију код вашег тима или шефа! Дакле, у овом примеру, можда сте га водили вођа вашег тима и он је закључио да мора постојати још један главни део:

  • Корисници би требали моћи да нам кажу када више не желе да виде одређене огласе.

Јер на крају крајева, не желимо да нервирамо наше вољене кориснике! Узимајући време за размишљање о свом задатку само неколико минута, уштедели смо сате или дане бола касније идентификовањем и планирањем важног задатка пре него што смо започели са кодирањем.

Пре него што наставимо даље, желим да се осврнем на могуће критике које бисте могли да имате.

Можда мислите: „У правилном послу ово је врста посла коју треба обавити пре него што захтеви икад стигну до програмера“, и ја се дефинитивно слажем с вама!

Међутим, нажалост, не живимо у савршеном свету. Понекад захтеви нису увек у потпуности разрађени пре него што дођу до програмера. То значи да се сви морамо потрудити да правилно проценимо захтеве пре почетка развоја.

Дефинишите проблем или проблеме које покушавате да решите.

Одговорите на питање „зашто ће неко ово користити?“ Или „који стварни или уочени проблем из стварног света покушавам да решим?“

Надам се да је одговор очигледан. За наш пример кеш меморије можете рећи: „Корисници ће увек видети најновија ажурирања“. За пример оглашавања, „корисници ће видети релевантне огласе уместо огласа до којих им није стало“.

Ако одговор није очигледан, вероватно је време да некога питате зашто радите овај задатак! Постављање овог питања водиће вам или до јаснијег разумевања задатка који је пред вама, или до преиспитивања онога што сте тражени.

Надам се да видите благодати било ког од ових одговора! Дубље разумевање проблема и сврхе омогућиће вам да током имплементације доносите одлуке које заправо служе пословним циљевима. Утврђивањем лоших решења или проблема који немају смисла избећи ће се изгубљени напори на послу који на крају никада неће решити проблем.

Други корак: Тумачење и процена захтева

У овом тренутку требало би да имате разумевање шта ћете радити и зашто то радите.

Ваш следећи корак биће разумевање детаља онога што радите, како се од вас очекује и зашто то радите на тај начин.

Појасните све важне појмове који се односе на ваш задатак.

Можда ћете открити да је овај корак важнији ако сте нови програмер у тиму или ако радите у великој компанији. Обе ове ситуације повећавају вероватноћу да ћете у својим захтевима пронаћи непознате појмове.

Услови могу бити пословни услови, попут назива производа, купаца или процеса. Они такође могу бити развојни појмови попут назива алата, апликација, модела, услуга или библиотека.

Морате бити сигурни да разумете све важне појмове, без икакве нејасноће, како бисте били сигурни да свој задатак спроводите правилно.

Можда ћете разумети да треба да креирате начин за приступ обједињеним корисничким информацијама, али да ли разумете шта значи додавање у „дао“?

Можда ћете разумети да требате форматирати податке о огласу, али да ли разумете шта је „МАДФ“ (Означавање фееда података о огласу)?

Ни ја.

Због тога морате идентификовати и дефинисати све важне појмове. Имате веће шансе да задатак погрешно имплементирате ако погрешно схватите дефиниције.

Утврдите како треба обавити задатак

У овом тренутку бисте требали почети да гледате како треба обавити задатак. Овај корак се може веома разликовати у зависности од тога где радите и одређеног задатка који сте добили.

У неким тимовима вам неће бити речено како да примените захтеве, већ ће вам бити речено са којом функционалношћу треба да завршите.

Други ће детаљно описати сваки ваш корак.

Највероватније ваше искуство пада негде на средину.

Ако вам ваш тим није дао упутства, на овом кораку не можете много учинити. Ако сте добили упутства, у овом тренутку ћете желети да се упознате са корацима које ћете морати предузети.

Овај корак делује прилично очигледно, али на редослед који долази долази на нешто на шта бисте требали обратити посебну пажњу.

Природна склоност може бити зароњавање у све детаље задатка пре него што се осигура да се сврха задатка разуме.

Пошто сте прво одвојили време за разумевање задатка, сада ћете имати на уму јаснији циљ приликом процене корака које требате предузети.

Утврдите да ли су проблеми решени

Ту се фаза анализе и фаза интерпретације спајају. У фази анализе усредсредили сте се на циљеве и исходе шире слике, шта и зашто .

У кораку тумачења фокусирали сте се на детаље, како .

Разлог због којег се то назива тумачење и процена је тај што ћете сада упоређивати како са оним што и зашто. Детаље тумачите узимајући у обзир ширу слику. Проценићете детаље и утврдити да ли је првобитни проблем решен.

Запитајте се: Да ли ће кораци који су ми дати резултирати исходом који је ваш задатак био створен? Да ли ће овај исход заиста решити првобитни проблем?

Ако се осећате уверено да су сви проблеми решени и сви детаљи имају смисла, спремни сте да започнете свој посао! У супротном, морате прећи на трећу фазу да бисте решили све сукобе.

Трећи корак: размишљајте критички

У овој фази треба са сигурношћу да изјавиш да разумеш проблем и решење. Последњи корак је осигурати да имате право решење.

Да бисмо створили најбољи могући производ, сви бисмо требали да се осећамо као да имамо одговорност да говоримо када нешто једноставно нема смисла.

С друге стране, не желимо да се несугласице несугласице. Не би требало да кажете да нешто није у реду јер „осећа се погрешно“ или зато што „то не волим“. Морате имати конкретне и добро промишљене разлоге.

Дакле, поставимо нека основна правила о несугласицама.

Знајте када се не слажете

  • Не слажите се док потпуно не разумете.

Никада немојте рећи да нешто није у реду док нисте потпуно сигурни да разумете са чиме се не слажете.

Ако не можете са сигурношћу да наведете проблем и предвиђено решење, не бисте се требали сложити. Ако нисте верификовали своје разумевање, не бисте се требали сложити. Тек када знате да имате најпотпуније могуће разумевање, можете почети да се не слажете.

Ако утврдите да немате све потребне информације, можда је време да зауставите и поново погледате било који од претходних корака пре него што некоме кажете да су захтеви погрешни.

  • Не слажите се око субјективних ствари. Фокусирајте се на стварне потенцијалне проблеме.

„Не свиђа ми се како се то ради“ је субјективно. „Ово ће узроковати проблеме са перформансама због броја операција које су укључене.“ је објективан разлог. Други примери субјективних разлога могу да укључују: „Ово нисам на други начин учинио“ и „Ово решење бих дизајнирао мало другачије, али само због личних преференција“.

  • Нека буду добро образложена објашњења ваших неслагања спремна за изношење.

Ако не можете да објасните зашто нешто није у реду, можете ли заиста рећи да заправо знате да није у реду? Предложио бих да запишете разлоге зашто нешто није у реду и шта се може учинити да се то поправи.

Ако немате решење да то поправите, на почетку јасно наведите да не знате.

Будите опрезни када се не слажете са другима. Главнину свог времена треба потрошити на разумевање и слушање пре него што се сложите.

Ако сте пратили све кораке до ове тачке, врло је вероватно да сте се добро разумели. Али будите пажљиви и будите отвореног ума да сте можда нешто пропустили!

Волим да започнем разговоре рекавши: „Не слажем се с вама, једноставно не разумем“. Касније долази до неслагања ако је потребно, али надамо се никада пре разумевања.

Знајте како се не слажете

Да бисмо били сигурни да се објективно не слажемо, ево неколико мера које ће вам помоћи да утврдите да ли је ваше неслагање валидно.

Објективна неслагања чине једно или више од следећег:

  • Покажите да је решење необавештено.
  • Покажите да је решење погрешно информисано.
  • Покажите да су проблем или решење нелогични.
  • Покажите да је решење непотпуно.

Неинформисаност није увреда, али уместо тога значи да су недостајале информације када је креирано решење. Можда нису знали за систем који тренутно постоји и могу да изврше потребне радње.

Бити погрешно информисан значи да је решење произашло из нетачних информација.

У овом случају они могу помислити да постојећи систем чини нешто што заправо не чини. На пример, можда је тим за СЕО (оптимизацију претраживача) тражио да Гоогле индексира пријављену страницу у вашој апликацији. Гоогле то не може. Погрешно су обавештени о томе шта Гооглеов пописивач ради.

Нелогичан проблем или решење је онај који једноставно нема смисла. Као програмер, мислим да је уобичајени нелогичан захтев за једну функцију која би могла да разбије другу. Могло би се сматрати нелогичним да се то ради, јер би бољело, а не помогло.

Решење које је непотпуно може заиста бити намењено. У развоју софтвера често покушавамо да започнемо прављењем МВП-а (минимално одрживог производа). То значи да у почетку можемо намерно изоставити функционалност која није апсолутно неопходна.

Уместо тога, решење треба сматрати некомплетним само ако не решава тренутни проблем који сте тражили да поправите или ако наведени кораци нису довољни за стварање функционалног производа или функције.

Резиме

Запамтите, немојте превише формализовати овај процес. Требало би да буде брзо и вероватно се састоји од записивања неколико мисли у апликацији Нотес. Тада би то могло довести до неколико разговора са колегама да бисте разјаснили шта треба да радите. То је све!

Ево поједностављене листе корака:

Корак 1 - Анализирајте

  • Класификовати
  • Резиме
  • Оутлине
  • Дефинишите проблем

Корак 2 - Протумачите и процените

  • Појасните појмове
  • Идентификујте задатке
  • Утврдите да ли ће проблем бити решен

Корак 3 - Размислите критички

  • Знајте када се не слажете
  • Знајте како се не слажете

Здраво, ја сам Јустин Фуллер. Тако ми је драго што сте прочитали мој пост! Морам да вас обавестим да је све што сам овде написао моје лично мишљење и да није намењено представљању мог послодавца на било који начин. Сви узорци кода су моји и потпуно су неповезани са кодом Банк Оф Америца.

Такође бих волео да чујемо вас, слободно се повежите са мном на ЛинкедИн-у, Гитхуб-у или Медиум-у. Хвала још једном на читању!