ProHoster > Blogs > interneta ziņas > Nepiekrītiet attīstīt kaut ko, ko nesaprotat

Nepiekrītiet attīstīt kaut ko, ko nesaprotat

Nepiekrītiet attīstīt kaut ko, ko nesaprotat

KopÅ” 2018. gada sākuma komandā ieņemu vadoŔā/priekÅ”nieka/vadoŔā izstrādātāja amatu - sauciet kā gribat, bet bÅ«tÄ«ba ir tāda, ka esmu pilnÄ«bā atbildÄ«gs par vienu no moduļiem un par visiem izstrādātājiem, kas strādā uz tā. Å is amats man sniedz jaunu skatÄ«jumu uz attÄ«stÄ«bas procesu, jo esmu iesaistÄ«jies vairāk projektos un aktÄ«vāk iesaistos lēmumu pieņemÅ”anā. Nesen, pateicoties Ŕīm divām lietām, es pēkŔņi sapratu, cik ļoti izpratnes mērs ietekmē kodu un lietojumprogrammu.

Es vēlos uzsvērt, ka koda (un galaprodukta) kvalitāte ir cieÅ”i saistÄ«ta ar to, cik cilvēki, kuri izstrādā un raksta kodu, ir informēti par to, ko viņi dara.

Iespējams, jÅ«s Å”obrÄ«d domājat: "Paldies, Cap. Protams, bÅ«tu jauki saprast, ko tu vispār raksti. Pretējā gadÄ«jumā jÅ«s varētu arÄ« nolÄ«gt pērtiÄ·u grupu, lai nospiestu patvaļīgus taustiņus un atstātu to pie tā. Un jums ir pilnÄ«ga taisnÄ«ba. LÄ«dz ar to es uzskatu par paÅ”saprotamu, ka jÅ«s saprotat, ka ir nepiecieÅ”ams vispārējs priekÅ”stats par to, ko jÅ«s darāt. To var saukt par izpratnes nulles lÄ«meni, un mēs to sÄ«kāk neanalizēsim. Mēs detalizēti aplÅ«kosim, kas tieÅ”i jums ir jāsaprot un kā tas ietekmē jÅ«su ikdienas pieņemtos lēmumus. Ja es bÅ«tu zinājis Ŕīs lietas iepriekÅ”, tas man bÅ«tu aiztaupÄ«jis daudz laika un apÅ”aubāma koda.

Lai gan zemāk neredzēsit nevienu koda rindiņu, es joprojām uzskatu, ka visam Å”eit teiktajam ir liela nozÄ«me augstas kvalitātes, izteiksmÄ«ga koda rakstÄ«Å”anai.

Pirmais izpratnes līmenis: kāpēc tas nedarbojas?

Izstrādātāji parasti sasniedz Å”o lÄ«meni ļoti agri savā karjerā, dažreiz pat bez citu palÄ«dzÄ«bas ā€“ vismaz manā pieredzē. Iedomājieties, ka esat saņēmis kļūdu ziņojumu: kāda lietojumprogrammas funkcija nedarbojas, tā ir jālabo. Kā jÅ«s turpināsiet?

Standarta shēma izskatās Ŕādi:

  1. Atrodiet koda daļu, kas rada problēmu (kā to izdarÄ«t, ir atseviŔķa tēma, es to aplÅ«koju savā grāmatā par mantoto kodu)
  2. Veiciet izmaiņas Å”ajā fragmentā
  3. Pārliecinieties, vai kļūda ir novērsta un nav raduŔās regresijas kļūdas

Tagad pievērsÄ«simies otrajam punktam ā€“ izmaiņu veikÅ”anai kodā. Å im procesam ir divas pieejas. Pirmais ir iedziļināties tajā, kas tieÅ”i notiek paÅ”reizējā kodā, identificēt kļūdu un novērst to. Otrkārt: pārvietojieties pēc sajÅ«tas ā€” pievienojiet, teiksim, +1 nosacÄ«juma priekÅ”rakstam vai cilpai, pārbaudiet, vai funkcija darbojas vēlamajā scenārijā, pēc tam izmēģiniet kaut ko citu un tā tālāk bezgalÄ«gi.

