Ärge nõustuge arendama seda, mida te ei mõista.

Alates 2018. aastast olen olnud liider/esimene/silmapaistev arendaja meeskonnas – nimetage seda kuidas soovite, kuid põhjus on see, et vastutan täielikult ühe mooduli ja kõigi arendajate eest, kes sellega töötavad. See positsioon avab mulle uue vaate arendusprotsessile, kuna olen kaasatud suuremasse hulka projekte ja osalen aktiivsemalt otsuste tegemises. Hiljuti, nende kahe asjaolu tõttu, taipasin ootamatult, kui palju arusaam mõjutab koodi ja rakendust.

Mõte, mida tahan edastada, on, et koodi (ja lõppproduktide) kvaliteet on tihedalt seotud sellega, kuivõrd inimesed, kes projekteerivad ja koodi kirjutavad, mõistavad, mida nad tegelikult teevad.

Võib-olla mõtlete nüüd: "Aitäh, kapten. Loomulikult on parem mõista, mida kirjutad. Muul juhul võiks sama hästi palgata rühma ahve, et nad hakkaksid suvalistele klahvidele vajutama ja sellega leppida." Ja teil on täiesti õigus. Seega, ma aktsepteerin, et te mõistate, et üldine arusaam sellest, mida teete, on vajalik. Seda võib nimetada nullitaseme arusaamiseks ja seda me ei hakka pikalt lahkama. Räägime kindlasti, mida täpselt on vaja mõista ja kuidas see mõjutab igapäevaseid otsuseid, mida teete. Kui oleksin need asjad varem teadnud, oleksin vältinud tohutult raisatud aega ja kahtlast koodi.

Kuigi allpool te koodijuppe ei näe, pean siiski vajalikuks rõhutada, et kõik, mida siinkohal öeldakse, on äärmiselt oluline kvaliteetse ja väljendusrikka koodi kirjutamise jaoks.

Esmataseme arusaam: Miks see ei tööta?

Selle tasemeni jõuavad arendajad tavaliselt oma karjääri varases etapis, vahel isegi ilma teiste abita – vähemalt minu tähelepanekute kohaselt. Kujutage ette, et olete saanud viga teatava funktsiooni kohta: mõni rakenduse funktsioon ei tööta, seda tuleb parandada. Kuidas te käitute?

Tavallinen skeem näeb välja järgnev:

1. Leida koodijupp, mis põhjustab probleemi (kuidas seda teha, on eraldi teema, mida käsitlen oma raamatus vananenud koodist)
2. Teha muudatused sellele koodijupile
3. Veenduda, et viga on parandatud ja tagasivisioonivigu ei esine

Nüüd keskendume teisele punktile - muudatuste tegemisele koodis. Selleks on kaks lähenemist. Esimene: süveneda sellesse, mis praeguses koodis toimub, tuvastada viga ja see parandada. Teine: edasi liikuda pimesi - lisada näiteks +1 tingimuslikul operaatoril või tsüklis, vaadata, kas see funktsioon töötab soovitud stsenaariumis, siis proovida midagi veel ja nii edasi lõputult.

Õige lähenemine on esimene. Kuidas selgitab oma raamatus Code Complete Steve McConnell (soovitan seda raamatut väga), iga kord, kui me teeme koodis muudatusi, peaksime olema võimelised kindlalt ennustama, kuidas see mõjutab rakendust. Tsiteerin mälu järgi, kuid kui vigade parandus ei tööta nii nagu ootasite, peaks see teid tugevalt hoiatama, peaksite kahtlema kogu oma tegevuskavas.

Kokkuvõttes, et teostada kvaliteetset vigade parandust, mis ei halvendaks koodi kvaliteeti, on vajalik mõista nii koodi struktuuri kui ka konkreetse probleemi allikat.

Teine mõistmise tase: Miks see toimib?

See tasand saavutatakse oluliselt vähem intuitiivselt kui eelmine. Mina, olles veel algaja arendaja, omandasin selle oma juhilt, ja hiljem olen korduvalt sama asja algajatele selgitanud.

Seekord kujutame ette, et olete saanud kohe kaks veateadet: esimeses on juttu stsenaariumist A, teises - stsenaariumist B. Mõlemas stsenaariumis toimub midagi valesti. Vastavalt sellele hakkate kõigepealt esimese vea kallale. Järgides esimesest arusaamist lähtuvaid põhimõtteid, süvenete korralikult probleemiga seotud koodisse, uurite, miks see paneb rakenduse stsenaariumis A käituma just nii, ja teete mõistlikud parandused, mis toovad soovitud tulemuse. Kõik läheb suurepäraselt.

Seejärel liigute stsenaariumisse B. Kordate stsenaariumi, et püüda viga provotseerida, kuid - üllatus! - nüüd kõik töötab nagu peab. Oma oletuse kinnitamiseks tühistate A veaga töötamise käigus tehtud muudatused ja B viga naaseb. Teie vigade parandamine lahendas mõlemad probleemid. Vedas!

