Ekde la komenco de 2018, mi okupas la pozicion de ĉefo/estro/ĉefa programisto en la teamo - nomu ĝin kiel vi volas, sed la afero estas, ke mi estas tute respondeca pri unu el la moduloj kaj pri ĉiuj programistoj, kiuj laboras. sur ĝi. Ĉi tiu pozicio donas al mi novan perspektivon pri la evoluprocezo, ĉar mi estas implikita en pli da projektoj kaj pli aktive engaĝita en decidado. Lastatempe, dank' al ĉi tiuj du cirkonstancoj, mi subite konstatis, kiom multe la mezuro de kompreno influas la kodon kaj la aplikaĵon.
La punkto, kiun mi volas rimarki, estas, ke la kvalito de la kodo (kaj la fina produkto) estas proksime rilata al kiom konsciaj la homoj, kiuj desegnas kaj skribas la kodon, estas pri tio, kion ili faras.
Vi eble pensas nun, “Dankon, Ĉapo. Kompreneble, estus bone kompreni kion vi skribas ĝenerale. Alie, vi ankaŭ povus dungi grupon de simioj por bati arbitrajn klavojn kaj lasi ĝin ĉe tio." Kaj vi tute pravas. Sekve, mi konsideras, ke vi rimarkas, ke necesas havi ĝeneralan ideon pri tio, kion vi faras. Ĉi tio povas esti nomita la nula nivelo de kompreno, kaj ni ne analizos ĝin detale. Ni rigardos detale kion vi bezonas kompreni kaj kiel ĝi influas la decidojn, kiujn vi faras ĉiutage. Se mi scius ĉi tiujn aferojn anticipe, ĝi ŝparus al mi multe da malŝparita tempo kaj dubinda kodo.
Kvankam vi ne vidos eĉ unu linion de kodo malsupre, mi ankoraŭ kredas, ke ĉio ĉi tie dirita estas tre grava por verki altkvalitan, esprimplenan kodon.
Unua nivelo de kompreno: Kial ĝi ne funkcias?
Programistoj kutime atingas ĉi tiun nivelon tre frue en sia kariero, foje eĉ sen helpo de aliaj - almenaŭ laŭ mia sperto. Imagu, ke vi ricevis cimraporton: iu funkcio en la aplikaĵo ne funkcias, ĝi devas esti riparita. Kiel vi procedos?
La norma skemo aspektas jene:
- Trovu la kodon, kiu kaŭzas la problemon (kiel fari tion estas aparta temo, mi kovras ĝin en mia libro pri hereda kodo)
- Faru ŝanĝojn al ĉi tiu fragmento
- Certiĝu, ke la cimo estas riparita kaj ke neniu regreseraro okazis
Nun ni koncentriĝu pri la dua punkto - fari ŝanĝojn al la kodo. Estas du aliroj al ĉi tiu procezo. La unua estas enprofundiĝi en kio ĝuste okazas en la nuna kodo, identigi la eraron kaj ripari ĝin. Due: movu per sento - aldonu, diru, +1 al kondiĉa deklaro aŭ buklo, vidu ĉu la funkcio funkcias en la dezirata scenaro, tiam provu ion alian, kaj tiel plu ĝis infinito.
La unua aliro estas ĝusta. Kiel Steve McConnell klarigas en sia libro Code Complete (kiun mi tre rekomendas, cetere), ĉiufoje kiam ni ŝanĝas ion en la kodo, ni devus povi antaŭdiri kun fido kiel ĝi influos la aplikaĵon. Mi citas el memoro, sed se eraro ne funkcias kiel vi atendis, vi devus esti tre alarmita kaj vi devus pridubi vian tutan agadplanon.
Por resumi tion, kio estis dirita, por plenumi bonan eraron, kiu ne malbonigas la kvaliton de la kodo, vi devas kompreni kaj la tutan strukturon de la kodo kaj la fonton de la specifa problemo.
Dua nivelo de kompreno: Kial ĝi funkcias?
Ĉi tiu nivelo estas komprenata multe malpli intuicie ol la antaŭa. Mi, estante ankoraŭ komencanta programisto, lernis ĝin danke al mia estro, kaj poste plurfoje klarigis la esencon de la afero al novuloj.
Ĉi-foje, ni imagu, ke vi ricevis du cimraportojn samtempe: la unua temas pri scenaro A, la dua temas pri scenaro B. En ambaŭ scenaroj okazas io malĝusta. Sekve, vi unue traktas la unuan cimon. Uzante la principojn, kiujn ni evoluigis por la kompreno de la Nivelo XNUMX, vi profunde enfosas la kodon rilatan al la problemo, eltrovu kial ĝi igas la aplikaĵon konduti kiel ĝi faras en Scenaro A, kaj faras akcepteblajn ĝustigojn kiuj produktas la rezulton, kiun vi volas. . Ĉio iras bonege.
Poste vi transiras al scenaro B. Vi ripetas la scenaron por provoki eraron, sed—surprizo! — nun ĉio funkcias kiel ĝi devus. Por konfirmi vian divenon, vi malfaras la ŝanĝojn, kiujn vi faris laborante pri cimo A, kaj cimo B revenas. Via eraro solvis ambaŭ problemojn. Bonŝance!
Vi tute ne kalkulis pri tio. Vi elpensis manieron ripari la eraron en scenaro A kaj ne havas ideon kial ĝi funkciis por scenaro B. En ĉi tiu etapo, estas tre tenta pensi, ke ambaŭ taskoj estis sukcese plenumitaj. Ĉi tio estas sufiĉe logika: la afero estis forigi erarojn, ĉu ne? Sed la laboro ankoraŭ ne estas finita: vi ankoraŭ devas eltrovi kial viaj agoj korektis la eraron en scenaro B. Kial? Ĉar ĝi eble funkcias laŭ malĝustaj principoj, kaj tiam vi devos serĉi alian elirejon. Jen kelkaj ekzemploj de tiaj kazoj:
- Ĉar la solvo ne estis adaptita al eraro B, konsiderante ĉiujn faktorojn, vi eble senkonscie rompis funkcion C.
- Eblas, ke ie kaŝas ankaŭ tria cimo, rilata al la sama funkcio, kaj via eraro dependas de ĝi por la ĝusta funkciado de la sistemo en la scenaro B. Ĉio aspektas bone nun, sed iam ĉi tiu tria cimo estos rimarkita kaj riparita. Tiam en scenaro B la eraro denove okazos, kaj estas bone, se nur tie.
Ĉio ĉi aldonas kaoson al la kodo kaj iam falos sur vian kapon - plej verŝajne en la plej maloportuna momento. Vi devos kunvenigi vian volforton por devigi vin pasigi tempon por kompreni kial ĉio ŝajnas funkcii, sed ĝi valoras ĝin.
Tria nivelo de kompreno: Kial ĝi funkcias?
Mia lastatempa kompreno rilatas ĝuste al ĉi tiu nivelo, kaj verŝajne ĝi estas tiu, kiu plej profitus al mi, se mi estus veninta al ĉi tiu ideo pli frue.
Por pliklarigi ĝin, ni rigardu ekzemplon: via modulo devas esti kongrua kun funkcio X. Vi ne aparte konas funkcion X, sed oni diris al vi, ke por kongrui kun ĝi necesas uzi la kadron F. Aliaj moduloj kiuj integriĝas kun X funkcias ĝuste kun li.
Via kodo tute ne estis en kontakto kun la F-kadro ekde la unua tago de sia vivo, do efektivigi ĝin ne estos tiel facila. Ĉi tio havos gravajn konsekvencojn por iuj partoj de la modulo. Tamen, vi ĵetas vin en evoluon: vi pasigas semajnojn skribante kodon, testante, disvolvante pilotversiojn, ricevante reagojn, ripari regresajn erarojn, malkovrante neantaŭvideblajn komplikaĵojn, ne plenumante la origine interkonsentitajn limdatojn, verkante iom pli da kodon, testante, ricevante retro-komunikadon, korektante regreserarojn - ĉio ĉi por efektivigi la F-kadron.
Kaj iam vi subite rimarkas - aŭ eble aŭdas de iu - ke eble kadro F tute ne donos al vi kongruecon kun trajto X. Eble la tuta tempo kaj penado estis enmetitaj tute malĝuste al tio.
Io simila okazis unufoje laborante pri projekto pri kiu mi respondecis. Kial ĉi tio okazis? Ĉar mi malmulte komprenis, kia funkcio X estas kaj kiel ĝi rilatas al kadro F. Kion mi devus fari? Petu al la persono, kiu atribuas la disvolvan taskon, klare klarigi kiel la celita agado kondukas al la dezirata rezulto, prefere ol simple ripeti tion, kio estis farita por aliaj moduloj aŭ preni sian vorton, ke tio estas tio, kion la trajto X devas fari.
La sperto de ĉi tiu projekto instruis min rifuzi komenci la disvolvan procezon ĝis ni havos klaran komprenon pri kial oni petas nin fari iujn aferojn. Rifuzu rekte. Kiam oni ricevas taskon, la unua impulso estas tuj preni ĝin por ne perdi tempon. Sed la politiko "frostigi la projekton ĝis ni eniros ĉiujn detalojn" povas redukti malŝparitan tempon laŭ grandordoj.
Eĉ se ili provas premi vin, devigi vin komenci laboron, kvankam vi ne komprenas la kialon de tio, rezistu. Unue, eltrovu kial vi ricevas tian taskon, kaj decidu ĉu ĉi tio estas la ĝusta vojo al la celo. Mi devis lerni ĉion ĉi malfacile – mi esperas, ke mia ekzemplo faciligos la vivon al tiuj, kiuj legas ĉi tion.
Kvara nivelo de kompreno: ???
Ĉiam estas pli por lerni en programado, kaj mi kredas, ke mi nur skrapis la surfacon de la temo de kompreno. Kiajn aliajn nivelojn de kompreno vi malkovris dum la jaroj de laboro kun kodo? Kiajn decidojn vi faris, kiuj pozitive influis la kvaliton de la kodo kaj aplikaĵo? Kiuj decidoj montriĝis malĝustaj kaj instruis al vi valoran lecionon? Kunhavigu vian sperton en la komentoj.
fonto: www.habr.com