Pirmā pieeja ir pareiza. Kā StÄ«vs Makkonels skaidro savā grāmatā Code Complete (kuru, starp citu, es ļoti iesaku), katru reizi, kad kaut ko mainām kodā, mums vajadzētu bÅ«t iespējai droÅ”i paredzēt, kā tas ietekmēs lietojumprogrammu. Es citēju no atmiņas, bet, ja kļūdu labojums nedarbojas tā, kā jÅ«s gaidÄ«jāt, jums vajadzētu bÅ«t ļoti satrauktiem un apÅ”aubÄ«t visu savu rÄ«cÄ«bas plānu.

Apkopojot teikto, lai veiktu labu kļūdu labojumu, kas nepasliktinātu koda kvalitāti, ir jāsaprot gan visa koda struktūra, gan konkrētās problēmas avots.

Otrais izpratnes līmenis: kāpēc tas darbojas?

Å is lÄ«menis tiek uztverts daudz mazāk intuitÄ«vi nekā iepriekŔējais. Es, vēl bÅ«dams iesācējs izstrādātājs, to uzzināju, pateicoties savam priekÅ”niekam, un pēc tam atkārtoti izskaidroju lietas bÅ«tÄ«bu jaunpienācējiem.

Å oreiz iedomāsimies, ka saņēmāt divus kļūdu ziņojumus uzreiz: pirmais ir par scenāriju A, otrais ir par scenāriju B. Abos gadÄ«jumos notiek kaut kas nepareizs. Tādējādi vispirms jānovērÅ” pirmā kļūda. Izmantojot principus, ko izstrādājām XNUMX. lÄ«meņa izpratnei, jÅ«s iedziļināties ar problēmu saistÄ«tajā kodā, noskaidrojiet, kāpēc tas liek lietojumprogrammai rÄ«koties tā, kā tas darbojas A scenārijā, un veiciet saprātÄ«gas korekcijas, kas nodroÅ”ina vēlamo rezultātu. . Viss notiek lieliski.

Pēc tam jÅ«s pārejiet uz scenāriju B. JÅ«s atkārtojat scenāriju, mēģinot izraisÄ«t kļūdu, taču ā€” pārsteigums! ā€” tagad viss darbojas kā nākas. Lai apstiprinātu savu minējumu, jÅ«s atsaucat izmaiņas, ko veicāt, strādājot ar kļūdu A, un kļūda B tiek atgriezta. JÅ«su kļūdu labojums atrisināja abas problēmas. Veiksmi!

JÅ«s ar to nemaz nerēķinājāties. JÅ«s esat izdomājis veidu, kā labot kļūdu scenārijā A, un jums nav ne jausmas, kāpēc tas darbojās scenārijā B. Å ajā posmā ir ļoti vilinoÅ”i domāt, ka abi uzdevumi ir veiksmÄ«gi izpildÄ«ti. Tas ir diezgan loÄ£iski: mērÄ·is bija novērst kļūdas, vai ne? Bet darbs vēl nav pabeigts: jums joprojām ir jāizdomā, kāpēc jÅ«su rÄ«cÄ«ba izlaboja kļūdu scenārijā B. Kāpēc? Jo tas var darboties pēc nepareiziem principiem, un tad jums bÅ«s jāmeklē cita izeja. Å eit ir daži Ŕādu gadÄ«jumu piemēri:

  • Tā kā risinājums nebija pielāgots kļūdai B, ņemot vērā visus faktorus, iespējams, jÅ«s neapzināti esat lauzis funkciju C.
  • Iespējams, ka kaut kur slēpjas arÄ« treŔā kļūda, kas saistÄ«ta ar to paÅ”u funkciju, un jÅ«su kļūdas labojums ir atkarÄ«gs no tā pareizai sistēmas darbÄ«bai scenārijā B. Tagad viss izskatās labi, bet kādu dienu Ŕī treŔā kļūda tiks pamanÄ«ta un izlabota. Tad B scenārijā kļūda atkārtosies, un tas ir labi, ja tikai tur.

Tas viss papildina kodu haosu un kādreiz uzkritÄ«s tev uz galvas ā€“ visticamāk, visnepiemērotākajā brÄ«dÄ«. Jums bÅ«s jāpieliek gribasspēks, lai piespiestu sevi pavadÄ«t laiku, lai saprastu, kāpēc Ŕķiet, ka viss darbojas, taču tas ir tā vērts.

TreÅ”ais izpratnes lÄ«menis: kāpēc tas darbojas?