Te ei oodanud seda üldse. Olete välja mõelnud viisi, kuidas parandada A-stsenaariumi viga ja ei tea, miks see töötas ka B-stsenaariumi puhul. Käes on aeg, kus on suur kiusatus otsustada, et mõlemad ülesanded on edukalt täidetud. See on täiesti loogiline: eesmärk oli ju vigade kõrvaldamine, eks? Kuid töö ei ole veel lõppenud: teil on veel oluline välja selgitada, miks teie tegevus parandas B-stsenaariumi viga. Miks? Sest see võib töötada vale põhimõtete alusel ja siis peate leidma teise väljundi. Siin on paar sellist juhtumit:

• Kuna lahendust ei valitud hädavajalikult B vea järgi kõiki tegureid arvestades, võib olla, et olete ise teadmata rikkunud funktsiooni C.
• Pole välistatud, et kuskil peitub ka kolmas bug, mis on seotud sama funktsiooniga, ja teie bugifiks seob B stsenaariumi süsteemi õige toimimise sellele. Praegu näeb kõik hea välja, kuid ühel päeval märgatakse seda kolmandat bugi ja parandatakse. Siis tekib B stsenaariumis jälle viga, ja olgu see ainult seal.

Kõik see lisab koodi kaootilisust ja kukub teile kunagi kaela – tõenäoliselt kõige sobimatumal hetkel. Peate kokku koguma endas jõu, et sundida ennast kulutama aega selle välja selgitamiseks, miks kõik väliselt töötab, kuid see on seda väärt.

Kolmas arusaamise tase: Miks see töötab?

Minu hiljutine arusaam on just selle tasemega seotud ja tõenäoliselt annaks see mulle kõige rohkem eeliseid, kui oleksin selle mõtte peale varem tulnud.

Et asi selgem oleks, võtame näiteks: teie moodul peab olema ühilduv funktsiooniga X. Te ei tunne funktsiooni X eriti hästi, kuid teile on öeldud, et selle ühilduvuse tagamiseks peate kasutama raamistikku F. Teised moodulid, mis integreeruvad X-iga, töötavad just selle raamistikuga.

Teie kood ei ole oma elu esimesest päevast alates kokku puutunud raamistiku F-ga, seega ei ole selle rakendamine sugugi lihtne. See toob kaasa tõsiseid tagajärgi mõnede mooduli osade jaoks. Sellegipoolest sukeldute te arendusse: nädalate viisi kirjutate koodi, testite, väljastate esialgseid versioone, saate tagasisidet, parandate regressioonivigu, avastate ettenägematuid probleeme, ei mahu algselt kokkulepitud tähtaegadesse, kirjutate veel mõne koodi, testite, saate tagasisidet, parandate regressioonivigu — kõik selleks, et rakendada raamistiku F-d.

Ja mingil hetkel te äkki taipate — või võib-olla kuulete kelleltki — et raamistiku F kasutamine ei pruugi teile anda ühildatavust funktsiooniga X. Võib-olla olid kõik need aeg ja jõud suunatud täiesti valele teele.

Midagi sarnast juhtus kunagi projekti käigus, mille eest ma vastutasin. Miks see juhtus? Sest ma ei mõistnud hästi, mis on funktsiooni X olemus ja kuidas see on seotud raamistiku F-ga. Mida oleksin pidanud tegema? Paluma inimesel, kes ülesande sõnastab, selgelt selgitada, kuidas kavandatud tegevusplaan viib soovitud tulemuseni, selle asemel, et lihtsalt korrata seda, mida on tehtud teiste moodulite jaoks, või uskuda, et nii on vajalik funktsiooni X töötamiseks.

Selle projekti kogemus õpetas mind keelduma arendustegevuse alustamisest, kui meil ei ole selget arusaama, miks meilt palutakse teatud tegevusi teha. Keelduma otse. Kui saad ülesande, on esimene impulss — haarata selle kallale kohe, et mitte aega raisata. Kuid poliitika „projekti peatamine, kuni saame kõigest arusaamise“ võib hoida raisatud aega tühja kulumise eest.

Isegi kui teid püüavad survestada, sundides teid tööle asumiseks, kuigi te ei mõista, miks see on vajalik — vastanduge. Esiteks uurige, millise eesmärgiga teile selline ülesanne antakse, ja otsustage, kas see on õige tee eesmärgi saavutamiseks. Ma pidin selle kõik valusalt õppima — loodetavasti aitab minu kogemus neid, kes seda loevad.

Neljas arusaamistasandi tase: ???

Programmeerimises on alati midagi uut õppida, ja ma arvan, et olen vaid teema pinnale tõmmanud. Milliseid teisi arusaamade tasandeid olete aastate jooksul koodiga töötades avastanud? Milliseid otsuseid olete teinud, mis on hästi mõjunud koodi ja rakenduse kvaliteedile? Millised otsused on osutunud valevalikuks ja õpetanud teile väärtuslikku õpetust? Jagage oma kogemusi kommentaarides.

Allikas: habr.com