Code Review — esensya, mga patakaran at kung paano magsagawa ng pagsusuri sa koponan

Ano ang Code Review?

Code Review — proseso ng pagsusuri ng source code ng isa o higit pang mga developer bago ito isama sa pangunahing sangay ng proyekto. Ang layunin ng pagsusuri ay hindi lamang paghahanap ng mga error, kundi pati na rin ang pagpapabuti ng arkitektura, pagsunod sa mga pamantayan ng koponan at pagpapalaganap ng kaalaman. Hindi tulad ng awtomatikong pagsusuri (mga linter), ang code review ay ginagawa ng tao at sinusuri ang pagiging madaling basahin, lohika at mga desisyong arkitektural.

Ayon sa Google Engineering Practices, 2024, ang Code Review ay nahahati sa dalawang pantay na layunin: protektahan ang codebase mula sa mga depekto at sanayin ang mga developer sa pamamagitan ng feedback. Sa mga mobile project, ang pagsusuri ay kinakailangang may kasamang pagsusuri ng mga framework (UIKit, SwiftUI, Jetpack Compose), pamamahala ng memorya at pagtatrabaho sa mga network request.

Code Review sa GitLab at GitHub ay isinaayos sa pamamagitan ng Merge Request at Pull Request. Bawat MR/PR ay naglalaman ng diff, mga komento sa mga linya, mga diskusyon at mga status ng pagsusuri. Ayon sa pananaliksik ng Microsoft Research (2023), ang mga koponan na nagsasagawa ng regular na pagsusuri ay naglalabas ng 40% na mas kaunting kritikal na bug sa produksyon.

Kasaysayan ng Code Review: mula sa pormal na inspeksyon hanggang sa asynchronous na PR

Ang unang pormal na Code Review ay lumitaw sa IBM noong 1970s bilang „mga structured na inspeksyon" na may step-by-step na checklist at protocol. Noong 2000s sa pagkalat ng Git at mga distributed na koponan, ang pagsusuri ay nag-evolve sa asynchronous na format sa pamamagitan ng Pull Request. Ginawa ng GitHub (2008) ang PR bilang isang mass phenomenon. Ang modernong Code Review ay isang impormal, asynchronous na proseso na may diin sa bilis at pag-aaral, hindi sa burukrasya.

Mga Uri ng Code Review: pormal at di-pormal na mga diskarte

Code Review ay inuri sa apat na pangunahing uri depende sa proseso at paglahok ng mga kalahok. Pormal (Asynchronous Review) — pagsusuri sa pamamagitan ng MR/PR nang walang synchronous na komunikasyon, pinakakaraniwan sa mga distributed na koponan. Di-pormal — quick CR, kapag ang isang developer ay lumapit sa isa pa at humiling na tingnan ang code sa loob ng 5 minuto.

Ayon sa Microsoft Research, 2023, ang pair programming — dalawang developer ay nagtatrabaho sa isang screen, bawat code ay isinusulat sa real-time na may pagsusuri „on the fly". Over-the-shoulder — isang developer ay tumitingin sa screen ng isa pa at nagkokomento ng code nang walang pormal na proseso. Walkthrough — ang may-akda ng code ay naggabay sa isang grupo ng mga developer sa pamamagitan ng mga pagbabago, ipinapaliwanag ang bawat desisyon.

Listahan ng Pagsusuri ng Code Review: ano ang susuriin sa code

Ang listahan ng pagsusuri ng Code Review ay tumutulong sa reviewer na hindi makaligtaan ang mga kritikal na mahalagang aspeto. Unang kategorya — kawastuhan at arkitektura: ang solusyon ba ay tumutugma sa itinakdang gawain, may labis na pagiging kumplikado, ang mga pattern ba (MVP, MVVM, Clean Architecture) ay napili nang tama. Ikalawang kategorya — estilo at pag-format: sinusunod ba ang estilo ng code ng koponan (Kotlin Code Style, Swift Style Guide).

Ayon sa Thoughtbot Code Review Guide, 2024, ikatlong bloke — pagsubok: mayroon bang mga unit test na naisulat, sinasaklaw ba nila ang mga boundary case, hindi ba nila sinira ang mga umiiral na test. Ikaapat — seguridad: mayroon bang mga naka-hardcode na token, API key, SQL injection, memory leak. Ikalima — pagganap: tama ba ang paggamit ng coroutines/RxJava, mayroon bang pag-block ng UI thread, labis na alokasyon.

