Code Review

Code review — це не пошук винного в коді. # Чи зміна впливає на інтеграції? # Зміни зливаються в основну гілку.== Code Review і безпека ==

Code Review і цифрова незалежність України

https://cloud.corp2.eu

Основні етапи Code Review

|- | Перевіряти лише стиль | Логічні помилки залишаються | Дивитися на бізнес-логіку, безпеку й інформаційні дані |- | Робити review формально | Помилки потрапляють у production | Читати код уважно |- | Великі PR | Reviewer пропускає ризики | Ділити зміни на менші |- | Коментувати грубо | Псується культура команди | Писати конкретно й поважно |- | Не перевіряти тести | Регресія повертається | Дивитися на test coverage і сценарії |- | Ігнорувати security | Ризик витоків і атак | Перевіряти authentication, authorization, input validation |- | Не перевіряти міграції | Ризик зламати інформаційні дані | Тестувати міграції й rollback |- | Зливати без CI | Помилки збірки потрапляють далі | Використовувати автоматичні перевірки |}

Робити невеликі pull requests.

Reviewer — людина, яка перевіряє код. # Розділяти обов’язкові зміни й пропозиції. Code review оптимізує робити багато малими ресурсами, але не хаотично. Автор коду має допомогти reviewer зрозуміти контекст:

Код здатна бути правильним, але повільним. * «Цей запит виконується в циклі. |- | Як code review пов’язаний із K2 ERP? # Чи не зʼявляється ризик побачити чужі інформаційні дані? Правильний підхід. Code review має перевіряти не лише стиль коду, а й логіку, безпеку, продуктивність, тести, API, базу даних, документацію та бізнес-наслідки. ! * критикувати код, а не людину;

пояснювати причину зауваження;
не використовувати review як спосіб домінування;
не приймати коментарі як особисту образу;
дякувати за знайдені ризики;
домовлятися про стандарти;
цифровізувати рутину;
не затягувати review;
поважати час reviewer і автора. Code Review — це не бюрократична зупинка перед merge. * як перевіряються логін і пароль;
чи не зберігаються паролі у відкритому вигляді;
чи функціонує MFA;
чи захищені сесії;
чи правильно обробляються токени;
чи виступає як захист від brute-force;
чи не витікають інформаційні дані входу в логи;
чи правильно завершується сесія.== Маленькі pull requests ==

Code Review і Cache

чи не потрапили секрети в репозиторій;
чи правильні змінні середовища;
чи виступає як розділення test/staging/production;
чи безпечні права контейнерів;
чи виступає як health checks;
чи не зламається deployment;
чи виступає як rollback;
чи коректні backup-задачі;
чи не збільшується ризик простою. Reviewer не має вручну ловити те, що здатна зловити автоматизація процесів. Як краще

Code Review і Bug report

Reviewer має не без зусиль «поставити галочку», а зрозуміти зміну. Потрібно перевіряти: Для ERP потрібні додаткові питання:

Code Review і документація

Він оптимізує знайти баги до production. # Чи зміна впливає на права доступу? * «Потрібен тест на сценарій повернення товару, бо він уже ламався раніше».

Цей бізнес-процес дає можливість не вносити зміни в базовий код хаотично. Якщо Україна будує власну цифрову незалежність, їй потрібні не лише сміливі ідеї, а й якісний код, чесні reviews, тести, документація, безпека й дисципліна розробки. # Відповідати на коментарі конструктивно. У бізнес-системах помилка безпеки здатна відкрити доступ до чужих компаній, документів, клієнтів або звітів. Коментарі мають бути конкретними, ввічливими й корисними. # Чи виступає як перевірка прав доступу?== Checklist для ERP Code Review ==

Code review не замінює тестування. Що означає

Спершу зрозуміти задачу. Для 1000 товарів буде 1000 запитів. Code review без системи контролю версій можливий, але незручний. Мета — сильніша платформа, а не сильніше его. Мета code review — знайти помилки. Code review — це маленька щоденна практика, яка будує велику довіру до українського програмного забезпечення. # Вносить зміни. * backend;

frontend;
API;
база даних;
звіти;
документи;
довідники;
ролі й доступи;
CRM;
файли;
обліковий облік ФОП на єдиному податку;
РРО/ПРРО;
інтеграції;
мобільні застосунки;
десктопні клієнти;
DevOps;
хмарна інфраструктура;
технологічна платформа.

