Nõuanded pärandkoodi käsitlemiseks

Ikooniline APPLE MACINTOSH 128K

Kui ilmub mõiste “pärandkood”, öeldakse seda tavaliselt või võetakse vastu põlguse varjundiga. Esialgne Google'i otsing „pärandkoodide meemid” toob sadu ja sadu pildimakrosid inimestest, kes rebivad oma juuksed välja, näevad pimestatud või tohutult pettunud.

Kui hakkasin 5 kuud tagasi tootearendusettevõttes tarkvaraarendajana töötama, polnud mul aimugi, mis on pärandkood või mis sellega töötamine kaasa toob.

Neljanda kuu jooksul paluti mul lisada lülitusfiltri moodul rakendusele, mille üks mu töökaaslane ehitas kaks või kolm aastat tagasi. See tundus piisavalt lihtne; Ma oleksin suurema osa viimasest kolmest aastast töötanud uskumatult keeruka rakenduse kallal, mis hõlmaks standardset pinu: TypeScript / React / Angular / Dotnet. Olin juba lahendanud paljud ainulaadsed probleemid ja tundsin end piisavalt kodeerimisvõimes, et teha lihtne moodus päringu parameetrite edastamiseks taustaprogrammile.

Nagu arvata võis, polnud see sugugi nii lihtne. Aga miks?

Mis on pärandkood ja miks sellega tegelemine võib olla keeruline

Pärandkood on kood, mis on päritud teiselt arendajalt või meeskonnalt, kes kasutab vanemaid tehnoloogiaid, mida enam ei toetata või on uuemaga asendatud. Paljud programmeerijad ütlevad, et “kood saab pärandkoodiks kohe, kui see on kirjutatud”. Funktsionaalne erinevus tavapärase ja pärandkoodi vahel võib olla lihtsalt selles, et sellel on erinevad tavapärased, võrreldes sellega, millega olete harjunud töötama.

Minu puhul kasutas rakendus XAML- ja T4-tekstimallide kasutamist, mitte põhilist C # -koodi, ja see polnud nii tugevalt trükitud, kui olin harjunud. See muutis mul andmete struktuuri mõistmise natuke raskemaks. Ükski tüüp ei tähendanud seda, et sattusin runErrorsisse palju sagedamini TypeErrorsisse, mida võib suure funktsiooni kirjutamisel olla keeruline siluda. Lisaks kasutas rakendus rakendust palju vanemat dotneti versiooni, mida oli vaja ühildada komponentide teegi ühilduva versiooniga.

Enne kui ma hakkan mõtlema pärandkoodi mõistlikkuse ja otstarbekuse mõistmise üle, on vaja lisada vastutusest lahtiütlemine, et pärandkood pole kõik halb ja pärandiprojekti kallal töötamine ei pea olema kohutav. Vastupidi, pärandkoodiga töötamine õpetas mind olema paindlik, kannatlik ja ennekõike andis kogemus mulle võimaluse lahendada probleeme uues kontekstis uue vaatenurgaga.

Tegelikult tegi see minust parema arendaja, kui ma olin enne, kui hakkasin läbi töötama eelnimetatud koodeksi kaudu, ja loodetavasti võib teie pärandprojekt õpetada teile ka midagi.

Kuidas toimida pärandkoodiga tehnilisel tasandil

Lugege võimaluse korral dokumentatsiooni ja koodikommentaare

Täiuslikus maailmas on igas kooditabelis kindel README, mis sisaldab sisulisi selgitusi projekti toimimise kohta, koodikommentaare, mis selgitavad algse autori täpset loogikat, ja kogu rakendus on mõistlik. Kuid seda juhtub harva. Paljud README-d ei uuene projekti arenedes, inimesed unustavad kirjutada kommentaare, eeldavad, et nende loogika on uuele arendajale ilmne või lihtsalt kulub nende asjade eest hoolitsemiseks aeg.

Vaadake koodeksibaasi tervikuna

Kui olete kadunud ega tea, kust alustada, küsige endalt järgmisi küsimusi:

  • Mis on rakenduse eesmärk?
  • Kuidas andmed rakenduse kaudu voolavad?
  • Kuidas sobib teie funktsioon rakendusse?

Kui saate suure pildi aru, on lihtsam välja mõelda, kuidas seda probleemi kõige paremini lahendada. Võib-olla peate looma uue faili ja looma uue kontrolleri. Võib-olla peate kirjutama utiliidi funktsiooni ja seda testima. Olenemata olukorrast on teie probleemi laiema konteksti mõistmine hea esimene samm lahenduse loomisel.