• Lohika — kawastuhan ng algorithm, paghawak ng mga boundary case at error
• Arkitektura — pagsunod sa Clean Architecture, MVVM, paghihiwalay ng responsibilidad
• Estilo ng code — pagpapangalan, pag-format, pagkakapareho sa proyekto
• Mga Pagsubok — pagkakaroon ng mga unit test, kanilang pagkakumpleto at berdeng status

Paano Magsagawa ng Code Review: mga panuntunan para sa reviewer

Code Review ay nangangailangan mula sa reviewer ng balanse sa pagitan ng pagiging masinsin at bilis. Pangunahing panuntunan — suriin ang code sa maliliit na bahagi. Optimal na dami — 200–400 linya ng mga pagbabago bawat sesyon. Ayon sa Google Research (2022), ang pagsusuri ng higit sa 500 linya ay nawawalan ng bisa: ang bilang ng mga napalampas na depekto ay tumataas nang linear sa dami ng mga pagbabago. Ikalawang panuntunan — magsimula sa arkitektura, pagkatapos lohika, pagkatapos mga detalye.

Ayon sa SmartBear, 2025, ang mga komento ay dapat na tiyak: hindi „ito ay masama", kundi „ang pamamaraang ito ay lumalabag sa SRP — ilipat ang validation logic sa isang hiwalay na klase". Bawat komento ay isang mungkahi para sa pagpapabuti, hindi kritisismo. Kung ang code ay tama ngunit ang estilo ay hindi tumutugma sa mga kagustuhan ng reviewer — iwanan nang walang komento. Dapat aprubahan ng reviewer ang tamang solusyon, kahit na siya mismo ay sumulat nito nang iba.

Paano Tumanggap ng Code Review: mga tip para sa may-akda

Pagtanggap ng Code Review — isang kasanayan na hindi gaanong mahalaga kaysa sa kakayahang suriin ang code. Ang may-akda ay dapat maging bukas sa mga komento at ituring ang mga ito bilang pagkakataon upang mapabuti ang solusyon. Unang panuntunan — huwag ituring ang mga komento bilang personal na kritisismo. Sinusuri ng Code Review ang code, hindi ang developer. Ikalawa — kung ang isang komento ay hindi malinaw, humingi ng paglilinaw, huwag agad ayusin.

Ayon sa LeadDev, 2024, bago ipadala sa pagsusuri, ang may-akda ay dapat mismo suriin ang kanyang code: patakbuhin ang mga pagsubok, dumaan sa checklist, tiyakin na walang debug logs at naka-comment na code. Ang MR/PR ay dapat maglaman ng malinaw na paglalarawan na may konteksto ng mga pagbabago. Kung mas mahusay ang paglalarawan, mas mabilis at produktibo ang pagsusuri.

Sikolohikal na kaligtasan sa Code Review

Pangunahing aspeto ng Code Review — sikolohikal na kaligtasan sa koponan. Kung ang isang developer ay natatakot makatanggap ng matalas na kritisismo o pang-iinsulto, itatago niya ang mga problema sa halip na talakayin ang mga ito. Ipinakita ng Google Project Aristotle (2017): ang mga koponan na may mataas na sikolohikal na kaligtasan ay 25% mas produktibo. Mga panuntunan: punahin ang code, hindi ang may-akda; magtanong sa halip na akusasyon; magpasalamat para sa magagandang solusyon.

Pangunahing panuntunan para sa may-akda — huwag magmadali sa pagsasara ng mga komento. Kung ang reviewer ay humiling ng mga pagbabago, dapat itong gawin, hindi sagutin ng „ok" at iwanan nang walang pagwawasto. Pagkatapos gawin ang mga pagwawasto — humiling muli ng pagsusuri. Sinusuportahan ng GitLab at GitHub ang Re-request Review para abisuhan ang reviewer.

Automation ng Code Review: linter at static na pagsusuri

Automation ng Code Review ay binabawasan ang trabaho ng mga developer sa pamamagitan ng pag-aalis ng pagsusuri ng mga pormal na panuntunan. Mga linter (ktlint, SwiftLint, ESLint) ay sumusuri ng estilo ng code, pag-format at mga pangunahing error. Mga static na analyzer (Detekt, SonarQube, Infer) ay nakakahanap ng mga potensyal na bug, memory leak at mga problema sa seguridad bago ang code ay umabot sa pagsusuri ng tao.