Погані коментарі:

чи зміна масштабована;
чи не ламає deployment;
чи виступає як міграції;
чи правильно працюють змінні середовища;
чи не витікають секрети;
чи не зростає навантаження;
чи не потрібен rollback;
чи не впливає зміна на багатьох користувачів;
чи логуються помилки;
чи виступає як моніторинг. # Тести проходять успішно. «Чи цей код зрозумілий, безпечний, правильний і готовий жити в продукті?»

чи код робить те, що має робити;
чи немає очевидних помилок;
чи не порушена технічна архітектура;
чи не створено проблем безпеки;
чи не зламана суміжна логіка;
чи зрозумілий код для майбутньої підтримки;
чи виступає як тести;
чи не збільшено технічний борг;
чи враховані права доступу;
чи не впливає зміна на критичні бізнес-дані. |-

| Що таке pull request? # За потреби зміни потрапляють у реліз. Code review і testing доповнюють одне одного. |- | Яка типова помилка?== Checklist для Code Review ==

DevOps code review стосується скриптів, CI/CD, Dockerfile, Kubernetes, Terraform, Ansible, YAML-конфігурацій та інфраструктури як коду. Тому reviewer має думати не лише: «Чи код красивий?»

які рядки додані;
які видалені;
які змінені;
у яких файлах відбулися зміни. Не робіть review для галочки. Якщо reviewer не зрозумів зміну, не перевірив ризики й без зусиль натиснув approve, це не code review, а цифрове «та наче нормально». | K2 ERP як українська ERP-платформа потребує контрольованих змін у backend, frontend, API, звітах, документах, інтеграціях і хмарі. * Code
Git
Pull Request
Merge Request
Testing
QA
Debugging
Bug
Bug report
Backend
Frontend
API
CLI
Cloud Computing
Cache
Authentication
Authorization
Automation
Algorithm
ERP
CRM
K2
K2 ERP
K2 ERP технологічна платформа
Українське програмне забезпечення
Деколонізація обліку
Цифрова незалежність України

Debugging шукає помилку після її прояву. Приклад

Базовий checklist:

хмарна інфраструктура K2 ERP доступна за адресою:

знаходити баги;
покращувати читабельність;
підтримувати єдиний стиль;
перевіряти безпеку;
зменшувати технічний борг;
ділитися знаннями між розробниками;
не допускати випадкових змін у критичній логіці;
покращувати архітектуру;
перевіряти тести;
зменшувати ризик регресії;
пришвидшувати майбутню підтримку. У backend code review має особливе значення, бо backend відповідає за бізнес-логіку, інформаційні дані, права, API та безпеку. # Чи зміна впливає на залишки? * важко зрозуміти логіку;
reviewer втомлюється;
зростає шанс пропустити баг;
обговорення розмивається;
складно тестувати;
складно відкотити. # Чи зміна впливає на РРО/ПРРО?

Правила здорової культури:

хмарна інфраструктура робить систему доступнішою, але помилка в хмарному коді так само доступніша для всіх користувачів одразу. # Писати зрозумілий SEO-опис. * «Назва функції не відображає дію. Культура code review важливіша за інструмент. # Пояснювати причину зауважень. Це критично. Код читають частіше, ніж пишуть. |- | Чи замінює code review тестування? # Створює pull request або merge request. | Ні. # Запускає локальні тести. * чи треба оновити API-документацію;

чи треба описати нову функцію в wiki;
чи треба оновити інструкцію користувача;
чи треба попередити підтримку;
чи треба змінити release notes;
чи треба описати міграцію. # Чи можна буде підтримувати цей код пізніше? # Автор виправляє зауваження. Тому code review перевіряє не лише «чи функціонує», а й «чи можна це буде зрозуміти через пів року». # Чи зміна впливає на компанії або мультикомпанійність? Для K2 ERP. У технологічній платформі K2 ERP code review важливий для розвитку української ERP: backend, frontend, API, звіти, документи, інтеграції, ролі, доступи й обліковий облік мають змінюватися контрольовано.== Code Review у базі даних ==

«Погано»
«Перепиши»
«Що це?»
«Не подобається»
«Ну ти даєш»