Katsetage rakendust käsitsi ja võimaluse korral ühiskatsetega

Rakenduse ajutine rikkumine uue funktsiooni lisamise ajal on paratamatus, olenemata sellest, milline arendaja tase olete. See on normaalne ja eeldatav, eriti kui olete selle tööga uus inimene, töötate pärandkoodide baasis koos harjumatu virnaga või nende kahe kombinatsiooniga.

Parim viis nende purunemiste pikaajalisteks probleemideks vältimiseks on oma rakenduse põhjalik testimine nii üksusetestide kui ka käsitsi tehtavate testidega. Nende testide olemasolu ja täpselt teadmine, millise katvuse te neist välja saate, säästab teie ja tulevasi arendajaid palju aega. Samuti muudavad ranged testid rakenduse mastabeeritavamaks ja annavad teile ka iga kord, kui testid puhtad, pisut dopamiini kiirustada. Kahjuks on minu stsenaariumi korral piiratud ühiku testimise juhtumeid

Manuaalsete testide jaoks peate välja töötama testmaatriksi ja veenduma, et dokument on tulevastele arendajatele juurdepääsetav. Maatriksi jaoks soovite määratleda toimingute komplekti, eeldatava käitumise, tegeliku käitumise selle testimisel ja muud olulised üksikasjad, näiteks:

Küsi abi

Eeldusel, et teie projekti kirjutas teie töökoha praegune või endine töötaja, teab ilmselt keegi teine, mis rakenduses toimub, või vähemalt teab piisavalt, et teid lahti lasta. Õppimine oma uhkust alla neelama ja kelleltki teist küsima on mõne jaoks ebamugav samm, kuid arendajaks kasvamiseks vajalik ja võib-olla saab teie töökaaslane teile õpetada paar uut trikki.

Hea viis oma aja (ja nende) efektiivseks kasutamiseks on teadlike küsimuste sõnastamine. Proovige vaadata tagasi kogu andmebaasi ja selgitada välja lüngad teie arusaamises. See mitte ainult ei aita neil paremini mõista, mis teie probleem on, vaid näitab ka seda, et te võtsite initsiatiivi, et proovite kõigepealt probleemi ise lahendada.

Tea, millal oma kaotusi vähendada

Kui kulutate liiga palju aega oma jala ukse taha saamisele ega ole pärast ülaltoodud toimingute proovimist funktsiooni rakendamisel tõsiseid samme astunud, tasub ehk funktsiooni ümber kood ümber kujundada. Ärge loobuge liiga lihtsalt, vaid pidage ka meeles, millised on teie tähtajad ja mida teie projektijuht sinult ootab.

Sellegipoolest on sellel viisil jätkamisel puudusi:

  • Koodi ümberkirjutamine võib vigu tutvustada, ehkki hea ühiku testimisega saab sellest mõnevõrra mööda minna.
  • Koodi ümberkirjutamine võib peidetud funktsionaalsuse eemaldada, ehkki seda saab ka korralike ühikatestidega vältida.
  • Kui teil on aega vaja, võib koodi lisaks funktsioonile funktsiooni välja kirjutamine olla aeganõudvam kui lihtsalt selle ümber ehitamine.

Kokkuvõttes kasutage oma parimat otsustusvõimet. Mõlemal valikul on plusse ja miinuseid ning see kõik sõltub teie asjaoludest ja projekti eelarvest.

Kuidas toimida pärandkoodiga psühholoogilisel tasandil

Nüüd, kui oleme pärandkoodiga tegelemise tehnilised aspektid katnud, räägime sellest, kuidas sellega hakkama saada, kasutades oma pehmeid oskusi. Lõppude lõpuks on arendajad inimesed, mitte ainult robotite kodeerimine, ja loovust ja autorlust nõudvate projektide väljakutsetega seotud probleemide lahendamine võib emotsionaalselt maksustada mitte ainult teile, vaid ka teie töökaaslastele.

Ole alandlik ja lahke

See on asi, mida tunnistan karmilt - pean rohkem harjutama. Kui mulle esimest korda määrati filtermodaaliprojekt, olin ma üsna häälekas selle suhtes, kui jama ja ebameeldiv kood pidi hakkama saama, samal ajal kui koodi algne autor istus minust 15 jala kaugusel. Ma tahtsin, et minu kommentaarid oleksid nali, kuid tagantjärele mõistan, et olin ülbe ja valus ning oleksin pidanud olema empaatilisem.

