Sûnt it begjin fan 2018 haw ik de posysje fan lead/baas/leadûntwikkelder yn it team - neam it wat jo wolle, mar it punt is dat ik folslein ferantwurdlik bin foar ien fan 'e modules en foar alle ûntwikkelders dy't wurkje derop. Dizze posysje jout my in nij perspektyf op it ûntwikkelingsproses, om't ik belutsen bin by mear projekten en mear aktyf belutsen by beslútfoarming. Koartlyn, troch dizze twa dingen, realisearre ik my ynienen hoefolle de mjitte fan begryp beynfloedet de koade en de applikaasje.
It punt dat ik meitsje wol is dat de kwaliteit fan 'e koade (en it einprodukt) nau besibbe is oan hoe bewust de minsken dy't de koade ûntwerpe en skriuwe binne fan wat se dogge.
Jo tinke miskien no, "Tankewol, Cap. Fansels soe it moai wêze om te begripen wat jo yn it algemien skriuwe. Oars kinne jo likegoed in groep apen hiere om willekeurige toetsen te slaan en it dêrby te litten." En do hast gelyk. Dêrom nim ik it foar fanselssprekkend dat jo beseffe dat it nedich is om in algemien idee te hawwen fan wat jo dogge. Dit kin neamd wurde it nul nivo fan begryp, en wy sille net analysearje it yn detail. Wy sille yn detail sjen wat jo krekt moatte begripe en hoe't it ynfloed hat op de besluten dy't jo elke dei meitsje. As ik hie bekend dizze dingen fan tefoaren, it soe hawwe besparre my in soad fergriemde tiid en twifele koade.
Hoewol't jo sille net sjen in inkele rigel fan koade hjirûnder, Ik leau noch dat alles sein hjir is fan grut belang foar in skriuwen fan hege kwaliteit, ekspressive koade.
Earste nivo fan begryp: Wêrom wurket it net?
Untwikkelders berikke dit nivo normaal heul betiid yn har karriêre, soms sels sûnder help fan oaren - teminsten yn myn ûnderfining. Stel jo foar dat jo in brekrapport hawwe krigen: guon funksje yn 'e applikaasje wurket net, it moat wurde reparearre. Hoe sille jo fierder?
It standertskema sjocht der sa út:
- Fyn it stik koade dat it probleem feroarsaket (hoe dit te dwaan is in apart ûnderwerp, ik beslach it yn myn boek oer legacy-koade)
- Meitsje feroarings oan dit snippet
- Soargje derfoar dat de brek is reparearre en gjin regression flaters hawwe bard
Litte wy no rjochtsje op it twadde punt - feroaringen oanmeitsje oan 'e koade. D'r binne twa oanpakken foar dit proses. De earste is om te ferdjipjen yn wat der krekt bart yn 'e hjoeddeistige koade, de flater identifisearje en it reparearje. Twad: ferpleatse troch gefoel - foegje, sis, +1 ta oan in betingste ferklearring of loop, sjoch as de funksje wurket yn it winske senario, besykje dan wat oars, en sa fierder ad infinitum.
De earste oanpak is korrekt. As Steve McConnell ferklearret yn syn boek Code Complete (dat ik trouwens sterk oanbefelje), elke kear as wy wat feroarje yn 'e koade, moatte wy mei fertrouwen kinne foarsizze hoe't it de applikaasje sil beynfloedzje. Ik sitearje út it ûnthâld, mar as in bugfix net wurket lykas jo ferwachte, moatte jo tige alarmearre wurde en jo moatte jo hiele aksjeplan freegje.
Om gearfetsje wat is sein, om in goede bugfix út te fieren dy't de kwaliteit fan 'e koade net degradearret, moatte jo sawol de heule struktuer fan' e koade as de boarne fan it spesifike probleem begripe.
Twadde nivo fan begryp: Wêrom wurket it?
Dit nivo wurdt folle minder yntuïtyf begrepen as it foarige. Ik, wylst noch in begjinnende ûntwikkelder, learde it mei tank oan myn baas, en dêrnei ferskate kearen útlein de essinsje fan 'e saak oan nijkommers.
Litte wy ús dizze kear foarstelle dat jo twa brekrapporten tagelyk krigen hawwe: de earste giet oer senario A, de twadde giet oer senario B. Yn beide senario's bart der wat mis. Dêrtroch pakke jo earst de earste bug oan. Mei help fan 'e begjinsels dy't wy ûntwikkele hawwe foar nivo XNUMX begryp, grave jo djip yn' e koade dy't relevant is foar it probleem, fynst út wêrom't it feroarsaket dat de applikaasje gedraacht sa't it docht yn senario A, en meitsje ridlike oanpassingen dy't it resultaat produsearje dat jo wolle. . Alles giet geweldich.
Dan geane jo troch nei senario B. Jo werhelje it senario yn in besykjen om in flater út te lokjen, mar-ferrassing! - no wurket alles sa't it moat. Om jo rieden te befêstigjen, meitsje jo de wizigingen ûngedien dy't jo makke hawwe wylst jo wurkje oan bug A, en brek B komt werom. Jo bugfix lost beide problemen op. Lucky!
Jo hawwe hjir hielendal net op rekkene. Jo binne mei in manier kommen om de flater te reparearjen yn senario A en hawwe gjin idee wêrom't it wurke foar senario B. Op dit poadium is it tige ferliedlik om te tinken dat beide taken mei súkses foltôge binne. Dit is frij logysk: it punt wie om flaters te eliminearjen, is it net? Mar it wurk is noch net klear: jo moatte noch útfine wêrom't jo aksjes de flater yn senario B korrizjearre hawwe. Wêrom? Om't it miskien wurket op 'e ferkearde prinsipes, en dan moatte jo sykje nei in oare útwei. Hjir binne in pear foarbylden fan sokke gefallen:
- Om't de oplossing net ôfstimd wie op flater B, mei alle faktoaren yn rekken brocht, kinne jo ûnbewust funksje C hawwe brutsen.
- It is mooglik dat d'r earne ek in tredde brek leit, relatearre oan deselde funksje, en jo bugfix hinget derfan ôf foar de juste wurking fan it systeem yn senario B. Alles sjocht der no goed út, mar ien dei sil dizze tredde brek opmurken en reparearre wurde. Dan yn senario B sil de flater wer foarkomme, en it is goed as allinich dêr.
Dit alles yntroduseart gaos yn 'e koade en sil ienris op jo holle falle - nei alle gedachten op it meast ûnopportune momint. Jo moatte jo wilskrêft sammelje om josels te twingen om tiid te besteegjen oan it begripen wêrom alles liket te wurkjen, mar it is it wurdich.
Tredde nivo fan begryp: Wêrom wurket it?
Myn resinte ynsjoch hat krekt betrekking op dit nivo, en it is wierskynlik dejinge dy't my it measte foardiel soe hawwe jûn as ik earder ta dit idee kaam wie.
Om it dúdliker te meitsjen, litte wy nei in foarbyld sjen: jo module moat kompatibel makke wurde mei funksje X. Jo binne net bysûnder bekend mei funksje X, mar jo hawwe jo ferteld dat jo it F-framework brûke moatte om dêr kompatibel te wêzen. modules dy't yntegrearje mei X wurkje krekt mei him.
Jo koade hat sûnt de earste dei fan syn libben hielendal net yn kontakt west mei it F-ramt, dus it útfieren sil net sa maklik wêze. Dit sil hawwe serieuze gefolgen foar guon dielen fan de module. Jo smite josels lykwols yn ûntwikkeling: jo besteegje wiken troch mei it skriuwen fan koade, testen, útroljen fan pilotferzjes, feedback krije, regressionflaters reparearje, ûnfoarsjoene komplikaasjes ûntdekke, net oan 'e oarspronklik ôfsprutsen deadlines foldwaan, wat mear koade skriuwe, testen, feedbackkommunikaasje krije, korrigearjen fan regressionfouten - dit alles om it F-kader út te fieren.
En op in stuit realisearje jo jo ynienen - of hearre jo miskien fan ien - dat miskien ramt F jo hielendal gjin kompatibiliteit mei funksje X jout. Miskien is al dy tiid en muoite dêr folslein ferkeard yn set.
Der barde ien kear sa'n ding by it wurk oan in projekt dêr't ik ferantwurdlik foar wie. Wêrom barde dit? Om't ik net folle begryp hie fan hokker funksje X wie en hoe't it ferbân hâlde mei ramt F. Wat hie ik dwaan moatten? Freegje de persoan dy't de ûntwikkelingstaak tawize om dúdlik te ferklearjen hoe't de bedoelde rin fan aksje liedt ta it winske resultaat, ynstee fan gewoan te herheljen wat foar oare modules dien is of har wurd foar it te nimmen dat dit is wat funksje X moat dwaan.
De ûnderfining fan dit projekt learde my om te wegerjen om it ûntwikkelingsproses te begjinnen oant wy in dúdlik begryp hawwe fan wêrom't wy wurde frege om bepaalde dingen te dwaan. Wegerje perfoarst. As jo in taak ûntfange, is de earste ympuls om it fuortendaliks op te nimmen om gjin tiid te fergriemen. Mar it belied "befrieze it projekt oant wy yn alle details komme" kinne fergriemde tiid ferminderje troch oarders fan grutte.
Sels as se besykje om druk op jo te setten, om jo te twingen om te wurkjen, hoewol jo de reden hjirfoar net begripe, ferset. Earst útfine wêrom't jo sa'n taak krije, en beslute oft dit it goede paad is nei it doel. Ik moast dit alles op 'e hurde manier leare - ik hoopje dat myn foarbyld it libben makliker sil meitsje foar dyjingen dy't dit lêze.
Fjirde nivo fan begryp: ???
D'r is altyd mear te learen yn programmearring, en ik leau dat ik allinich it oerflak fan it ûnderwerp fan begryp haw bekrast. Hokker oare nivo's fan begryp hawwe jo ûntdutsen oer de jierren fan wurkjen mei koade? Hokker besluten hawwe jo makke dy't in positive ynfloed hawwe op de kwaliteit fan 'e koade en tapassing? Hokker besluten die bliken ferkeard te wêzen en learden jo in weardefolle les? Diel jo ûnderfining yn 'e kommentaren.
Boarne: www.habr.com