{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"Ne pristajte na razvoj onoga \u0161to ne razumijete","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ne
\n
\nOd po\u010detka 2018. godine obna\u0161am du\u017enost vo\u0111e\/\u0161efa\/vode\u0107eg programera u timu \u2014 kako god \u017eelite to nazvati, bitno je da sam potpuno odgovoran za jedan od modula i za sve programere koji na njemu rade. Ova pozicija mi otvara novi pogled na proces razvoja jer sam uklju\u010d\u0435\u043d u ve\u0107i broj projekata i aktivnije sudjelujem u dono\u0161enju odluka. Nedavno, zahvaljuju\u0107i ova dva okolnosti, iznenada sam shvatio koliko znanje utje\u010de na kod i na aplikaciju.<\/p>\n

Misao koju \u017eelim izraziti svodi se na to da je kvaliteta koda (i kona\u010dnog proizvoda) usko povezana s tim koliko ljudi koji se bave dizajnom i pi\u0161u kod, svjesni su onoga \u0161to zapravo rade.<\/p>\n

Mo\u017eda sada mislite: \u201eHvala, kapetane. Naravno, bilo bi dobro razumjeti \u0161to uop\u0107e pi\u0161e\u0161. U suprotnom, s istim uspjehom mo\u017eemo unajmiti grupu majmuna da udaraju po nasumi\u010dnim tipkama i time se smiriti.\u201c I potpuno ste u pravu. Stoga prihva\u0107am kao \u010dinjenicu: svjesni ste da imati op\u0107e razumijevanje onoga \u0161to radite, jest neophodno. To mo\u017eemo nazvati nultim nivoom razumijevanja, i njega ne\u0107emo detaljno razra\u0111ivati. Detaljno \u0107emo obraditi \u0161to to\u010dno treba razumjeti i kako to utje\u010de na odluke koje donosite svaki dan. Da sam znao te stvari ranije, to bi me oslobodilo mno\u0161tva izgubljenog vremena i sumnjivog koda.
\n<\/a><\/noindex>
\nIako dolje ne\u0107ete vidjeti ni jednu liniju koda, ipak smatram da sve \u0161to je ovdje re\u010deno ima velik zna\u010daj za pisanje kvalitetnog, izrazitog koda. <\/p>\n

Prvi nivo razumijevanja: Za\u0161to ne radi?<\/h4>\n

\nNa ovaj nivo programeri obi\u010dno dolaze u najranijim fazama svoje karijere, ponekad \u010dak i bez i\u010dije pomo\u0107i \u2014 barem prema mojim zapa\u017eanjima. Zamislite da ste dobili bug report: neka funkcija u aplikaciji ne radi, treba je popraviti. Kako \u0107ete postupiti?<\/p>\n

Standardna shema izgleda ovako:<\/p>\n

    \n
  1. Prona\u0107i dio koda koji izaziva problem (kako to u\u010diniti \u2014 posebna je tema koju razra\u0111ujem u svojoj knjizi o zastarjelom kodu)<\/li>\n
  2. Unijeti promjene u taj dio koda<\/li>\n
  3. Provjeriti je li bug ispravljen i da regresivne pogre\u0161ke nisu nastale<\/li>\n<\/ol>\n

    \nSada \u0107emo se usredoto\u010diti na drugi dio \u2014 promjenu u kodu. Postoje dva pristupa ovom procesu. Prvi: razumjeti \u0161to se to\u010dno doga\u0111a u trenutnom kodu, otkriti gre\u0161ku i ispraviti je. Drugi: kretati se nasumice \u2014 dodati, recimo, +1 u uvjetni operator ili petlju, vidjeti ho\u0107e li to funkcionirati u potrebnom scenariju, a zatim isprobavati jo\u0161 ne\u0161to i tako unedogled.<\/p>\n

    Ispravan pristup je prvi. Kao \u0161to u svojoj knjizi Code Complete obja\u0161njava Steve McConnell (ina\u010de, jako je preporu\u010dujem), svaki put kada ne\u0161to mijenjamo u kodu, trebali bismo biti sposobni s povjerenjem predvidjeti kako \u0107e to utjecati na aplikaciju. Citiram iz sje\u0107anja, ali ako popravak gre\u0161ke ne funkcionira kako ste o\u010dekivali, to bi vas trebalo ozbiljno zabrinuti, trebali biste preispitati \u010ditav svoj plan.<\/p>\n

    Sve u svemu, kako bi se izvr\u0161ilo kvalitetno ispravljanje gre\u0161ke koje ne\u0107e pogor\u0161ati kvalitetu koda, potrebno je razumjeti i cijelu strukturu koda i izvor konkretne problematike.<\/p>\n

    Druga razina razumijevanja: Za\u0161to to radi?<\/h4>\n

    \nOva razina se shva\u0107a mnogo manje intuitivno od prethodne. Kao mladi programer, usvojio sam je zahvaljuju\u0107i svom \u0161efu, a kasnije sam je vi\u0161e puta obja\u0161njavao po\u010detnicima.<\/p>\n

    Ovaj put zamislite da ste primili dva izvje\u0161taja o gre\u0161ci: prvi se odnosi na scenarij A, a drugi na scenarij B. U oba scenarija ne\u0161to nije u redu. Prema tome, prvo se bavite prvim problemom. Slijede\u0107i principe koje smo odredili za prvu razinu razumijevanja, pa\u017eljivo prou\u010davate kod povezan s problemom, otkrivate za\u0161to aplikacija reagira na odre\u0111eni na\u010din u scenariju A i unosite razumne ispravke koje daju to\u010dno onaj rezultat kojeg ste o\u010dekivali. Sve ide odli\u010dno.<\/p>\n

    Nakon toga prelazite na scenarij B. Ponovno provodite scenarij u poku\u0161aju da izazovete gre\u0161ku, ali \u2014 iznena\u0111enje! \u2014 sada sve funkcionira kako treba. Da biste potvrdili svoju pretpostavku, poni\u0161tavate promjene napravljene tijekom rada na gre\u0161ci A, a gre\u0161ka B se ponovno pojavljuje. Va\u0161e ispravljanje gre\u0161ke rije\u0161ilo je oba problema. Imate sre\u0107e!<\/p>\n

    Niste se nadali da \u0107e to tako ispasti. Smislili ste na\u010din da ispravite gre\u0161ku u scenariju A i nemate pojma za\u0161to je to uspelo u scenariju B. U ovoj fazi postoji velika isku\u0161enja da se zaklju\u010di da su oba zadatka uspe\u0161no zavr\u0161ena. To ima smisla: kona\u010dno, svrha je bila ispraviti gre\u0161ke, zar ne? Ali rad jo\u0161 nije gotov: morate se jo\u0161 pozabaviti pitanjem za\u0161to su va\u0161e radnje ispravile gre\u0161ku u scenariju B. Za\u0161to? Zato \u0161to mo\u017eda koristi pogre\u0161ne principe, i tada \u0107ete morati da potra\u017eite drugo re\u0161enje. Evo nekoliko primera takvih slu\u010dajeva:<\/p>\n