On palju tegureid, mis võivad viia pärandkoodi väljalülitamiseni, mida peaksite arvestama enne, kui hakkate autorit kritiseerima või oletate nende kohta halvimat (see on lõdvalt seotud põhimõttelise omistamisveaga!).

Algsel autoril võisid olla põhjused koodi kirjutamiseks nii, nagu nad tegid.

Ajalised ja tehnoloogilised piirangud võivad panna inimese kirjutama koodi, mis töötab, kuid millel pole tingimata parimat tava. Kui pildistate end olukorras, kus pole piisavalt aega, vananenud tööriistu ja ülesandeloendit miil pikk, ei kirjutaks te tõenäoliselt ka parimat koodi!

Konventsioonid muutuvad.

Vanemates projektides kasutab koodi tava stringide deklareerimiseks üksikuid jutumärke ja kaks tühikut võrdsesid ühe vahekaardiga. Meil oli mitu faili sisse pestud mitu väikest klassi. Meie praeguses kokkuleppes kasutame kahekordseid jutumärke ja nelja tühikut ning iga klass, olenemata sellest, kui väike, elab oma mudelite kataloogis .cs-faili. Ja mitme aasta pärast olen kindel, et ka see muutub.

Kogu kood muutub lõpuks pärandiks

See seostub eelmise punktiga: teie kood on lõpuks pärand. Vanemuse redelil üles liikudes võetakse tööle uued arendajad ja nad peavad teie vana koodi säilitama. Võite kirjutada puhta, veatu DRY-koodi, kuid kui tavapärased muudatused või trendid muutuvad, võivad need uued arendajad teie koodi vaadata samamoodi nagu teiste pärandkoodi.

Olge uhked väikeste õnnestumiste üle

Väljaspool tavapäraseid tavasid pole lihtne töötada; pärandkoodiga tegelemise põhjus on tohutu meemide ja naljade hulk. Kui olete kunagi õppinud keelt väljaspool oma emakeelt, teate, mis tunne on unustada mõni sõna või sõna teises keeles, kuid pidage seda meeles oma emakeeles ja ärge tõlkige tühimikku. Sama kehtib ka tänapäevaste ja pärandkonventsioonide vahel vahetamise kohta. Mõnikord kulub laagrite taastamiseks vaid minut.

Pärandkoodis edukalt navigeerimisel näitate oma kohanemisvõimet, mis on oluline oskus, millest on kasu nii praegusel töökohal kui ka kõigil tulevastel töökohtadel, sõltumata sellest, kas need töökohad on tehnoloogiavaldkonnas või mitte. Pärandkood on ideaalne oskus selle oskuse harjutamiseks.

Kokkuvõtteks

Kasutage seda aega oma koodi kirjutamise toetamiseks

Nüüd, kui teil on olnud pärandkoodbaasis töötamise kogemus, peaksite sellest eemalduma, kui peaksite paremini mõistma, mis teile tööriistade ja konventsioonide osas meeldib ja mis ei meeldi. Need on asjad, mida saate edasistes projektides jätkata ja mis muudavad teid teiste koodide paremaks läbivaatamiseks, konstruktiivse kriitika pakkumiseks ja juhendamiseks.

Arendage rakendusi kasutaja ja tulevase arendaja jaoks

Olenemata sellest, kas teil on olnud suurte dokumentide ja koodikommentaaride olemasolu või puuduvad dokumendid või koodikommentaarid, näete, kuidas nii dokumentatsioon kui ka kommentaarid on võimsad tööriistad, mis aitavad tulevastel arendajatel projektis liikuda. Teil on ühine eesmärk soovida sujuvat, funktsionaalset ja kuiva rakendust. dokumentatsiooni säilitamine ja informatiivsete koodikommentaaride maha jätmine on hea viis selle lünga ületamiseks.

Pidage meeles, et kunagi on ka teie kood pärand

Olen seda juba paar korda maininud, kuid on oluline korrata, et ka teie kood on pärand, hoolimata sellest, kui kuiv ja puhas on teie kood ja loogika.

Kõige olulisem kaasavõtmine on olla paindlik, tagasihoidlik ja kindlasti õppida vanast koodist uusi trikke.