Code Review — суштина, правила и како спроводити преглед у тиму

Шта је Code Review?

Code Review — процес провере изворног кода од стране једног или више програмера пре његове интеграције у главну грану пројекта. Циљ прегледа није само проналажење грешака, већ и побољшање архитектуре, усклађеност са стандардима тима и ширење знања. За разлику од аутоматске анализе (линтера), код-ревју се изводи од стране човека и оцењује читљивост, логику и архитектонска решења.

Према Google Engineering Practices, 2024, Code Review се дели на два равноправна циља: заштита кôд базе од дефеката и обука програмера кроз повратну информацију. У мобилним пројектима преглед обавезно укључује проверу фрејмворка (UIKit, SwiftUI, Jetpack Compose), управљања меморијом и рада са мрежним захтевима.

Code Review у GitLab-у и GitHub-у организован је кроз Merge Request и Pull Request. Сваки MR/PR садржи diff, коментаре на линије, дискусије и статусе провера. Према истраживању Microsoft Research (2023), тимови који практикују редовни преглед испоручују 40% мање критичних багова у продукцију.

Историја Code Review: од формалних инспекција до асинхроних PR-ова

Први формални Code Review појавили су се у IBM-у 1970-их као „структурисане инспекције" са корак-по-корак контролним листама и протоколом. 2000-их са ширењем Git-а и дистрибуираних тимова, преглед је еволуирао у асинхрони формат кроз Pull Request. GitHub (2008) је учинио PR масовном појавом. Савремени Code Review је неформалан, асинхрон процес са акцентом на брзину и учење, а не на бирократију.

Типови Code Review: формални и неформални приступи

Code Review класификује се на четири основна типа у зависности од процеса и укључености учесника. Формални (Asynchronous Review) — провера кроз MR/PR без синхроне комуникације, најзаступљенији у дистрибуираним тимовима. Неформални — quick CR, када један програмер приђе другом и затражи да погледа код за 5 минута.

Према Microsoft Research, 2023, програмирање у пару (Pair Programming) — два програмера раде за једним екраном, сваки кôд се пише у реалном времену са ревизијом „у ходу". Over-the-shoulder — један програмер гледа у екран другог и коментарише кôд без формалног процеса. Walkthrough — аутор кôда води групу програмера кроз измене, објашњавајући сваку одлуку.

Контролна листа Code Review: шта проверавати у коду

Контролна листа Code Review помаже рецензенту да не пропусти критично важне аспекте. Прва категорија — исправност и архитектура: да ли решење одговара постављеном задатку, да ли постоји прекомерна сложеност, да ли су обрасци (MVP, MVVM, Clean Architecture) правилно изабрани. Друга категорија — стил и форматирање: да ли се поштује код-стајл тима (Kotlin Code Style, Swift Style Guide).

Према Thoughtbot Code Review Guide, 2024, трећи блок — тестирање: да ли су написани јединични тестови, да ли покривају граничне случајеве, да ли нису покварили постојеће тестове. Четврти — безбедност: да ли постоје хардкодовани токени, API кључеви, SQL ињекције, цурења меморије. Пети — перформансе: да ли су корутине/RxJava правилно коришћене, да ли постоји блокирање UI нити, прекомерне алокације.

• Логика — исправност алгоритма, обрада граничних случајева и грешака
• Архитектура — поштовање Clean Architecture, MVVM, раздвајање одговорности
• Код-стајл — именовање, форматирање, конзистентност са пројектом
• Тестови — постојање јединичних тестова, њихова потпуност и зелени статус

Како спроводити Code Review: правила за рецензента

Code Review захтева од рецензента равнотежу између темељитости и брзине. Главно правило — проверавати кôд у малим порцијама. Оптимални обим — 200–400 линија измена у једној сесији. Према Google Research (2022), преглед преко 500 линија губи ефикасност: број пропуштених дефеката расте линеарно са обимом измена. Друго правило — почети од архитектуре, затим логика, па детаљи.

Према SmartBear, 2025, коментари треба да буду конкретни: не „ово је лоше", већ „овaj метод крши SRP — извади логику валидације у посебну класу". Сваки коментар је предлог за побољшање, а не критика. Ако је кôд исправан, али стил не одговара преференцама рецензента — оставити без коментара. Рецензент треба да одобри исправно решење, чак и ако би сам написао другачије.

Како примати Code Review: савети за аутора

