Sedert die begin van 2018 beklee ek die posisie van hoof/baas/hoofontwikkelaar in die span - noem dit wat jy wil, maar die punt is dat ek geheel en al verantwoordelik is vir een van die modules en vir al die ontwikkelaars wat werk. daarop. Hierdie posisie gee my 'n nuwe perspektief op die ontwikkelingsproses, aangesien ek by meer projekte betrokke is en meer aktief by besluitneming betrokke is. Onlangs, danksy hierdie twee dinge, het ek skielik besef hoeveel die mate van begrip die kode en die toepassing beïnvloed.
Die punt wat ek wil maak is dat die kwaliteit van die kode (en die finale produk) nou verwant is aan hoe bewus die mense wat die kode ontwerp en skryf is van wat hulle doen.
Jy dink dalk nou, "Dankie, Cap. Dit sal natuurlik lekker wees om te verstaan wat jy in die algemeen skryf. Andersins kan jy net sowel ’n groep ape huur om arbitrêre sleutels te slaan en dit daar te laat.” En jy is heeltemal reg. Gevolglik aanvaar ek dit as vanselfsprekend dat u besef dat dit nodig is om 'n algemene idee te hê van wat u doen. Dit kan die nulvlak van begrip genoem word, en ons sal dit nie in detail ontleed nie. Ons sal in detail kyk wat presies jy moet verstaan en hoe dit die besluite wat jy elke dag neem, beïnvloed. As ek hierdie dinge vooraf geweet het, sou dit my baie vermorsde tyd en twyfelagtige kode gespaar het.
Alhoewel jy nie 'n enkele reël kode hieronder sal sien nie, glo ek steeds dat alles wat hier gesê word van groot belang is vir die skryf van hoë gehalte, ekspressiewe kode.
Eerste vlak van begrip: Hoekom werk dit nie?
Ontwikkelaars bereik gewoonlik hierdie vlak baie vroeg in hul loopbane, soms selfs sonder enige hulp van ander – ten minste volgens my ervaring. Stel jou voor dat jy 'n foutverslag ontvang het: een of ander funksie in die toepassing werk nie, dit moet reggemaak word. Hoe sal jy voortgaan?
Die standaardskema lyk soos volg:
- Vind die stukkie kode wat die probleem veroorsaak (hoe om dit te doen is 'n aparte onderwerp, ek dek dit in my boek oor nalatenskapkode)
- Maak veranderinge aan hierdie brokkie
- Maak seker dat die fout reggestel is en geen regressiefoute voorgekom het nie
Kom ons fokus nou op die tweede punt - die maak van veranderinge aan die kode. Daar is twee benaderings tot hierdie proses. Die eerste is om te delf in wat presies in die huidige kode gebeur, die fout te identifiseer en dit reg te stel. Tweedens: beweeg volgens voel - voeg, sê, +1 by 'n voorwaardelike stelling of lus, kyk of die funksie in die verlangde scenario werk, probeer dan iets anders, ensovoorts ad infinitum.
Die eerste benadering is korrek. Soos Steve McConnell verduidelik in sy boek Code Complete (wat ek terloops sterk aanbeveel), elke keer as ons iets in die kode verander, behoort ons met selfvertroue te kan voorspel hoe dit die toepassing sal beïnvloed. Ek haal uit die geheue aan, maar as 'n foutoplossing nie werk soos jy verwag het nie, behoort jy baie bekommerd te wees en jy moet jou hele aksieplan bevraagteken.
Om op te som wat gesê is, om 'n goeie foutoplossing uit te voer wat nie die kwaliteit van die kode afbreek nie, moet jy beide die hele struktuur van die kode en die bron van die spesifieke probleem verstaan.
Tweede vlak van begrip: Hoekom werk dit?
Hierdie vlak word baie minder intuïtief as die vorige een verstaan. Ek, terwyl ek nog 'n beginner ontwikkelaar was, het dit te danke aan my baas geleer, en daarna herhaaldelik die essensie van die saak aan nuwelinge verduidelik.
Kom ons stel ons hierdie keer voor dat jy twee foutverslae tegelyk ontvang het: die eerste handel oor scenario A, die tweede oor scenario B. In albei scenario's gebeur iets verkeerd. Gevolglik pak jy die eerste fout eerste aan. Deur die beginsels wat ons ontwikkel het vir Vlak XNUMX-begrip te gebruik, delf jy diep in die kode wat relevant is tot die probleem, vind uit hoekom dit veroorsaak dat die toepassing optree soos dit in Scenario A doen, en maak redelike aanpassings wat die resultaat lewer wat jy wil hê. . Alles gaan uitstekend.
Dan gaan jy aan na scenario B. Jy herhaal die scenario in 'n poging om 'n fout uit te lok, maar—verrassing! — nou werk alles soos dit moet. Om jou raaiskoot te bevestig, ontdoen jy die veranderinge wat jy gemaak het terwyl jy aan fout A gewerk het, en fout B kom terug. Jou foutoplossing het albei probleme opgelos. Gelukkig!
Jy het glad nie hierop gereken nie. Jy het met 'n manier vorendag gekom om die fout in scenario A reg te stel en het geen idee hoekom dit vir scenario B gewerk het nie. Op hierdie stadium is dit baie aanloklik om te dink dat beide take suksesvol afgehandel is. Dit is redelik logies: die punt was om foute uit te skakel, was dit nie? Maar die werk is nog nie klaar nie: jy moet nog uitvind hoekom jou optrede die fout in scenario B reggestel het. Hoekom? Omdat dit dalk op die verkeerde beginsels werk, en dan sal jy na 'n ander uitweg moet soek. Hier is 'n paar voorbeelde van sulke gevalle:
- Aangesien die oplossing nie aangepas is vir fout B nie, met inagneming van alle faktore, het jy dalk onwetend funksie C gebreek.
- Dit is moontlik dat daar ook 'n derde fout iewers skuil, wat verband hou met dieselfde funksie, en jou foutoplossing hang daarvan af vir die korrekte werking van die stelsel in scenario B. Alles lyk nou goed, maar eendag sal hierdie derde fout opgemerk en reggemaak word. Dan in scenario B sal die fout weer voorkom, en dit is goed as dit net daar is.
Dit alles voeg chaos by die kode en sal eendag op jou kop val - heel waarskynlik op die mees ongeleë oomblik. Jy sal jou wilskrag moet bymekaarmaak om jouself te dwing om tyd te spandeer om te verstaan hoekom alles lyk of dit werk, maar dit is die moeite werd.
Derde vlak van begrip: Hoekom werk dit?
My onlangse insig hou juis verband met hierdie vlak, en dit is waarskynlik die een wat my die meeste voordeel sou gegee het as ek vroeër tot hierdie idee gekom het.
Om dit duideliker te maak, kom ons kyk na 'n voorbeeld: jou module moet versoenbaar gemaak word met funksie X. Jy is nie besonder bekend met funksie X nie, maar daar is vir jou gesê dat jy die F-raamwerk moet gebruik om daarmee versoenbaar te wees. modules wat met X integreer werk presies met hom.
Jou kode was glad nie in kontak met die F-raamwerk sedert die eerste dag van sy lewe nie, so die implementering daarvan sal nie so maklik wees nie. Dit sal ernstige gevolge vir sommige dele van die module hê. Jy werp jouself egter in ontwikkeling: jy spandeer weke om kode te skryf, te toets, loodsweergawes uit te rol, terugvoer te kry, regressiefoute reg te stel, onvoorsiene komplikasies te ontdek, nie die oorspronklik ooreengekome spertye na te kom nie, nog 'n kode te skryf, te toets, terugvoerkommunikasie te kry, om regressiefoute reg te stel - dit alles om die F-raamwerk te implementeer.
En op 'n stadium besef jy skielik - of hoor dalk van iemand - dat raamwerk F dalk glad nie vir jou versoenbaarheid met kenmerk X sal gee nie. Miskien is al daardie tyd en moeite heeltemal verkeerd daaraan gesit.
Iets soortgelyks het een keer gebeur terwyl ek aan 'n projek gewerk het waarvoor ek verantwoordelik was. Hoekom het dit gebeur? Omdat ek min begrip gehad het van wat funksie X is en hoe dit met raamwerk F verband hou. Wat moes ek gedoen het? Vra die persoon wat die ontwikkelingstaak opdra om duidelik te verduidelik hoe die beoogde aksie tot die gewenste uitkoms lei, eerder as om bloot te herhaal wat vir ander modules gedoen is of hulle woord daarvoor te aanvaar dat dit is wat kenmerk X moet doen.
Die ervaring van hierdie projek het my geleer om te weier om met die ontwikkelingsproses te begin totdat ons 'n duidelike begrip het van hoekom ons gevra word om sekere dinge te doen. Weier volstrek. Wanneer jy 'n taak ontvang, is die eerste impuls om dit dadelik aan te pak om nie tyd te mors nie. Maar die "vries die projek totdat ons in al die besonderhede kom"-beleid kan vermorsde tyd met ordes van grootte verminder.
Selfs al probeer hulle druk op jou plaas, om jou te dwing om te begin werk, alhoewel jy nie die rasionaal hiervoor verstaan nie, weerstaan. Vind eers uit hoekom jy so 'n taak kry, en besluit of dit die regte pad na die doel is. Ek moes dit alles op die harde manier leer – ek hoop my voorbeeld sal die lewe makliker maak vir diegene wat dit lees.
Vierde vlak van begrip: ???
Daar is altyd meer om te leer in programmering, en ek glo ek het net die oppervlak van die onderwerp van begrip gekrap. Watter ander vlakke van begrip het jy ontdek oor die jare van werk met kode? Watter besluite het jy geneem wat 'n positiewe impak op die kwaliteit van die kode en toepassing gehad het? Watter besluite het verkeerd geblyk te wees en het jou 'n waardevolle les geleer? Deel jou ervaring in die kommentaar.
Bron: will.com