Mula sa simula ng 2018, hawak ko na ang posisyon ng lead/boss/lead developer sa team - tawagan ito kung ano ang gusto mo, ngunit ang punto ay ako ay ganap na responsable para sa isa sa mga module at para sa lahat ng mga developer na nagtatrabaho sa ibabaw nito. Ang posisyon na ito ay nagbibigay sa akin ng isang bagong pananaw sa proseso ng pag-unlad, dahil ako ay kasangkot sa higit pang mga proyekto at mas aktibong kasangkot sa paggawa ng desisyon. Kamakailan lamang, salamat sa dalawang pangyayaring ito, bigla kong napagtanto kung gaano nakakaapekto ang sukatan ng pag-unawa sa code at sa aplikasyon.
Ang puntong gusto kong gawin ay ang kalidad ng code (at ang huling produkto) ay malapit na nauugnay sa kung gaano kamalayan ang mga taong nagdidisenyo at nagsusulat ng code sa kanilang ginagawa.
Maaaring iniisip mo ngayon, “Salamat, Cap. Siyempre, ito ay magiging maganda upang maunawaan kung ano ang iyong isinusulat sa pangkalahatan. Kung hindi, maaari kang umarkila ng isang grupo ng mga unggoy upang pindutin ang mga arbitrary key at iwanan ito doon." At ikaw ay ganap na tama. Alinsunod dito, ipinagkakaloob ko na napagtanto mo na ang pagkakaroon ng pangkalahatang ideya ng iyong ginagawa ay kinakailangan. Ito ay matatawag na zero level of understanding, at hindi natin ito susuriin nang detalyado. Titingnan namin nang detalyado kung ano ang eksaktong kailangan mong maunawaan at kung paano ito nakakaapekto sa mga desisyong ginagawa mo araw-araw. Kung alam ko ang mga bagay na ito nang maaga, ito ay makakapagligtas sa akin ng maraming nasayang na oras at kaduda-dudang code.
Bagama't hindi ka makakakita ng isang linya ng code sa ibaba, naniniwala pa rin ako na ang lahat ng sinabi dito ay napakahalaga para sa pagsulat ng mataas na kalidad, nagpapahayag na code.
Unang antas ng pag-unawa: Bakit hindi ito gumagana?
Karaniwang naaabot ng mga developer ang antas na ito nang maaga sa kanilang mga karera, kung minsan kahit na walang anumang tulong mula sa iba - hindi bababa sa aking karanasan. Isipin na nakatanggap ka ng ulat ng bug: ang ilang function sa application ay hindi gumagana, kailangan itong ayusin. Paano ka magpapatuloy?
Ang karaniwang scheme ay ganito ang hitsura:
- Hanapin ang piraso ng code na nagdudulot ng problema (kung paano ito gagawin ay isang hiwalay na paksa, saklaw ko ito sa aking aklat tungkol sa legacy code)
- Gumawa ng mga pagbabago sa snippet na ito
- Siguraduhing naayos ang bug at walang naganap na mga error sa pagbabalik
Ngayon, tumuon tayo sa pangalawang punto - paggawa ng mga pagbabago sa code. Mayroong dalawang mga diskarte sa prosesong ito. Ang una ay upang bungkalin kung ano ang eksaktong nangyayari sa kasalukuyang code, tukuyin ang error at ayusin ito. Pangalawa: ilipat ayon sa pakiramdam - magdagdag, sabihin, +1 sa isang conditional statement o loop, tingnan kung gumagana ang function sa nais na senaryo, pagkatapos ay subukan ang ibang bagay, at iba pa ad infinitum.
Ang unang diskarte ay tama. Tulad ng ipinaliwanag ni Steve McConnell sa kanyang aklat na Code Complete (na lubos kong inirerekumenda, sa pamamagitan ng paraan), sa tuwing babaguhin natin ang isang bagay sa code, dapat nating mahulaan nang may kumpiyansa kung paano ito makakaapekto sa aplikasyon. Sumipi ako mula sa memorya, ngunit kung ang isang bugfix ay hindi gumana sa paraang inaasahan mo, dapat kang maalarma at dapat mong tanungin ang iyong buong plano ng aksyon.
Upang ibuod kung ano ang sinabi, upang maisagawa ang isang mahusay na pag-aayos ng bug na hindi nagpapababa sa kalidad ng code, kailangan mong maunawaan pareho ang buong istraktura ng code at ang pinagmulan ng partikular na problema.
Pangalawang antas ng pag-unawa: Bakit ito gumagana?
Ang antas na ito ay naiintindihan nang hindi gaanong intuitive kaysa sa nauna. Ako, habang isang baguhan na developer, natutunan ko ito salamat sa aking boss, at pagkatapos ay paulit-ulit na ipinaliwanag ang kakanyahan ng bagay sa mga bagong dating.
Sa pagkakataong ito, isipin natin na nakatanggap ka ng dalawang ulat ng bug nang sabay-sabay: ang una ay tungkol sa senaryo A, ang pangalawa ay tungkol sa senaryo B. Sa parehong mga senaryo, may nangyaring mali. Alinsunod dito, haharapin mo muna ang unang bug. Gamit ang mga prinsipyong binuo namin para sa Antas XNUMX na pag-unawa, hinuhukay mo nang malalim ang code na nauugnay sa problema, alamin kung bakit ito nagiging sanhi ng pag-uugali ng application sa paraang ginagawa nito sa Scenario A, at gumawa ng mga makatwirang pagsasaayos na magbubunga ng resulta na gusto mo. . Lahat ay maganda.
Pagkatapos ay lumipat ka sa senaryo B. Ulitin mo ang senaryo sa pagtatangkang pukawin ang isang error, ngunit—sorpresa! — ngayon lahat ay gumagana ayon sa nararapat. Upang kumpirmahin ang iyong hula, i-undo mo ang mga pagbabagong ginawa mo habang gumagawa sa bug A, at babalik ang bug B. Nalutas ng iyong bugfix ang parehong problema. Swerte!
Hindi ka umaasa dito. Nakagawa ka ng paraan para ayusin ang error sa senaryo A at wala kang ideya kung bakit ito gumana para sa senaryo B. Sa yugtong ito, napaka-kaakit-akit isipin na ang parehong mga gawain ay matagumpay na natapos. Ito ay lubos na lohikal: ang punto ay upang alisin ang mga pagkakamali, hindi ba? Ngunit hindi pa tapos ang gawain: kailangan mo pa ring malaman kung bakit naitama ng iyong mga aksyon ang error sa senaryo B. Bakit? Dahil maaaring ito ay gumagana sa mga maling prinsipyo, at pagkatapos ay kakailanganin mong maghanap ng ibang paraan. Narito ang ilang halimbawa ng mga ganitong kaso:
- Dahil ang solusyon ay hindi iniayon sa error B, na isinasaalang-alang ang lahat ng mga salik, maaaring hindi mo namamalayan na nasira ang function C.
- Posibleng mayroon ding pangatlong bug na nakatago sa isang lugar, na nauugnay sa parehong function, at nakasalalay dito ang iyong bugfix para sa tamang operasyon ng system sa scenario B. Mukhang maayos na ang lahat, ngunit isang araw ay mapapansin at maaayos ang ikatlong bug na ito. Pagkatapos ay sa scenario B ang error ay magaganap muli, at ito ay mabuti kung doon lamang.
Ang lahat ng ito ay nagdaragdag ng kaguluhan sa code at balang araw ay mahuhulog sa iyong ulo - malamang sa pinaka-hindi angkop na sandali. Kailangan mong tipunin ang iyong paghahangad upang pilitin ang iyong sarili na gumugol ng oras sa pag-unawa kung bakit tila gumagana ang lahat, ngunit sulit ito.
Ikatlong antas ng pag-unawa: Bakit ito gumagana?
Ang aking kamakailang insight ay tiyak na nauugnay sa antas na ito, at ito ay marahil ang isa na magbibigay sa akin ng pinakamaraming benepisyo kung ako ay dumating sa ideyang ito nang mas maaga.
Para mas maging malinaw, tingnan natin ang isang halimbawa: kailangang gawing tugma ang iyong module sa function X. Hindi ka partikular na pamilyar sa function X, ngunit sinabihan ka na para maging compatible dito kailangan mong gamitin ang F framework. Iba pa ang mga module na sumasama sa X ay gumagana nang eksakto sa kanya.
Ang iyong code ay hindi kailanman nakikipag-ugnayan sa F framework mula noong unang araw ng buhay nito, kaya ang pagpapatupad nito ay hindi magiging madali. Ito ay magkakaroon ng malubhang kahihinatnan para sa ilang bahagi ng modyul. Gayunpaman, itinatapon mo ang iyong sarili sa pag-unlad: gumugugol ka ng mga linggo sa pagsulat ng code, pagsubok, paglulunsad ng mga pilot na bersyon, pagkuha ng feedback, pag-aayos ng mga error sa regression, pagtuklas ng mga hindi inaasahang komplikasyon, hindi pagtupad sa orihinal na napagkasunduan na mga deadline, pagsulat ng ilang karagdagang code, pagsubok, pagkuha ng feedback na komunikasyon, pagwawasto ng mga error sa regression - lahat ng ito para maipatupad ang F framework.
At sa isang punto ay bigla mong napagtanto - o maaaring marinig mula sa isang tao - na maaaring ang framework F ay hindi magbibigay sa iyo ng pagiging tugma sa tampok na X. Marahil sa lahat ng oras at pagsisikap na iyon ay ganap na mali.
May katulad na nangyari minsan habang gumagawa ng isang proyekto kung saan ako ang may pananagutan. Bakit nangyari ito? Dahil wala akong gaanong pag-unawa sa kung ano ang function ng X at kung paano ito nauugnay sa framework F. Ano ang dapat kong gawin? Hilingin sa taong nagtatalaga ng gawain sa pagpapaunlad na malinaw na ipaliwanag kung paano humahantong sa ninanais na resulta ang nilalayong hakbang ng pagkilos, sa halip na ulitin lamang kung ano ang ginawa para sa iba pang mga module o tanggapin ang kanilang salita para dito na ito ang kailangang gawin ng feature X.
Ang karanasan ng proyektong ito ay nagturo sa akin na tumanggi na simulan ang proseso ng pagbuo hanggang sa magkaroon tayo ng malinaw na pag-unawa kung bakit tayo hinihiling na gawin ang ilang bagay. Tumanggi nang tahasan. Kapag nakatanggap ka ng isang gawain, ang unang salpok ay agad na gawin ito upang hindi mag-aksaya ng oras. Ngunit ang patakarang "i-freeze ang proyekto hanggang sa makuha namin ang lahat ng mga detalye" ay maaaring mabawasan ang nasayang na oras sa pamamagitan ng mga order ng magnitude.
Kahit na subukan nilang bigyan ka ng presyon, upang pilitin kang magsimula sa trabaho, kahit na hindi mo naiintindihan ang katwiran para dito, lumaban ka. Una, alamin kung bakit ka binibigyan ng ganoong gawain, at magpasya kung ito ang tamang landas patungo sa layunin. Kinailangan kong matutunan ang lahat ng ito sa mahirap na paraan - sana ang aking halimbawa ay gawing mas madali ang buhay para sa mga nagbabasa nito.
Ikaapat na antas ng pag-unawa: ???
Palaging marami pang dapat matutunan sa programming, at naniniwala ako na scratched ko lang ang ibabaw ng paksa ng pag-unawa. Anong iba pang mga antas ng pag-unawa ang natuklasan mo sa mga taon ng pagtatrabaho sa code? Anong mga desisyon ang ginawa mo na may positibong epekto sa kalidad ng code at aplikasyon? Anong mga desisyon ang naging mali at nagturo sa iyo ng mahalagang aral? Ibahagi ang iyong karanasan sa mga komento.
Pinagmulan: www.habr.com