Mans nesenais ieskats attiecas tieÅ”i uz Å”o lÄ«meni, un, iespējams, tas man bÅ«tu devis vislielāko labumu, ja es bÅ«tu nonācis pie Ŕīs idejas agrāk.

Lai padarÄ«tu to skaidrāku, aplÅ«kosim piemēru: jÅ«su modulis ir jāpadara savietojams ar funkciju X. JÅ«s neesat Ä«paÅ”i pazÄ«stams ar funkciju X, taču jums teica, ka, lai tas bÅ«tu saderÄ«gs ar to, jums ir jāizmanto F ietvars. moduļi, kas integrējas ar X, strādā tieÅ”i ar viņu.

JÅ«su kods vispār nav kontaktējies ar F ietvaru kopÅ” tā pirmās dzÄ«ves dienas, tāpēc tā ievieÅ”ana nebÅ«s tik vienkārÅ”a. Tam bÅ«s nopietnas sekas dažām moduļa daļām. Tomēr jÅ«s iesaistāties attÄ«stÄ«bā: pavadāt nedēļas, rakstot kodu, testējot, izlaižot izmēģinājuma versijas, saņemat atsauksmes, labojat regresijas kļūdas, atklājat neparedzētas komplikācijas, neievērojat sākotnēji norunātos termiņus, rakstāt vēl kādu kodu, testējat, saņemat atgriezenisko saziņu, regresijas kļūdu laboÅ”ana - tas viss, lai ieviestu F ietvaru.

Un kādā brÄ«dÄ« jÅ«s pēkŔņi saprotat ā€“ vai varbÅ«t dzirdat no kāda ā€“, ka, iespējams, ietvars F vispār nenodroÅ”inās saderÄ«bu ar funkciju X. VarbÅ«t viss laiks un pÅ«les tam tika ieguldÄ«ts pilnÄ«gi nepareizi.

Kaut kas lÄ«dzÄ«gs reiz notika, strādājot pie projekta, par kuru biju atbildÄ«gs. Kāpēc tas notika? Jo man bija maz izpratnes par to, kas ir funkcija X un kā tā ir saistÄ«ta ar ietvaru F. Kas man bija jādara? PalÅ«dziet personai, kas uzdod izstrādes uzdevumu, skaidri paskaidrot, kā iecerētā rÄ«cÄ«ba noved pie vēlamā rezultāta, nevis vienkārÅ”i atkārtot to, kas tika darÄ«ts citiem moduļiem, vai pieņemt vārdu, ka tas ir tas, kas X funkcijai ir jādara.

Å Ä« projekta pieredze man iemācÄ«ja atteikties sākt izstrādes procesu, lÄ«dz mēs skaidri sapratÄ«sim, kāpēc mums tiek prasÄ«ts darÄ«t noteiktas lietas. Atteikties tieÅ”i. Saņemot uzdevumu, pirmais impulss ir nekavējoties to uzņemties, lai netērētu laiku. Taču politika ā€œiesaldēt projektu, lÄ«dz mēs iedziļināsimies visās detaļāsā€ var par daudzām kārtām samazināt izŔķērdēto laiku.

Pat ja viņi mēģina uz jums izdarÄ«t spiedienu, piespiest jÅ«s sākt darbu, lai gan jÅ«s nesaprotat tā pamatojumu, pretojieties. Vispirms noskaidrojiet, kāpēc jums tiek dots Ŕāds uzdevums, un izlemiet, vai tas ir pareizais ceļŔ uz mērÄ·i. Man tas viss bija jāiemācās cietajā ceļā - es ceru, ka mans piemērs atvieglos dzÄ«vi tiem, kas to lasa.

Ceturtais izpratnes līmenis: ???

ProgrammÄ“Å”anā vienmēr ir ko mācÄ«ties, un es uzskatu, ka esmu tikai saskrāpējis izpratni par tēmu. Kādus citus izpratnes lÄ«meņus esat atklājis gadu gaitā, strādājot ar kodu? Kādus lēmumus jÅ«s pieņēmāt, kas pozitÄ«vi ietekmēja koda un lietojumprogrammas kvalitāti? Kādi lēmumi izrādÄ«jās nepareizi un deva jums vērtÄ«gu mācÄ«bu? Dalieties pieredzē komentāros.

Avots: www.habr.com

Pievieno komentāru