Bilang isang engineer ng junior software, palagi akong nagbigay ng mga komento sa pagsusuri ng code na natanggap ko upang malaman kung paano maging isang mas mahusay na coder. Ngunit nang dumating ang oras para sa akin na subukan ang aking unang pagsusuri ng code, naisip ko na ang aking karanasan ay hindi ako naghanda na maging nasa kabilang linya.
Gumawa ako ng isang malubhang kaso ng imposter syndrome, na bumababang pababa na may mga tanong: Dapat ba akong magkomento sa linyang ito ng code o hindi ba ito nagkakahalaga? Dapat ba akong makahanap ng mga artikulo upang suportahan ang bawat puna? Babagsak ko ba ang site sa pamamagitan ng pag-apruba nito? Galit ba sila sa akin? Okay, inaamin kong mabilis ako. Ngunit matapos makipag-usap sa ilang mga katrabaho, alam kong hindi ako nag-iisa sa aking mga alala.
Ang mga inhinyero ng software ng junior ay maaaring ihagis sa pagsusuri ng code na may isang pagkakatulad na "alam mo kung paano magbasa ng isang libro upang malaman mo kung paano sumulat ng isang libro, na hindi totoo, " sabi ni Jessica Rudder, isang karanasan sa engineer sa GitHub.
May mga inaasahan na darating sa pagsusuri ng code, at ang proseso ay maaaring maging racking ng nerve. Kaya kinapanayam ko ang pitong iba pang mga inhinyero ng software upang mangolekta ng mga tip sa kung paano bumuo ng isang pagsusuri ng mindset.
1. Pag-isipan ang Pangkalahatang Epekto
Karaniwan, ang isang mahusay na kahilingan sa pull (PR) ay dapat lamang makaapekto sa isang nakakulong na bahagi ng codebase. Gayunpaman, ang limitadong saklaw ay hindi dapat pigilan ka mula sa pag-iisip tungkol sa pagbabago ng code sa loob ng konteksto ng mas malaking codebase.
Si Nigel Munoz, isang dating full-stack engineer sa The Muse at isang kasalukuyang engineer ng freelance software, ay hinihikayat ang reviewer na isipin ang tungkol sa "kung paano nakakaapekto ang pagbabagong ito sa mas malaki at mas maliit na larawan." Ang pagsasaalang-alang sa mas malaking larawan ay may kasamang paghahanap ng anumang mga teknikal na utang - hanapin ang code iyon ay paulit-ulit, hindi modular, o hindi sumunod sa pinakabagong mga karaniwang kombensyon - pati na rin ang pagsusuri ng mga pagbabago sa arkitektura ng codebase.
Si Sam Donow, isang pangunahing tagabuo sa Hudson River Trading, ay naniniwala na "walang masyadong malaki o napakaliit na magkomento. Ang mga mungkahi para sa maliliit na pagpapabuti ay maaaring humantong sa mas malaking pagpapabuti sa maraming bahagi ng codebase. "
Maaari kang gumamit ng puna ng PR sa GitHub upang magbigay ng positibong puna pati na rin ituro kung saan ang code ay maaaring magkakaiba sa karaniwang mga kombensyon ng balangkas ng React.
Halimbawa, sa panahon ng aking sariling mga pagsusuri sa code, nakatanggap ako ng komento na ang ilang mga pag-aari sa isang sangkap na React ay nakalilito, na nagpalabas ng mas malawak na mga katanungan tungkol sa kung paano ginagamit ang sangkap. Sa huli, tinanggal ko ang mga katangian mula sa orihinal na sangkap at lumikha ng isang hiwalay na sangkap upang linawin ang pag-uugali ng bawat isa at matiyak na kapwa maaaring magamit sa parehong mga lugar.
2. Isaalang-alang ang Seguridad
Huwag kalimutan na ang ilang mga pagbabago ay maaaring makaapekto sa higit pa sa codebase. Inirerekomenda ni Rudder na suriin kung ang isang gumagamit ay "maaaring gumamit ng pag-andar na ito upang harapin ang isang tao o maaaring abusuhin ang system." Halimbawa, kung ang bagong tampok sa paghiling ng pull ay may kasamang pagpasok ng gumagamit, hanapin ang SQL injection, data access, script-site script, at iba pang kahinaan sa seguridad.
3. Tumutok sa Mga bug
Ang iyong mga kapwa tagabigay ng code - kahit gaano pa ang robotic na tila nila ay tao, at ang mga tao ay maaaring masira o makalimutan ang mga pag-andar. Kaya siguraduhing "suriin mo ang mga pagsubok na may parehong kahalagahan tulad ng natitirang code, " payo ni Abhishek Pillai, isang nangunguna sa tech sa Mga Guro ng Mga Pay Pay. "Pipigilan nila ang mga bagong bug at magsisilbing isang form ng dokumentasyon sa sinumang gumagawa nito sa hinaharap."
Ang pagbabasa ng mga pagsubok ay makakatulong sa iyo na maunawaan ang pag-andar ng isang bagong tampok at makita ang iba't ibang mga kaso na ipakikilala nito, habang ang pagsusuri sa mga pagsubok ay makakatulong sa iyo na ituro ang mga nawawalang kaso at makahanap ng mga tampok na hindi nakapaloob sa PR na ito. Kung walang mga pagsubok na kasama sa pagbabago ng code at tila may kaugnayan ito, nararapat na hilingin ang mga ito sa loob ng pagsusuri.
Ngunit ang mga pagsubok ay hindi lahat. "Huwag maglagay ng labis na pananampalataya sa system, " babala ni Donow. "Dahil lamang sa mga pagsubok na tumakbo ay hindi nangangahulugang walang mga bug."
Maaari mo ring nais na "patakbuhin ang app nang lokal upang gumana na subukan ito at tiyaking gumagana ito. Kung hindi ito gumana, kung gayon walang punto sa karagdagang pagsusuri, "sabi ni Ryan Verner, isang developer ng software sa ika-8 na Liwanag. Kahit na hindi iniisip ng ilang mga tagasuri ang manu-manong pagsusuri ay dapat na bahagi ng proseso ng pagsusuri ng code - sa bahagi dahil sa oras na kinakailangan - Naniniwala si Verner na mabilis na paraan upang matukoy kung dapat kang mamuhunan ng mas maraming oras sa pagsusuri pati na rin ang isang diskarte upang matulungan ang pagbawas ang paglaki ng isang bug backlog.
4. Maging isang Player Player
Ang cliché ay tumatagal ng bagong kahulugan pagdating sa pagsusuri ng code. "Gumawa ng oras upang suriin dahil ito ang codebase ng lahat, " sabi ni Verner, na nagsusulong para sa isang kahulugan ng "kolektibong pagmamay-ari." Ikaw, bilang tagasuri, ay dapat na nagtatrabaho patungo sa pagprotekta sa backlog ng mga bug mula sa paglaki ng mas malaki sa layunin na ibigay ang iyong mas mababa sa trabaho ang koponan.
Ginagamit ni Pillai ang mga gif upang ipagdiwang ang naaprubahan ng kanyang mga kasama sa koponan at handa nang pagsamahin ang mga PR.
Sa parehong oras, si Charles Luxton, isang tech na nangunguna sa The Muse, ay hinihikayat ang tagasuri na maunawaan at alalahanin ang mga prioridad ng koponan. Sa mabilis na mga paparating at hindi pagkakasundo na napupuno, kung minsan ay lumilikha ng isang bagay na dapat gawin para sa backlog na nagsisiguro na ang mga pagpapabuti ay gagawin sa hinaharap at maglagay ng puna sa code na pinag-uusapan sa habang panahon ay ang Band-Aid na kailangan mo upang panatilihing masaya ang iyong koponan.
Sa wakas, tanungin ang iyong sarili kung ang code ay magkakaroon ba ng kahulugan sa isang tao na sumali lamang sa koponan at binabasa ito sa loob ng kanilang unang ilang linggo ay makakatulong na mababasa at maiintindihan ang iyong code.
5. Gamitin ang Proseso para sa Pagbabahagi ng Pagkatuto at Kaalaman
Ang proseso ng pagsusuri ay nagbibigay sa lahat ng kasangkot sa isang lugar upang makakuha ng higit pang pananaw sa codebase, wika, frameworks, at pinakamahusay na kasanayan.
Si Matt Jeffery, isang tech na nangunguna sa The Muse, ay nagpapayo sa repasuhin na "maunawaan ang mga pagbabago ng arkitektura. Isang paraan ay ang basahin ang mga pangalan ng file mula sa tulong nila na magbigay ng konteksto. Halimbawa, kung naghahanap ka ng pagbabago sa layer ng pag-access ng data alam mong hindi ka nakikipag-ugnayan sa logic ng negosyo o UI. "
Maaari kang gumamit ng puna ng PR sa GitHub upang magbahagi ng babasahin.
Kapag nalaman mo mula sa mga pagbabago sa code, mayroon ka ring pagkakataon na magbahagi ng kaalaman. "Pinakamabuting ipaliwanag ang iyong opinyon at i-back up ito sa dokumentasyon, " sabi ni Luxton. Ang mga link na ibinibigay mo sa pagsuporta sa katibayan at mapagkakatiwalaang mga artikulo ay hindi lamang makakatulong sa tagasuri at code ng manunulat na galugarin ang iba't ibang mga diskarte habang gumawa sila ng isang pangwakas na pasya, ngunit din palakasin ang kanilang kaalaman sa programming.
Habang iniisip mo ang mga tip na ito, tandaan din na ang pagsusuri ay isang oras upang magamit ang iyong mga kasanayan sa mga tao. "Bigyan ang mga tao ng pakinabang ng pag-aalinlangan na naisip nila ang kanilang diskarte at ituro ang iba't ibang mga posibilidad habang sinusubukan na iwaksi ang defensiveness, " sabi ni Rudder. "Nag-iwan ako ng mga puna sa buong at isang pambalot na puna - narito kung ano ang mahusay, narito ang maaaring mapabuti, narito ang kailangang baguhin bago pagsamahin."
Sa ganitong uri ng diskarte, hindi lamang mapoprotektahan ang iyong code base mula sa utang sa tech, pagbabanta sa seguridad, at mga bug, ngunit bubuo ka rin ng iyong koponan.
