Mag-review — ano ito, paano gumagana ang code review at pagsusuri ng PR

Ano ang code review

Code review — ay ang sistematikong pagsusuri ng code ng mga kasamahan bago ito isama. Sa konteksto ng Git, ito ay nangangahulugang: ang developer ay gumagawa ng pull request na may mga pagbabago, nagtatalaga ng mga reviewer, at pinag-aaralan nila ang diff, nag-iiwan ng mga komento at nagbibigay ng desisyon. Ang reviewer ay maaaring humiling ng mga pagbabago (Request Changes), aprubahan ang PR (Approve) o mag-iwan ng pangkalahatang komento.

Ang code review ay may limang layunin: pagpapabuti ng kalidad ng code (pagtuklas ng mga depekto bago pumunta sa production), pagpapalaganap ng kaalaman (natututo ang reviewer ng mga bagong approach, ang may-akda ay tumatanggap ng feedback), pagsunod sa mga pamantayan (pagsusuri ng pagsunod sa code style at mga desisyon sa arkitektura), pagbabawas ng bus factor (ang code ay hindi lamang kilala ng isang developer) at pagbuo ng kultura ng responsibilidad (ang may-akda ay nagsusulat nang mas maingat, alam na ang code ay susuriin).

Ang kabaligtaran ng code review ay blind commit: itinutulak ng developer ang mga pagbabago sa karaniwang branch nang walang review. Ang ganitong approach ay pinapayagan lamang sa mga solong gumagamit na proyekto o para sa mga agarang hotfix na may kasunod na review. Sa propesyonal na pag-develop ng koponan, ang code review ay isang sapilitang yugto para sa anumang pagbabago, kabilang ang mga pag-aayos ng dokumentasyon at configuration.

Ano ang sinusuri sa code review

Ang code review ay dapat sistematiko, hindi magulo. Ang mga bihasang reviewer ay sumusuri ng code sa isang tiyak na pagkakasunod-sunod: una ang arkitektura at lohika, pagkatapos ang mga test, pagkatapos ang seguridad at pagganap, at sa wakas — estilo at pagpapangalan. Tinitiyak ng pagkakasunud-sunod na ito na ang mga kritikal na problema ay mapapansin bago mapagod ang reviewer.

Arkitektura at lohika: nalulutas ba ng code ang gawain, mayroon bang mga hindi kailangang abstraksiyon, sinusunod ba ang mga prinsipyong SOLID at DRY. Ang kumplikadong code na mahirap unawain sa unang pagbasa — isang senyales na kailangan ng refactoring. Dapat tiyakin ng reviewer na ang code ay eksaktong ginagawa kung ano ang nakasaad sa gawain at walang mga side effect sa labas ng saklaw ng responsibilidad nito.

Mga test: sinasaklaw ba ng mga bagong test ang lahat ng senaryo — positibo, negatibo, mga kaso sa hangganan. Pumapasa ba ang mga umiiral na test pagkatapos ng mga pagbabago. Mayroon bang mga flaky test na hindi matatag na pumapalya. Seguridad: kawalan ng SQL injection, XSS, pagtagas ng sensitibong data sa pamamagitan ng mga log o tugon ng API. Pagganap: kahusayan ng mga algorithm, labis na query sa database, pagtagas ng resource.

• Arkitektura — kawastuhan ng solusyon, pagsunod sa SOLID, kawalan ng over-engineering.
• Lohika — paghawak ng lahat ng senaryo, kabilang ang mga error at kaso sa hangganan.
• Mga test — saklaw ng mga bagong pagbabago, kawalan ng sirang lumang test.
• Seguridad — iniksyon, XSS, CSRF, pagtagas ng data sa pamamagitan ng log.
• Pagganap — kumplikasyon ng algorithm, N+1 query, pagtagas ng memorya.

Sukat ng review: bakit 400 linya ang maximum

