2018. aasta algusest olen töötanud meeskonnas juhtiva/bossi/juhtarendaja ametikohal – nimetage kuidas tahate, aga asi on selles, et vastutan täielikult ühe mooduli ja kõigi arendajate eest, kes töötavad. selle kallal. See ametikoht annab mulle arendusprotsessile uue vaatenurga, kuna olen rohkemates projektides ja aktiivsemalt kaasatud otsuste tegemisele. Hiljuti sain tänu nendele kahele asjale järsku aru, kui palju mõistmise mõõde koodi ja rakendust mõjutab.
Mõte, mida ma tahan rõhutada, on see, et koodi (ja lõpptoote) kvaliteet on tihedalt seotud sellega, kui teadlikud on koodi kujundavad ja kirjutavad inimesed sellest, mida nad teevad.
Võib-olla mõtlete praegu: "Aitäh, Cap. Muidugi oleks tore üldiselt aru saada, mida sa kirjutad. Vastasel juhul võite sama hästi palgata rühma ahve, kes suvalisi klahve löövad ja jätate selle sinnapaika. Ja sul on täiesti õigus. Sellest tulenevalt pean enesestmõistetavaks, et mõistate, et üldine ettekujutus sellest, mida te teete, on vajalik. Seda võib nimetada mõistmise nulltasemeks ja me ei hakka seda üksikasjalikult analüüsima. Vaatame üksikasjalikult, mida täpselt peate mõistma ja kuidas see mõjutab teie igapäevaseid otsuseid. Kui ma oleksin neid asju ette teadnud, oleks see säästnud palju raisatud aega ja küsitavat koodi.
Kuigi te ei näe allpool ühtegi koodirida, usun siiski, et kõik siin öeldu on kvaliteetse ja väljendusrikka koodi kirjutamisel väga oluline.
Esimene mõistmise tase: miks see ei tööta?
Tavaliselt jõuavad arendajad sellele tasemele oma karjääri alguses, mõnikord isegi ilma teiste abita – vähemalt minu kogemuse põhjal. Kujutage ette, et saite veateate: mõni rakenduse funktsioon ei tööta, see tuleb parandada. Kuidas edasi?
Standardskeem näeb välja selline:
- Leidke probleemi põhjustav koodijupp (kuidas seda teha on eraldi teema, käsitlen seda oma pärandkoodi käsitlevas raamatus)
- Tehke selles väljavõttes muudatused
- Veenduge, et viga on parandatud ja regressioonivigu pole esinenud
Nüüd keskendume teisele punktile – koodis muudatuste tegemisele. Sellel protsessil on kaks lähenemisviisi. Esimene on süveneda sellesse, mis praeguses koodis täpselt toimub, tuvastada viga ja see parandada. Teiseks: liikuge tunnetuse järgi – lisage tingimuslausele või tsüklile näiteks +1, vaadake, kas funktsioon töötab soovitud stsenaariumi korral, seejärel proovige midagi muud ja nii edasi lõpmatuseni.
Esimene lähenemine on õige. Nagu Steve McConnell oma raamatus Code Complete selgitab (mida ma, muide, väga soovitan), peaksime iga kord, kui koodis midagi muudame, suutma kindlalt ennustada, kuidas see rakendust mõjutab. Tsiteerin mälu järgi, kuid kui veaparandus ei tööta ootuspäraselt, peaksite olema väga ärevil ja seadma kahtluse alla kogu oma tegevuskava.
Öeldu kokkuvõtteks: selleks, et teha hea veaparandus, mis ei halvenda koodi kvaliteeti, peate mõistma nii koodi kogu struktuuri kui ka konkreetse probleemi allikat.
Teine mõistmise tase: miks see töötab?
Seda taset mõistetakse palju vähem intuitiivselt kui eelmist. Mina, olles alles algaja arendaja, õppisin selle tänu oma ülemusele selgeks ja selgitasin hiljem korduvalt uustulnukatele asja olemust.
Kujutagem seekord ette, et saite kaks veateadet korraga: esimene puudutab stsenaariumi A, teine stsenaariumi B. Mõlema stsenaariumi puhul juhtub midagi valesti. Seetõttu lahendate kõigepealt esimese vea. Kasutades põhimõtteid, mille oleme välja töötanud XNUMX. taseme mõistmiseks, uurite sügavalt probleemiga seotud koodi, selgitate välja, miks see põhjustab rakenduse käitumist nii, nagu see stsenaariumi A korral käitub, ja teete mõistlikke muudatusi, mis annavad soovitud tulemuse. . Kõik läheb suurepäraselt.
Seejärel liigute edasi stsenaariumi B juurde. Kordate stsenaariumit, püüdes tõrget esile kutsuda, kuid üllatus! — nüüd töötab kõik nii nagu peab. Oma oletuse kinnitamiseks võtate tagasi vea A kallal töötamise ajal tehtud muudatused ja viga B tuleb tagasi. Teie veaparandus lahendas mõlemad probleemid. Õnnelik!
Sa ei arvestanud sellega üldse. Olete välja mõelnud viisi stsenaariumi A vea parandamiseks ja teil pole aimugi, miks see stsenaariumi B puhul toimis. Praegu on väga ahvatlev arvata, et mõlemad ülesanded on edukalt täidetud. See on üsna loogiline: eesmärk oli vigade kõrvaldamine, kas pole? Kuid töö pole veel lõppenud: peate veel välja mõtlema, miks teie tegevus stsenaariumi B vea parandas. Miks? Sest see võib töötada valedel põhimõtetel ja siis peate otsima teist väljapääsu. Siin on paar näidet sellistest juhtumitest:
- Kuna lahendust ei kohandatud veale B, võisite kõiki tegureid arvesse võttes funktsiooni C teadmatult rikkuda.
- Võimalik, et kuskil varitseb ka kolmas viga, mis on seotud sama funktsiooniga ja sellest sõltub teie veaparandus süsteemi korrektseks tööks stsenaariumi B korral. Praegu tundub kõik hea, kuid ühel päeval märgatakse ja parandatakse seda kolmandat viga. Seejärel kordub stsenaariumi B viga uuesti ja see on hea, kui ainult seal.
Kõik see lisab koodi kaost ja kukub kunagi pähe – tõenäoliselt kõige ebasobivamal hetkel. Peate koguma oma tahtejõudu, et sundida end kulutama aega, et mõista, miks kõik näib toimivat, kuid see on seda väärt.
Kolmas mõistmise tase: miks see töötab?
Minu hiljutine arusaam on seotud just selle tasemega ja ilmselt oleks see mulle kõige rohkem kasu toonud, kui oleksin selle mõtteni varem jõudnud.
Et see oleks selgem, vaatame näidet: teie moodul tuleb muuta funktsiooniga X ühilduvaks. Te ei ole funktsiooniga X eriti tuttav, kuid teile öeldi, et sellega ühildumiseks peate kasutama F raamistikku. moodulid, mis integreeruvad X-ga, töötavad täpselt temaga.
Teie kood pole F-raamistikuga selle esimesest elupäevast peale üldse kokku puutunud, nii et selle juurutamine ei ole nii lihtne. Sellel on mooduli mõnele osale tõsised tagajärjed. Küll aga viskad end arendusse: kulutad nädalaid koodi kirjutamisele, testimisele, pilootversioonide juurutamisele, tagasiside saamisele, regressioonivigade parandamisele, ettenägematute komplikatsioonide avastamisele, algselt kokkulepitud tähtaegade mittejärgimisele, veel koodi kirjutamisele, testimisele, tagasisidesuhtlusele, regressioonivigade parandamine – seda kõike F-raamistiku rakendamiseks.
Ja ühel hetkel sa mõistad äkki – või võib-olla kuuled kelleltki –, et võib-olla ei anna raamistik F sulle üldse ühilduvust funktsiooniga X. Võib-olla oli kogu see aeg ja vaev selle jaoks täiesti valesti pandud.
Midagi sarnast juhtus kord, kui töötasin projekti kallal, mille eest mina vastutasin. Miks see juhtus? Kuna mul oli vähe arusaamist, mis on funktsioon X ja kuidas see on seotud raamistikuga F. Mida ma oleksin pidanud tegema? Paluge arendusülesannet määraval inimesel selgelt selgitada, kuidas kavandatud tegevusviis soovitud tulemuseni viib, selle asemel, et korrata lihtsalt teiste moodulite puhul tehtut või tunnistada, et just seda funktsiooni X peab tegema.
Selle projekti kogemus õpetas mind keelduma arendusprotsessi alustamast enne, kui meil on selge arusaam, miks meilt teatud asju palutakse. Keeldu otse. Kui saate ülesande, on esimene impulss see kohe kätte võtta, et mitte aega raisata. Kuid poliitika "külmutage projekt, kuni jõuame kõigisse üksikasjadesse" võib raisatud aega suurusjärkude võrra vähendada.
Isegi kui nad püüavad teile survet avaldada, sundida teid tööle asuma, kuigi te ei mõista selle põhjust, seiske vastu. Kõigepealt mõelge välja, miks teile selline ülesanne antakse, ja otsustage, kas see on õige tee eesmärgi saavutamiseks. Ma pidin seda kõike kõvasti õppima – loodan, et minu eeskuju teeb nende elu lihtsamaks, kes seda loevad.
Neljas mõistmise tase: ???
Programmeerimises on alati rohkem õppida ja ma usun, et olen mõistmise teemal vaid pinna kriipinud. Milliseid muid mõistmise tasemeid olete aastate jooksul koodiga töötades avastanud? Milliseid otsuseid tegite, mis mõjutasid positiivselt koodi ja rakenduse kvaliteeti? Millised otsused osutusid valedeks ja andsid teile väärtusliku õppetunni? Jagage oma kogemusi kommentaarides.
Allikas: www.habr.com