{"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\/et\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"\u00c4rge n\u00f5ustuge arendama seda, mida te ei m\u00f5ista.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00c4rge
\n
\nAlates 2018. aastast olen olnud liider\/esimene\/silmapaistev arendaja meeskonnas \u2013 nimetage seda kuidas soovite, kuid p\u00f5hjus on see, et vastutan t\u00e4ielikult \u00fche mooduli ja k\u00f5igi arendajate eest, kes sellega t\u00f6\u00f6tavad. See positsioon avab mulle uue vaate arendusprotsessile, kuna olen kaasatud suuremasse hulka projekte ja osalen aktiivsemalt otsuste tegemises. Hiljuti, nende kahe asjaolu t\u00f5ttu, taipasin ootamatult, kui palju arusaam m\u00f5jutab koodi ja rakendust.<\/p>\n

M\u00f5te, mida tahan edastada, on, et koodi (ja l\u00f5ppproduktide) kvaliteet on tihedalt seotud sellega, kuiv\u00f5rd inimesed, kes projekteerivad ja koodi kirjutavad, m\u00f5istavad, mida nad tegelikult teevad.<\/p>\n

V\u00f5ib-olla m\u00f5tlete n\u00fc\u00fcd: \"Ait\u00e4h, kapten. Loomulikult on parem m\u00f5ista, mida kirjutad. Muul juhul v\u00f5iks sama h\u00e4sti palgata r\u00fchma ahve, et nad hakkaksid suvalistele klahvidele vajutama ja sellega leppida.\" Ja teil on t\u00e4iesti \u00f5igus. Seega, ma aktsepteerin, et te m\u00f5istate, et \u00fcldine arusaam sellest, mida teete, on vajalik. Seda v\u00f5ib nimetada nullitaseme arusaamiseks ja seda me ei hakka pikalt lahkama. R\u00e4\u00e4gime kindlasti, mida t\u00e4pselt on vaja m\u00f5ista ja kuidas see m\u00f5jutab igap\u00e4evaseid otsuseid, mida teete. Kui oleksin need asjad varem teadnud, oleksin v\u00e4ltinud tohutult raisatud aega ja kahtlast koodi.
\n<\/a><\/noindex>
\nKuigi allpool te koodijuppe ei n\u00e4e, pean siiski vajalikuks r\u00f5hutada, et k\u00f5ik, mida siinkohal \u00f6eldakse, on \u00e4\u00e4rmiselt oluline kvaliteetse ja v\u00e4ljendusrikka koodi kirjutamise jaoks. <\/p>\n

Esmataseme arusaam: Miks see ei t\u00f6\u00f6ta?<\/h4>\n

\nSelle tasemeni j\u00f5uavad arendajad tavaliselt oma karj\u00e4\u00e4ri varases etapis, vahel isegi ilma teiste abita \u2013 v\u00e4hemalt minu t\u00e4helepanekute kohaselt. Kujutage ette, et olete saanud viga teatava funktsiooni kohta: m\u00f5ni rakenduse funktsioon ei t\u00f6\u00f6ta, seda tuleb parandada. Kuidas te k\u00e4itute?<\/p>\n

Tavallinen skeem n\u00e4eb v\u00e4lja j\u00e4rgnev:<\/p>\n

    \n
  1. Leida koodijupp, mis p\u00f5hjustab probleemi (kuidas seda teha, on eraldi teema, mida k\u00e4sitlen oma raamatus vananenud koodist)<\/li>\n
  2. Teha muudatused sellele koodijupile<\/li>\n
  3. Veenduda, et viga on parandatud ja tagasivisioonivigu ei esine<\/li>\n<\/ol>\n

    \nN\u00fc\u00fcd keskendume teisele punktile - muudatuste tegemisele koodis. Selleks on kaks l\u00e4henemist. Esimene: s\u00fcveneda sellesse, mis praeguses koodis toimub, tuvastada viga ja see parandada. Teine: edasi liikuda pimesi - lisada n\u00e4iteks +1 tingimuslikul operaatoril v\u00f5i ts\u00fcklis, vaadata, kas see funktsioon t\u00f6\u00f6tab soovitud stsenaariumis, siis proovida midagi veel ja nii edasi l\u00f5putult.<\/p>\n

    \u00d5ige l\u00e4henemine on esimene. Kuidas selgitab oma raamatus Code Complete Steve McConnell (soovitan seda raamatut v\u00e4ga), iga kord, kui me teeme koodis muudatusi, peaksime olema v\u00f5imelised kindlalt ennustama, kuidas see m\u00f5jutab rakendust. Tsiteerin m\u00e4lu j\u00e4rgi, kuid kui vigade parandus ei t\u00f6\u00f6ta nii nagu ootasite, peaks see teid tugevalt hoiatama, peaksite kahtlema kogu oma tegevuskavas.<\/p>\n

    Kokkuv\u00f5ttes, et teostada kvaliteetset vigade parandust, mis ei halvendaks koodi kvaliteeti, on vajalik m\u00f5ista nii koodi struktuuri kui ka konkreetse probleemi allikat.<\/p>\n

    Teine m\u00f5istmise tase: Miks see toimib?<\/h4>\n

    \nSee tasand saavutatakse oluliselt v\u00e4hem intuitiivselt kui eelmine. Mina, olles veel algaja arendaja, omandasin selle oma juhilt, ja hiljem olen korduvalt sama asja algajatele selgitanud.<\/p>\n

    Seekord kujutame ette, et olete saanud kohe kaks veateadet: esimeses on juttu stsenaariumist A, teises - stsenaariumist B. M\u00f5lemas stsenaariumis toimub midagi valesti. Vastavalt sellele hakkate k\u00f5igepealt esimese vea kallale. J\u00e4rgides esimesest arusaamist l\u00e4htuvaid p\u00f5him\u00f5tteid, s\u00fcvenete korralikult probleemiga seotud koodisse, uurite, miks see paneb rakenduse stsenaariumis A k\u00e4ituma just nii, ja teete m\u00f5istlikud parandused, mis toovad soovitud tulemuse. K\u00f5ik l\u00e4heb suurep\u00e4raselt.<\/p>\n

    Seej\u00e4rel liigute stsenaariumisse B. Kordate stsenaariumi, et p\u00fc\u00fcda viga provotseerida, kuid - \u00fcllatus! - n\u00fc\u00fcd k\u00f5ik t\u00f6\u00f6tab nagu peab. Oma oletuse kinnitamiseks t\u00fchistate A veaga t\u00f6\u00f6tamise k\u00e4igus tehtud muudatused ja B viga naaseb. Teie vigade parandamine lahendas m\u00f5lemad probleemid. Vedas!<\/p>\n

    Te ei oodanud seda \u00fcldse. Olete v\u00e4lja m\u00f5elnud viisi, kuidas parandada A-stsenaariumi viga ja ei tea, miks see t\u00f6\u00f6tas ka B-stsenaariumi puhul. K\u00e4es on aeg, kus on suur kiusatus otsustada, et m\u00f5lemad \u00fclesanded on edukalt t\u00e4idetud. See on t\u00e4iesti loogiline: eesm\u00e4rk oli ju vigade k\u00f5rvaldamine, eks? Kuid t\u00f6\u00f6 ei ole veel l\u00f5ppenud: teil on veel oluline v\u00e4lja selgitada, miks teie tegevus parandas B-stsenaariumi viga. Miks? Sest see v\u00f5ib t\u00f6\u00f6tada vale p\u00f5him\u00f5tete alusel ja siis peate leidma teise v\u00e4ljundi. Siin on paar sellist juhtumit:<\/p>\n