Limitasyon ng laki ng PR — ang pinakamahalagang sukatan ng epektibidad ng code review. Ang pananaliksik ng Cisco (2015) at mga sumunod na eksperimento ng SmartBear at Google ay nagpakita: sa dami ng review na higit sa 400 linya, ang kakayahan ng reviewer na makakita ng mga depekto ay biglang bumababa. Kung lumampas ang PR sa 400 linya, ang mga error ay natutuklasan na may posibilidad na hindi mas mataas kaysa random.

Optimal na sukat: 200-400 linya para sa isang PR. Ang nasabing dami ay maaaring suriin ng reviewer sa loob ng 30-60 minuto, na pinapanatili ang konsentrasyon. Inirerekomenda ng Google ang hindi hihigit sa 200 linya para sa isang round ng review na may buong konsentrasyon. Kung mas marami ang pagbabago — ang gawain ay dapat hatiin sa ilang magkakasunod na PR, bawat isa ay nagdadala ng lohikal na kumpletong pagbabago.

Oras ng review: sa loob ng 24 na oras mula sa paggawa ng PR. Kung ang review ay tatagal ng ilang araw, mawawala ang konteksto ng gawain, at ang may-akda ay kailangang gumugol ng oras sa pagbawi ng konteksto kapag sumasagot sa mga komento. Ang mga koponan na may mataas na kultura ng code review ay nagtatakda ng SLA para sa review: halimbawa, 4 na oras para sa mga kritikal na pagbabago at 24 na oras para sa mga ordinaryo.

Paano magsulat ng tamang komento sa review

Ton ng mga komento — ay mahalaga para sa epektibidad ng code review. Ang komentong "Ito ay mali" ay nagdudulot ng depensibong reaksyon at hindi nagbibigay ng kapaki-pakinabang na impormasyon sa may-akda. Ang pinakamahusay na pormulasyon ay tanong-mungkahi: "Ano sa palagay mo sa approach na ito?", "Dito maaaring magkaroon ng NPE kung ang user == nil. Baka magdagdag ng guard?". Ang mga tanong ay hindi gaanong pumipilit at nagpapasigla ng talakayan.

Ang istraktura ng isang magandang komento ay may kasamang tatlong bahagi: ano ang mali, bakit ito problema at kung paano ito ayusin. Halimbawa: "Sa loop na ito, ginagamit ang O(n²) dahil sa nested contains, na maaaring bumagal sa 10k+ na record. Subukang palitan ng Set para sa O(1) na paghahanap". Ang ganitong pormulasyon ay sabay na nagpapahiwatig ng problema, nagpapaliwanag ng kahalagahan nito at nag-aalok ng solusyon — ang may-akda ay hindi kailangang manghula.

Sinusuportahan ng GitHub at GitLab ang suggestions — mga built-in na mungkahi ng pagbabago ng code. Ang reviewer ay maaaring sumulat: "```suggestion Salain ang mga walang laman na linya bago ang pagproseso```" — at ilalapat ng may-akda ang pagbabago sa isang click. Pinapabilis nito ang maliliit na pag-aayos at binabawasan ang bilang ng mga round ng review. Para sa malalaking pag-aayos, mas mabuting magsulat ng pangkalahatang komento kaysa maglagay ng malalaking bloke sa suggestion.

# Template para sa magandang komento ng code review

# MASAMA: "Mali ang code na ito"
# MABUTI: "Maaari tayong mawalan ng data sa walang laman na tugon.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Syntax ng suhestiyon sa GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow ng code review sa koponan

Ang epektibong workflow ng review ay batay sa apat na yugto. Una — inihahanda ng may-akda ang PR: nagsusulat ng malinaw na pangalan (hal., "feat: add password reset screen"), nagdaragdag ng paglalarawan ng mga pagbabago, link sa gawain sa tracker at mga tagubilin sa pag-test. Pangalawa — nagtatalaga ng reviewer ang may-akda sa pamamagitan ng auto-assign (batay sa CODEOWNERS) o manwal.