Примање Code Review — вештина није мање важна од способности провере кôда. Аутор треба да приступи примедбама отворено и да их сматра приликом за побољшање решења. Прво правило — не доживљавати коментаре као личну критику. Code Review проверава кôд, а не програмера. Друго — ако је коментар нејасан, затражити појашњење, а не одмах исправљати.

Према LeadDev, 2024, пре слања на преглед, аутор је дужан да сам провери свој кôд: покрене тестове, прође кроз контролну листу, увери се да нема дебаг логова и закоментарисаног кôда. MR/PR треба да садржи разумљив опис са контекстом измена. Што је опис квалитетнији, то ће преглед бити бржи и продуктивнији.

Психолошка безбедност у Code Review

Кључни аспект Code Review — психолошка безбедност у тиму. Ако се програмер плаши оштре критике или исмевања, скриваће проблеме уместо да их дискутује. Google Project Aristotle (2017) показао је: тимови са високом психолошком безбедношћу су 25% продуктивнији. Правила: критикуј кôд, а не аутора; постављај питања уместо оптужби; захвали за добра решења.

Кључно правило за аутора — не журити са затварањем коментара. Ако је рецензент затражио измене, one морају бити унете, а не одговорити „ок" и оставити без исправке. Након уношења измена — поново затражити ревизију. GitLab и GitHub подржавају Re-request Review за обавештавање рецензента.

Аутоматизација Code Review: линтери и статичка анализа

Аутоматизација Code Review смањује оптерећење програмера, уклањајући проверу формалних правила. Линтери (ktlint, SwiftLint, ESLint) проверавају код-стајл, форматирање и основне грешке. Статички анализатори (Detekt, SonarQube, Infer) проналазе потенцијалне багове, цурења меморије и безбедносне проблеме пре него што кôд стигне на ревизију човека.

Према detekt Documentation, 2024, у CI/CD цевоводу линтери и анализатори се покрећу аутоматски приликом креирања MR/PR. Ако провера не прође — MR се блокира дугметом Merge. Ово гарантује да на ревизију човека стиже кôд који је већ прошао основну проверу. Рецензент се фокусира на архитектуру, логику и читљивост, а не на размаке и увлачења.

// Пример конфигурације detekt за Android пројекат
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")
}

Алати за Code Review у мобилним пројектима

Алати за Code Review у мобилном развоју деле се на платформске (GitLab, GitHub, Bitbucket) и специјализоване (Gerrit, Reviewable, Crucible). GitLab и GitHub пружају уграђену функционалност: diff поређење, коментаре на линије, нити, статусе Approve/Changes Requested, интеграцију са CI/CD. Избор алата зависи од величине тима и политике прегледа.

Према GitLab Docs, 2025, за велике тимове (50+ програмера) Gerrit пружа строжу контролу: обавезну верификацију кроз CI пре спајања, пондерисана одобрења (Verified + Code-Review) и детаљна права приступа. За мале и средње тимове GitLab и GitHub су оптималан избор: подешавање Required Approvals, Code Owners и Merge Checks траје минуте.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, уграђени CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Pull Requests за Mercurial/Git, Approvals са Diff коментарима
• Gerrit — строги процес верификације, пондерисане оцене, Jenkins интеграција

Типичне грешке у Code Review

Грешке у Code Review смањују његову ефикасност и демотивишу тим. Прва — провера превеликог обима измена одједном. Када MR садржи 2000+ линија, рецензент пропушта до 70% дефеката. Друга — субјективне примедбе које нису засноване на код-стајлу или архитектури. Коментари попут „ја бих написао другачије" без образложења не доносе корист.

Према Google Engineering Practices, 2024, трећа грешка — игнорисање тестова. Ако MR не укључује тестове за нову функционалност — рецензент треба да их затражи, а не да одобри „за касније". Четврта — провера на крају дана или спринта, када је пажња расејана. Најбоље време за преглед — прва половина дана, издвојених 30–60 минута без пребацивања између задатака.

Безбедност прегледа — пета честа грешка: рецензенти не проверавају да ли у коду постоје хардкодоване тајне, непокривени WebView са JavaScript-ом, рањивости у библиотекама. У мобилним пројектима ово је критично: цурење API кључа може довести до компромитације целог бекенда.

Code Review у дистрибуираним тимовима

За удаљене тимове Code Review је главни канал преноса знања. Препоручује се асинхрони формат кроз MR са јасним роковима: максимално 24 сата за ревизију. Користите снимке екрана (Loom) за сложене архитектонске дискусије. У дистрибуираним тимовима посебно је важно писмено бележење одлука у коментарима MR, како се контекст не би изгубио при промени временских зона.