Ayon sa dokumentasyon ng detekt, 2024, sa CI/CD pipeline, ang mga linter at analyzer ay awtomatikong pinapatakbo kapag gumawa ng MR/PR. Kung ang pagsusuri ay hindi pumasa — ang MR ay blokeado gamit ang Merge button. Ito ay ginagarantiyahan na ang code na umaabot sa pagsusuri ng tao ay nakapasa na sa pangunahing pagsusuri. Ang reviewer ay nakatuon sa arkitektura, lohika at pagiging madaling basahin, hindi sa mga espasyo at indentation.

// Halimbawa ng configuration ng detekt para sa Android project
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

Mga Tool para sa Code Review sa mga mobile project

Mga tool sa Code Review sa mobile development ay nahahati sa platform (GitLab, GitHub, Bitbucket) at espesyalisado (Gerrit, Reviewable, Crucible). Ang GitLab at GitHub ay nagbibigay ng built-in na functionality: paghahambing ng diff, mga komento sa mga linya, Threads, mga status na Approve/Changes Requested, integration sa CI/CD. Ang pagpili ng tool ay depende sa laki ng koponan at patakaran sa pagsusuri.

Ayon sa Dokumentasyon ng GitLab, 2025, para sa malalaking koponan (50+ developers), ang Gerrit ay nagbibigay ng mas mahigpit na kontrol: sapilitang pag-verify sa pamamagitan ng CI bago ang pagsasama, may timbang na mga pag-apruba (Verified + Code-Review) at detalyadong mga karapatan sa pag-access. Para sa maliliit at katamtamang koponan, ang GitLab at GitHub ay optimal na pagpipilian: ang configuration ng Required Approvals, Code Owners at Merge Checks ay tumatagal ng ilang minuto.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, built-in na CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Pull Requests para sa Mercurial/Git, Approvals na may Diff na komento
• Gerrit — mahigpit na proseso ng pag-verify, may timbang na mga rating, Jenkins integration

Mga Karaniwang Pagkakamali sa Code Review

Mga pagkakamali sa Code Review ay nagbabawas sa bisa nito at nagde-demotivate sa koponan. Una — pagsusuri ng masyadong malaking dami ng mga pagbabago nang sabay-sabay. Kapag ang MR ay naglalaman ng 2000+ na linya, ang reviewer ay nakakaligtaan ng hanggang 70% ng mga depekto. Ikalawa — mga subjective na komento na hindi batay sa estilo ng code o arkitektura. Ang mga komentong tulad ng „susulatin ko ito nang iba" nang walang batayan ay hindi nagdudulot ng pakinabang.

Ayon sa Google Engineering Practices, 2024, ikatlong pagkakamali — pagbalewala sa mga pagsubok. Kung ang MR ay hindi may kasamang mga pagsubok para sa bagong functionality — dapat hilingin ng reviewer ang mga ito, hindi aprubahan „para sa ibang pagkakataon". Ikaapat — pagsusuri sa pagtatapos ng araw o sprint, kapag ang atensyon ay nakakalat. Pinakamahusay na oras para sa pagsusuri — unang kalahati ng araw, 30–60 minutong nakalaan nang walang paglipat sa pagitan ng mga gawain.

Seguridad ng pagsusuri — ikalimang karaniwang pagkakamali: hindi sinusuri ng mga reviewer kung mayroong mga naka-hardcode na sikreto, hindi saradong WebView na may JavaScript, mga kahinaan sa mga library sa code. Sa mga mobile project ito ay kritikal: ang pagtagas ng API key ay maaaring humantong sa kompromiso ng buong backend.

Code Review sa mga distributed na koponan

Para sa mga malalayong koponan, ang Code Review ay pangunahing channel ng paglilipat ng kaalaman. Inirerekomenda ang asynchronous na format sa pamamagitan ng MR na may malinaw na mga deadline: maximum na 24 oras para sa pagsusuri. Gumamit ng mga screen recording (Loom) para sa mga kumplikadong talakayan sa arkitektura. Sa mga distributed na koponan, ang nakasulat na pagtatala ng mga desisyon sa mga komento ng MR ay lalong mahalaga upang hindi mawala ang konteksto kapag nagbabago ang time zone.