Ikatlong yugto — sinusuri ng reviewer ang code at nag-iiwan ng mga komento. Ikaapat — ang may-akda ay gumagawa ng mga pag-aayos, sumasagot sa mga komento at humihiling ng muling review. Ang cycle ay paulit-ulit hanggang sa makuha ang pag-apruba. Pagkatapos ng pag-apruba, ang may-akda ay nagsasagawa ng merge (o ang merge ay ginagawa ng bot). Ang automation sa pamamagitan ng Mergify o GitHub Auto-merge ay nagpapabilis sa huling yugto.

Mahalagang elemento ng workflow — pamamahala ng mga lumang PR. Kung ang PR ay walang review nang higit sa 3 araw, ang proseso ay naharang. Mga solusyon: pag-ikot ng mga reviewer (kung ang itinalagang reviewer ay hindi available), mga notification sa pamamagitan ng Slack/Teams, limitasyon ng oras para sa review (SLA). Sa ilang koponan, ang PR na walang review nang higit sa 7 araw ay awtomatikong isinasara, at ang may-akda ay gumagawa ng bago pagkatapos ng pag-synchronize sa main.

• Paglikha ng PR — malinaw na pangalan, paglalarawan, link sa gawain, screenshot para sa mga pagbabago sa UI.
• Pagtatalaga — auto-assign sa pamamagitan ng CODEOWNERS o manwal na pagpili ng 1-2 reviewer.
• Review — pagsusuri sa pagkakasunod-sunod: arkitektura → lohika → test → seguridad → estilo.
• Pag-aayos — sumasagot ang may-akda sa lahat ng komento, nag-aayos ng blocking issues, humihiling ng re-review.
• Merge — pagkatapos ng pag-apruba at berdeng CI, ang may-akda o bot ay nagsasagawa ng pagsasama.

Mga karaniwang pagkakamali sa code review

Unang pagkakamali — mababaw na review. Ang reviewer ay mabilis na tumitingin sa diff, hindi lumalalim sa lohika, at pumipindot ng Approve. Mga dahilan: malaking PR, deadline, pagkapagod. Bunga: pumapasok ang mga bug sa production. Solusyon: kung walang oras para sa kalidad na review — sumulat ng tapat na "Hindi ako makapagsuri ngayon, ipagpaliban bukas" sa halip na pormal na pag-apruba.

Pangalawang pagkakamali — labis na pamumuna (nitpicking). Ang reviewer ay nag-iiwan ng dose-dosenang komento tungkol sa estilo ng pag-format, pagpapangalan ng variable, mga trivial na detalye. Ito ay nagde-demotivate sa may-akda at nagpapahaba ng review. Solusyon: ang StyleGuide at linter ay dapat awtomatikong suriin ang estilo. Ang tao sa review ay sumusuri ng lohika, arkitektura at seguridad.

Pangatlong pagkakamali — review na walang tanong. Kung ang reviewer ay naglalagay lamang ng Request Changes at Approve, ngunit hindi nagtatanong, nawawala ang pagkakataong matuto ng bago. Ang pinakamahusay na indikasyon ng kalusugan ng code review ay ang pagkakaroon ng mga talakayan kung saan ang magkabilang panig ay natututo ng bago. Kung ang review ay monologo ng isa sa mga kalahok — ang proseso ay sira.

• Mababaw na review — Approve nang walang paglalim. Solusyon: huwag mag-review kung walang oras.
• Nitpicking — pamumuna ng estilo na sinusuri ng linter. Solusyon: i-automate ang style checks.
• Personal na pananaw — "ako ay magsusulat nang iba". Solusyon: ang code ay dapat gumana, hindi magustuhan ng reviewer.
• Pagpapahaba — review na higit sa 24 na oras. Solusyon: SLA para sa review, eskalasyon sa paglabag.
• Pagbalewala sa konteksto — review ng code nang hindi nauunawaan ang gawain. Solusyon: basahin ang paglalarawan ng PR bago ang diff.