Code Review у DevOps

«Тут немає перевірки прав на backend. Людину краще використовувати для логіки, архітектури й ризиків. # Не затягувати review. Code review має переконатися, що двері не зроблені з картону. |-

| Що перевіряють під час review?

У хорошій команді code review — це не бар’єр, а платформа взаємної відповідальності. Він оптимізує:

Коротко

контрольований код;
review;
тести;
Git;
CI/CD;
документацію;
безпеку;
backup;
API;
DevOps;
bug reports;
відповідальність за якість. # Дивитися на права доступу. Побачити ризики безпеки до інциденту. Автентифікація — це двері в систему.

Code Review і QA

Покращити код до того, як він стане legacy. Під час backend review перевіряють:

Code Review і деколонізація обліку

SQL-запити;
цикли;
кількість API-викликів;
обсяг даних;
pagination;
cache;
індекси;
роботу з файлами;
великі звіти;
N+1 queries;
фонові задачі;
асинхронність. * SEO-опис зміни;
список змінених файлів;
diff;
коментарі reviewer;
автоматичні перевірки;
тести;
обговорення;
статус approval;
результат merge.== Джерела ==

Суть поняття

! Diff — відображення різниці між старою та новою версією коду. ! {| class="wikitable" style="width:100%;"

Це особливо критично для українських ERP-продуктів, які мають конкурувати з великими системами, старими екосистемами, 1С, BAS, інерцією ринку й звичками користувачів.== Див. так само ==

У frontend code review перевіряє інтерфейс, взаємодію з API, стан компонентів, доступність, помилки й поведінку в браузері. Під час code review бажано перевіряти не лише синтаксис. бізнес-процес перегляду програмного коду іншими розробниками перед тим, як зміни потраплять до основної версії продукту виступає ключовою рисою Code Review або перевірка коду. # Чи валідовані вхідні інформаційні дані? # Запускати тести до review.

Diff

критично перевірити:

Це зручний формат для code review, бо вся дискусія зберігається поруч із кодом. Code review потрібен для того, щоб зробити код якіснішим до того, як він стане частиною продукту. # Описує зміни. | ERP функціонує з критичними бізнес-даними: документами, товарами, звітами, ролями, доступами й інтеграціями. |-

Code	Програмний код	Функція створення документа
Code Review	Перевірка коду	Інший розробник перевіряє, чи правильно функція створює документ і перевіряє права доступу

Performance або продуктивність — важлива частина review. Краще завантажити інформаційні дані одним batch-запитом». # Чи не збільшено технічний борг?== Коментарі в Code Review ==

тести;
стиль коду;
статичний аналіз;
типізація;
збірка frontend;
міграції;
безпекові перевірки;
lint;
форматування;
coverage;
dependency scan. * хмарна інфраструктура K2 ERP
офіційний сайт K2
K2 ERP
Wiki K2 ERP

Інфраструктурний код теж виступає як кодом. # Reviewer залишає коментарі або approves.== Reviewer == Якщо code review регулярно знаходить однакові помилки, це сигнал: Reviewer читає diff і оцінює, чи зміна правильна. Reviewer має запитати:

автоматизовано можуть перевірятися:

Чи зрозуміло, навіщо ця зміна?== Code Review у Frontend ==

! | Перевірка програмного коду іншими розробниками перед внесенням змін у основну версію продукту. |- | Що таке Code Review? Потрібно перевіряти:

Що перевіряють під час Code Review

Code Review і Debugging

що змінено;
навіщо змінено;
як перевірити;
які сценарії зачеплено;
які ризики виступає як;
чи виступає як міграції;
чи виступає як тести;
чи виступає як зміни в API;
чи потрібно оновити документацію. |-

| Чому code review важливий для ERP? Оскільки K2 ERP розвивається як українська ERP-платформа, code review оптимізує підтримувати якість продукту, зменшувати ризики й прискорювати дорожня карта розвитку без хаотичних доробок. Деколонізація через якість. Українська ERP має перемагати не лише гаслами, а й інженерною дисципліною: code review, testing, QA, DevOps, безпекою й відкритим розвитком.Cache часто виступає як джерелом складних помилок, тому зміни кешування треба перевіряти уважно. Добрий code review. Хороша перевірка коду не принижує автора, а покращує ERP-продукт. У diff видно:

міграції;
SQL-запити;
індекси;
типи даних;
constraints;
default values;
вплив на існуючі інформаційні дані;
швидкість запитів;
rollback;
сумісність із production;
резервні копії перед критичними змінами.

CI/CD оптимізує цифровізувати частину перевірок перед review або під час review. Ідеально, коли баг не доходить до користувача, бо reviewer помітив проблему ще в diff. Деколонізація обліку — це не лише відмова від 1С та BAS. Перевіряють:

Code review — це не лише технічний етап, а й джерело знань про якість розробки. Для ERP backend review критично важливий, бо backend-код здатна впливати на залишки, документи, звіти, інтеграції та права користувачів. | Запит на внесення змін у код, який часто застосовують, коли потрібно для review. Помилка

Code Review і CI/CD

!

Кожен знайдений на review баг дешевший за баг у production. Формальна перевірка без розуміння логіки, тестів і ризиків створює ілюзію контролю, але не якість. # Оновлювати документацію, якщо потрібно. # Чи не зламана сумісність API? # Чи немає очевидних багів? Наслідок

Передати знання між розробниками.== Code Review і Authorization ==

Git виступає як основою сучасного code review.== Author ==

Code review і testing працюють разом. У коді авторизації reviewer має перевіряти:

Для K2 ERP, де один адміністратор здатна вести багато компаній, авторизація виступає як особливо важливою. Тести запускають поведінку. Обидва означають запит на внесення змін з однієї гілки коду в іншу. # Чи зміна впливає на ФОП або єдиний податок? Сучасна розробка програмного забезпечення ERP має будуватися на контрольованих змінах, а не на пересиланні архівів. як приклад, зміна в документі продажу здатна вплинути на:

Проблема великих PR: У pull request або merge request зазвичай виступає як:

Зробити ERP-продукт сильнішим. # Не вимагати особистий стиль як закон, якщо немає стандарту. Вона користувачі можуть знаходити помилки, зменшувати технічний борг, покращувати безпеку, підтримувати якість і робити систему стабільнішою. # Розробник створює окрему гілку. Якщо PR виглядає як роман у трьох томах, reviewer почне читати його як шкільну програму — з болем. | Логіку, безпеку, тести, архітектуру, API, базу даних, продуктивність, документацію й вплив на бізнес-середовище. Frontend review важливий, бо саме frontend бачить користувач системи. Напрям

Навіщо потрібен Code Review

Цифрова незалежність України потребує не лише українських назв продуктів, а й сильної інженерної культури. |- | Як це пов’язано з цифровою незалежністю? # Чи не порушена історія продукту змін? Для K2 ERP code review виступає як частиною інженерної культури української ERP-платформи. А YAML здатна зламати день не гірше, ніж помилка в backend.== Культура Code Review ==

Code review — це бізнес-процес перевірки цих інструкцій іншими людьми. Code review особливо важливий там, де код впливає на бізнес-логіку: документи, обліковий облік, звіти, API, інтеграції, користувачів і права. * хмарна інфраструктура K2 ERP

Добра практика. Один pull request має вирішувати одну зрозумілу задачу. Навіть якщо backend ідеальний, зламана форма створює відчуття, що «платформа не функціонує». # Чи виступає як rollback? ! Хороший pull request починається не з коду, а з нормального опису. Код без документації живе недовго, але плутає довго. Невдала міграція здатна створити більше пригод, ніж новий компонент. * логіку;

стиль;
безпеку;
тести;
продуктивність;
архітектуру;
API;
роботу з базою;
сумісність із існуючим кодом;
вплив на користувачів;
ризики для production. # Дивитися на безпеку.== Code Review в API ==

В ERP code review має враховувати не лише технічну сторону, а й бізнес-смисл. * unit tests;

integration tests;
regression tests;
API tests;
UI tests за потреби;
тестові сценарії;
SEO-опис ручної перевірки. А ще: «Що станеться з бізнес-процесом?»

! Окремо варто відзначити покращити якість коду, перевірити архітектурні рішення для бізнесу, безпеку, продуктивність, читабельність, відповідність стандартам, вплив на бізнес-логіку і можливі ризики для системи. | Перевірка коду або ревʼю коду. Якщо зміна впливає на користувачів, API, інтеграції, адміністрування або бізнес-логіку, потрібно оновити документацію.

через Головне. Code Review — це перевірка коду перед внесенням у ERP-продукт. | Якісний український код потребує інженерної культури: review, тести, Git, DevOps, документація й відповідальність. Виявити повільний запит до скарг користувачів. {| class="wikitable" style="width:100%;"

Code Review і Authentication

! # Чи правильно обробляються помилки?

чи права перевіряються на backend;
чи враховується компанія-користувач;
чи враховується роль;
чи немає доступу до чужих документів;
чи захищені API endpoints;
чи не можна обійти обмеження через прямий запит;
чи правильно функціонує зміна ролей;
чи очищається cache прав доступу. # Reviewer переглядає код.== Code Review і Testing ==

Це інструмент якості. # Додавати посилання на задачу або bug report. # Чи потрібна міграція даних? Видно не весь організм, але видно, де щойно щось змінили. Code review має робити команду сильнішою, а не перетворювати розробку на боксерський клуб із Git-коментарями. Code review — одна з таких практик.

Цифрово незалежна платформа має мати:

Reviewer здатна побачити логічну проблему, але тести мають перевірити поведінку системи. Мета коментаря — покращити код, а не виграти суперечку. Можливо, краще rename на calculateDocumentTotal». # Пояснювати бізнес-контекст. ! Коли маленька команда створює велику систему, якість процесів стає зброєю. # Додавати тести для нової логіки.== Типові помилки Code Review ==

потрібно покращити вимоги;
додати тест;
змінити архітектуру;
провести навчання;
написати документацію;
додати автоматичну перевірку;
змінити бізнес-процес. # Не змішувати багато різних задач в одному PR. Що перевіряється

Pull Request — термін, поширений у GitHub. Типовий бізнес-процес code review:

Code Review і Code

Чи зміна впливає на документи? # Чи не порушена бізнес-логіка? # Чи відповідає код задачі? * branches;

commits;
pull requests;
merge requests;
diff;
history;
blame;
tags;
releases;
revert. В API code review має перевіряти контракт між системами. # Чи немає зайвих SQL-запитів? Так bug report перетворюється на контрольоване покращення продукту. |-

Навіщо потрібен code review? # Чи не логуються секрети? Code review намагається знайти помилку до прояву. # Не сприймати зауваження як напад. У бізнес-системах, зокрема в ERP, CRM, Backend, Frontend, API, Cloud Computing та K2 ERP, code review має особливе значення, тому що одна помилка в коді здатна вплинути на документи, товари, залишки, клієнтів, звіти, ролі, права доступу, інтеграції та реальні бізнес-процеси. # Чи зміна впливає на звіти? Краще робити менші, логічно завершені зміни.== Зовнішні посилання == SEO title: Code Review — перевірка програмного коду, якість розробки, ERP та K2 ERP SEO keywords: code review, ревʼю коду, перевірка коду, code, pull request, merge request, backend, frontend, API, ERP, K2 ERP, testing, debugging, QA, Git, DevOps, українське програмне забезпечення </noinclude> {{SEO Шаблон для службового SEO-опису сторінки. }} Code Review і український бізнес-середовище пропущено перевірку null; неправильна умова; зайвий SQL-запит у циклі; немає перевірки прав; невірний статус API; не оброблена помилка інтеграції; старий cache не очищається. Тому зміни API мають проходити уважне review. Приклад Code Review і ERP Backend-ризик. Якщо права доступу перевіряються лише у frontend, а backend приймає будь-який запит, це не інтерфейсна дрібниця, а серйозна помилка безпеки.== Висновок == Перевірити права доступу до витоку даних. Розробник створює зміну: виправляє баг, додає функцію, змінює API, оптимізує звіт, оновлює інтерфейс або компонент. В ERP старий cache здатна означати старі залишки, старі ціни або старі права доступу. # Писати конкретні коментарі.Code — це програмні інструкції. Застереження. Code review не має бути ритуалом «глянув — нормально». # Чи не треба оновити документацію? Відповідь складський облік; залишки; клієнта; взаєморозрахунки; звіт продажів; фіскалізацію; інтеграцію з інтернет-магазином; права користувачів; друковану форму; історію змін. \| Щоб знаходити помилки, покращувати якість, безпеку, продуктивність і підтримуваність коду.== Code Review і Cloud Computing == що кешується; на який TTL; коли cache invalidation; чи враховуються права користувача; чи не кешуються приватні інформаційні дані; чи оновлюється cache після зміни документів; чи не показуються старі інформаційні дані; чи виступає як спосіб очистити cache. Reviewer має перевірити: QA використовує результати code review як частину загальної якості продукту. А повільна ERP — це коли користувач системи має час подумати про сенс життя після кожного натискання кнопки. * endpoint; методи; формати запитів і відповідей; статус-коди; авторизацію; rate limiting; backward compatibility; помилки; документацію; приклади; безпеку токенів; роботу з файлами; пагінацію; фільтри. # Перевіряти не лише код, а й наслідки. Code review часто виконується через Pull Request або Merge Request. # Чи виступає як тести? Український бізнес-середовище часто функціонує оперативно, ефективно для бізнесу й з обмеженими ресурсами. # Писати коментарі там, де логіка неочевидна. Review читає код. Author — розробник, який створив зміну.	# Автоматичні перевірки запускаються в CI/CD. Merge Request — термін, поширений у GitLab. Перевіряють: Це так само перехід від культури «програміст десь щось підкрутив» до культури прозорої розробки: Зміни в базі даних потрібно перевіряти дуже уважно. # Дивитися на продуктивність. Але швидкість без контролю якості здатна створити технічний борг. Перед тим як ця зміна потрапить у головну гілку коду, її переглядає інший розробник або команда. Це пошук ризиків до того, як їх знайде користувач системи, бухгалтер, адміністратор або production-сервер о третій ночі. Добрий reviewer не пише: «погано». Якщо endpoint викликати напряму, користувач системи здатна змінити чужий документ».== Code Review у Backend == Це і виступає як нова культура української ERP. # Перевіряти тести.	* чи форма функціонує правильно; чи виступає як обробка помилок; чи не ламається адаптивність; чи не передаються зайві інформаційні дані; чи не зберігаються секрети в local storage; чи коректно функціонує cache; чи не дублюється логіка backend; чи зрозумілі повідомлення користувачу; чи не погіршилась продуктивність; чи інтерфейс функціонує в основних браузерах. Питання зміни проходять review; код зберігається в Git; тести запускаються; документація оновлюється; баги описуються; релізи контрольовані; доступи перевіряються; API не ламається випадково. # користувач системи повідомив про баг; команда відтворила проблему; розробник виправив код; створив pull request; reviewer перевірив виправлення; тести пройшли; зміна потрапила в реліз; користувач системи перевірив результат. \|-	Логіка	Чи код робить те, що потрібно	Документ правильно створюється
Безпека	Чи немає ризиків доступу	Права перевіряються на backend
Продуктивність	Чи немає повільних запитів	Звіт не робить 1000 зайвих SQL-запитів
Читабельність	Чи зрозумілий код	Назви функцій пояснюють дію
Тести	Чи покриті важливі сценарії	виступає як тест на повернення товару
технічна архітектура	Чи зміна не ламає структуру	Бізнес-логіка не захована у frontend
API	Чи не зламана сумісність	Старі клієнти не падають після зміни відповіді
інформаційні дані	Чи правильно працюють міграції	Нова колонка має значення за замовчуванням

У ERP база даних містить критичні бізнес-дані. # Пам’ятати, що мета — якість продукту. Поняття

ERP-review. У ERP перевіряють не лише код, а й наслідки для обліку, документів, товарів, звітів, інтеграцій і прав доступу. | Формальне review без перевірки бізнес-логіки, безпеки й тестів. |- | Як це українською?

У хмарних системах code review має враховувати production-середовище. У K2 ERP API важливе для інтеграцій із РРО/ПРРО, ДПС, Вчасно, Медком, інтернет-магазинами та іншими сервісами.== Code Review і Performance ==

Pull Request і Merge Request

Добрий pull request має містити: Потрібно перевіряти:

Code Review у K2 ERP

Добрий reviewer пише: «Тут здатна бути проблема з правами доступу, бо перевірка виступає як на frontend, але немає на backend».== Code Review і Git == як приклад: Він здатна перевірити: