2018. urtearen hasieratik, taldean garatzaile nagusiaren/buruaren/buruaren kargua hartzen dut - nahi duzun bezala deitu, baina kontua da moduluetako baten eta lan egiten duten garatzaile guztien ardura osoa naizela. gainean. Posizio honek garapen prozesuaren ikuspegi berri bat ematen dit, proiektu gehiagotan parte hartzen dudalako eta erabakiak hartzen aktiboago nagoelako. Duela gutxi, bi gauza horiei esker, bat-batean konturatu naiz ulermen neurriak zenbateraino eragiten duen kodean eta aplikazioan.
Azaldu nahi dudan puntua da kodearen (eta azken produktuaren) kalitatea oso lotuta dagoela kodea diseinatzen eta idazten ari diren pertsonak egiten ari direnaren jakitunarekin.
Oraintxe bertan pentsatzen ari zara agian: "Eskerrik asko, Cap. Noski, ondo legoke idazten ari zarena orokorrean ulertzea. Bestela, tximino talde bat kontratatuko zenuke tekla arbitrarioak sakatu eta horretan uztea". Eta arrazoi osoa duzu. Horren arabera, egiten ari zarenaren ideia orokorra izatea beharrezkoa dela konturatzen zarela uste dut. Horri ulermen-maila zero dei daiteke, eta ez dugu zehatz-mehatz aztertuko. Zehazki zer ulertu behar duzun eta egunero hartzen dituzun erabakietan nola eragiten duen aztertuko dugu. Gauza hauek aldez aurretik jakin izan banu, galdutako denbora eta kode zalantzagarri asko aurreztuko nizkizuke.
Behean kode-lerro bakar bat ere ikusiko ez duzun arren, uste dut hemen esandako guztiak garrantzi handia duela kalitate handiko kode adierazgarria idazteko.
Lehenengo ulermen maila: Zergatik ez du funtzionatzen?
Garatzaileak normalean maila horretara iristen dira beren karreran oso goiz, batzuetan besteen laguntzarik gabe ere, nire esperientziaren arabera behintzat. Imajinatu akatsen txosten bat jaso duzula: aplikazioko funtzio batzuk ez dute funtzionatzen, konpondu egin behar da. Nola egingo duzu aurrera?
Eskema estandarrak honelakoa da:
- Aurkitu arazoa eragiten duen kode zatia (hau nola egin gai bereizia da, nire liburuan estaltzen dut ondare-kodeari buruz)
- Egin aldaketak zati honetan
- Ziurtatu akatsa konponduta dagoela eta ez dela erregresio akatsik gertatu
Orain bigarren puntuan zentratu gaitezen: kodean aldaketak egitea. Prozesu honetarako bi ikuspegi daude. Lehenengoa uneko kodean zehazki zer gertatzen den sakontzea da, errorea identifikatu eta konpondu. Bigarrena: mugitu sentimenduaren arabera - gehitu, esan, +1 baldintzazko adierazpen edo begizta bati, ikusi funtzioak nahi duzun eszenatokian funtzionatzen duen, gero beste zerbait probatu, eta abar infinituan.
Lehenengo hurbilketa zuzena da. Steve McConnell-ek bere Code Complete liburuan azaltzen duenez (oso gomendatzen dut, bide batez), kodean zerbait aldatzen dugun bakoitzean, konfiantzaz aurreikusteko gai izan beharko genuke aplikazioan nola eragingo duen. Memoriatik aipatzen ari naiz, baina akatsen konponketa batek espero zenuen moduan funtzionatzen ez badu, oso larrituta egon beharko zenuke eta zure ekintza-plan osoa zalantzan jarri beharko zenuke.
Esandakoa laburbiltzeko, kodearen kalitatea hondatzen ez duen akatsen konponketa ona egiteko, kodearen egitura osoa eta arazo zehatzaren iturria ulertu behar dituzu.
Bigarren ulermen maila: Zergatik funtzionatzen du?
Maila hau aurrekoa baino askoz gutxiago intuitiboki ulertzen da. Ni, garatzaile hasiberria nintzela, nire buruzagiari esker ikasi nuen, eta, ondoren, behin eta berriz azaldu nien gaiaren funtsa etorri berriei.
Oraingoan, pentsa dezagun bi akatsen txosten aldi berean jaso dituzula: lehenengoa A eszenatokiari buruzkoa da, bigarrena B agertokiari buruzkoa. Bi eszenatokietan, zerbait gaizki gertatzen da. Horren arabera, lehen akatsari aurre egiten diozu. XNUMX. maila ulertzeko garatu ditugun printzipioak erabiliz, arazoari dagokion kodean sakontzen duzu, asmatzen duzu zergatik eragiten duen aplikazioak A eszenatokian jokatzen duen moduan eta nahi duzun emaitza lortzen duten egokitzapen egokiak egiten dituzu. . Dena bikain doa.
Ondoren, B eszenatokira igarotzen zara. Eszenatokia errepikatzen duzu akats bat eragin nahian, baina... harridura! - Orain dena behar bezala funtzionatzen du. Zure asmakizuna berresteko, A akatsean lan egiten duzun bitartean egin dituzun aldaketak desegin eta B akatsa itzuliko da. Zure akatsen konponketak bi arazoak konpondu ditu. Zortea!
Ez zenuen inondik inora honekin kontatzen. A agertokiko errorea konpontzeko modu bat asmatu duzu eta ez dakizu zergatik funtzionatu duen B eszenatokian. Etapa honetan, oso tentagarria da bi zereginak arrakastaz burutu direla pentsatzea. Hau nahiko logikoa da: kontua akatsak ezabatzea zen, ezta? Baina lana oraindik ez da amaitu: oraindik asmatu behar duzu zure ekintzek zergatik zuzendu duten B eszenatokiko errorea. Zergatik? Printzipio okerretan lan egiten ari delako, eta orduan beste bide bat bilatu beharko duzu. Hona hemen horrelako kasuen adibide pare bat:
- Soluzioa B errorera egokitu ez denez, faktore guztiak kontuan hartuta, baliteke C funtzioa jakin gabe hautsi izana.
- Baliteke hirugarren akats bat ere nonbait ezkutuan egotea, funtzio berarekin lotuta, eta zure akatsen konponketa horren araberakoa izango da sistemaren funtzionamendu zuzena B eszenatokian. Orain dena ondo ikusten da, baina egunen batean hirugarren akats hau nabarituko da eta konponduko da. Ondoren, B eszenatokian errorea berriro gertatuko da, eta ona da hor egonez gero.
Horrek guztiak kaosa gehitzen dio kodeari eta noizbait buruan eroriko zaizu, seguruenik unerik desegokienean. Zure borondatea bildu beharko duzu dena zergatik funtzionatzen duen ulertzen denbora pasatzera behartzeko, baina merezi du.
Hirugarren ulermen maila: Zergatik funtzionatzen du?
Nire azken ikuspegia maila honi dagokio hain zuzen, eta ziurrenik ideia hori lehenago heldu izan banu onura gehien emango lidakeena da.
Argiago gera dadin, ikus dezagun adibide bat: zure modulua X funtzioarekin bateragarri egin behar da. Ez duzu X funtzioa bereziki ezagutzen, baina harekin bateragarria izateko F markoa erabili behar duzula esan dizute. X-rekin integratzen diren moduluek berarekin lan egiten dute zehazki.
Zure kodea ez da F markoarekin batere harremanetan egon bere bizitzako lehen egunetik, beraz, ez da hain erraza izango inplementatzea. Horrek ondorio larriak izango ditu moduluaren zati batzuetan. Hala ere, garapenera sartzen zara: asteak ematen dituzu kodea idazten, probatzen, bertsio pilotuak zabaltzen, iritziak jasotzen, erregresio-akatsak konpontzen, ustekabeko konplikazioak deskubritzen, hasieran adostutako epeak ez betetzen, kode gehiago idazten, probatzen, iritzien komunikazioa jasotzen, erregresio akatsak zuzentzea - hori guztia F markoa ezartzeko.
Eta noizbait konturatzen zara bat-batean - edo agian norbaitengandik entzun - agian F markoak ez dizula batere bateragarritasunik emango X ezaugarriarekin. Agian denbora eta ahalegin guztia guztiz gaizki jarri zen horretan.
Antzeko zerbait gertatu zen behin nire arduraduna nintzen proiektu batean lanean ari nintzenean. Zergatik gertatu da hau? X funtzioa zer zen eta F markoarekin zer erlazio zuen gutxi ulertzen nuelako. Zer egin behar nuen? Eskatu garapen-ataza esleitzen dion pertsonari argi eta garbi azal dezala aurreikusitako ekintzak nola ekartzen duen nahi den emaitza, beste modulu batzuetarako egindakoa errepikatzea edo X ezaugarriak hori dela egin behar duen hitza hartu beharrean.
Proiektu honen esperientziak irakatsi zidan uko egiten garapen prozesuari hasiera emateari, gauza jakin batzuk zergatik eskatzen zaizkigun argi ulertu arte. Uko egin. Zeregin bat jasotzen duzunean, lehen bulkada berehala hartzea da, denborarik ez galtzeko. Baina "proiektua izoztu xehetasun guztietan sartu arte" politikak alferrik galtzen den denbora gutxitu dezake.
Nahiz eta presioa egiten saiatu, lanean hastera behartzen, horren arrazoia ulertzen ez duzun arren, eutsi. Lehenik eta behin, asmatu zergatik ematen dizun zeregin hori, eta erabaki hori helbururako bide egokia den. Hau guztia modu gogorrean ikasi behar izan nuen - espero dut nire adibideak hau irakurtzen dutenei bizitza erraztuko diela.
Laugarren ulermen maila: ???
Beti dago gehiago ikasteko programazioan, eta uste dut ulermenaren gaiaren azalera besterik ez dudala urratu. Zein beste ulermen-maila aurkitu dituzu kodearekin lan egiten urteetan zehar? Kodearen eta aplikazioaren kalitatean eragin positiboa izan duten erabakiak hartu dituzu? Zein erabaki okerrak izan dira eta ikasgai baliotsu bat eman dizute? Partekatu zure esperientzia iruzkinetan.
Iturria: www.habr.com