Code Review
Merge Request — термін, поширений у GitLab.; Це інструмент якості.; Відповідь
- як перевіряються логін і пароль;
- чи не зберігаються паролі у відкритому вигляді;
- чи функціонує MFA;
- чи захищені сесії;
- чи правильно обробляються токени;
- чи є собою захист від brute-force;
- чи не витікають інформаційні дані входу в логи;
- чи правильно завершується сесія.;Debugging шукає помилку після її прояву.; Добра практика. Один pull request має вирішувати одну зрозумілу задачу.; Якщо Україна будує власну цифрову незалежність, їй потрібні не лише сміливі ідеї, а й якісний код, чесні reviews, тести, документація, безпека й дисципліна розробки.;
Правила здорової культури:
Reviewer
Code Review в API
Суть поняття
як ілюстрація, зміна в документі продажу має змогу вплинути на:
У хмарних системах code review має враховувати production-середовище.; Code review — одна з таких практик.; Цифрово незалежна платформа має мати:
Добрий reviewer не пише: «погано».;== Рекомендації для автора коду ==
Цей бізнес-процес надає можливість не вносити зміни в ключовий код хаотично.; Формальна перевірка без розуміння логіки, тестів і ризиків створює ілюзію контролю, але не якість.; # Писати конкретні коментарі.; Видно не весь організм, але видно, де щойно щось змінили.; * unit tests;
- integration tests;
- regression tests;
- API tests;
- UI tests за потреби;
- тестові сценарії;
- характеристика ручної перевірки.; | Перевірка коду або ревʼю коду.; # Чи не зламана сумісність API?;== Author ==
У K2 ERP code review має змогу стосуватися різних частин системи:
- знаходити баги;
- покращувати читабельність;
- підтримувати єдиний стиль;
- перевіряти безпеку;
- зменшувати технічний борг;
- ділитися знаннями між розробниками;
- не допускати випадкових змін у критичній логіці;
- покращувати архітектуру;
- перевіряти тести;
- зменшувати ризик регресії;
- пришвидшувати майбутню підтримку.; Що означає
Reviewer — людина, яка перевіряє код.; Невдала міграція має змогу створити більше пригод, ніж новий компонент.; # Відповідати на коментарі конструктивно.; # Створює pull request або merge request.; * «Цей запит виконується в циклі.; Людину краще використовувати для логіки, архітектури й ризиків.;
Добрий code review. Хороша перевірка коду не принижує автора, а покращує програмний продукт.; !;У хорошій команді code review — це не бар’єр, а платформа взаємної відповідальності.;== Code Review і QA ==
ERP-review. У ERP перевіряють не лише код, а й наслідки для обліку, документів, товарів, звітів, інтеграцій і прав доступу.; * «Назва функції не відображає дію.;== Code Review і Performance ==
Code Review і Authorization
Cache часто є собою джерелом складних помилок, з цієї причини зміни кешування треба перевіряти уважно.; !; |-
| Чому code review важливий для ERP?; Наслідок
Для ERP backend review критично важливий, бо backend-код має змогу впливати на залишки, документи, звіти, інтеграції та права користувачів.; * backend;
|
Що таке pull request?; # Пояснювати причину зауважень.;
Він сприяє: Code Review і документація
Code Review і Git
Інфраструктурний код теж є собою кодом.; Перевірити права доступу до витоку даних.; # Чи зміна впливає на звіти?; |- |
Яка типова помилка?; * зміни проходять review;
розвитку української ERP: backend забезпечується через Для K2 ERP. У технологічній платформі K2 ERP code review важливий; додатково реалізовано frontend, API, звіти, документи, інтеграції, ролі, доступи й обліковий облік мають змінюватися контрольовано.;
Code Review і цифрова незалежність УкраїниТиповий бізнес-процес code review: Перевіряють: |
;== Коментарі в Code Review ==
Коментарі мають бути конкретними, ввічливими й корисними.; Code review — це не лише технічний етап, а й джерело знань про якість розробки.; # Не затягувати review.; завдяки наявності Головне. Code Review — це перевірка коду перед внесенням у програмний продукт.; Frontend review важливий, бо саме frontend бачить користувач системи.; * логіку;
|
Code | Програмний код | Функція створення документа |
|---|---|---|---|---|---|---|
| Code Review | Перевірка коду | Інший розробник перевіряє, чи правильно функція створює документ і перевіряє права доступу |
Reviewer має змогу побачити логічну проблему, але тести мають перевірити поведінку системи.; Diff — це як рентген для коду.; Performance або продуктивність — важлива частина review.;== Checklist для Code Review ==
Маленькі pull requests
Git є собою основою сучасного code review.; # Чи відповідає код задачі?; # Зміни зливаються в основну гілку.;Bug report часто приводить до зміни коду, а зміна коду має пройти review.; # Перевіряти тести.; В API code review має перевіряти контракт між системами.;== Що перевіряють під час Code Review ==
У K2 ERP API важливе для інтеграцій із РРО/ПРРО, ДПС, Вчасно, Медком, інтернет-магазинами та іншими сервісами.;Базовий checklist: Code review — це бізнес-процес перевірки цих інструкцій іншими людьми.; Вона користувачі можуть знаходити помилки, зменшувати технічний борг, покращувати безпеку, підтримувати якість і робити систему стабільнішою.; Обидва означають запит на внесення змін з однієї гілки коду в іншу.; | ERP функціонує з критичними бізнес-даними: документами, товарами, звітами, ролями, доступами й інтеграціями.; * чи зміна масштабована;
- чи не ламає deployment;
- чи є собою міграції;
- чи правильно працюють змінні середовища;
- чи не витікають секрети;
- чи не зростає навантаження;
- чи не потрібен rollback;
- чи не впливає зміна на багатьох користувачів;
- чи логуються помилки;
- чи є собою моніторинг.; Код без документації живе недовго, але плутає довго.; | Перевірка програмного коду іншими розробниками перед внесенням змін у основну версію продукту.; !; * міграції;
- SQL-запити;
- індекси;
- типи даних;
- constraints;
- default values;
- вплив на існуючі інформаційні дані;
- швидкість запитів;
- rollback;
- сумісність із production;
- резервні копії перед критичними змінами.; Code review — це маленька щоденна практика, яка будує велику довіру до українського програмного забезпечення.; з цієї причини зміни API мають проходити уважне review.; !; # Чи не збільшено технічний борг?; # Чи не порушена історичний розвиток змін?;
Виявити повільний запит до скарг користувачів.;== Джерела ==
Reviewer читає diff і оцінює, чи зміна правильна.; * складський облік;
- залишки;
- клієнта;
- взаєморозрахунки;
- звіт продажів;
- фіскалізацію;
- інтеграцію з інтернет-магазином;
- права користувачів;
- друковану форму;
- історію змін.; # Дивитися на продуктивність.; # Чи валідовані вхідні інформаційні дані?;
Code Review і CI/CD
Застереження. Code review не має бути ритуалом «глянув — нормально».;== Code Review і Debugging ==
Зміни в базі даних потрібно перевіряти дуже уважно.; # Оновлювати документацію, якщо потрібно.;== Висновок ==
- Чи зміна впливає на документи?; Приклад
Добрий reviewer пише: «Тут має змогу бути проблема з правами доступу, бо перевірка є собою на frontend, але немає на backend».; # Reviewer переглядає код.; # Чи зміна впливає на компанії або мультикомпанійність?; У бізнес-системах помилка безпеки має змогу відкрити доступ до чужих компаній, документів, клієнтів або звітів.;== Типові помилки Code Review ==
Якщо зміна впливає на користувачів, API, інтеграції, адміністрування або бізнес-логіку, потрібно оновити документацію.; Під час backend review перевіряють:
Культура code review важливіша за інструмент.; | Ні.; DevOps code review стосується скриптів, CI/CD, Dockerfile, Kubernetes, Terraform, Ansible, YAML-конфігурацій та інфраструктури як коду.; | Запит на внесення змін у код, який часто застосовують, коли потрібно для review.; Хороший pull request починається не з коду, а з нормального опису.;== Code Review і деколонізація обліку ==- чи код робить те, що має робити;
- чи немає очевидних помилок;
- чи не порушена технічна архітектура;
- чи не створено проблем безпеки;
- чи не зламана суміжна логіка;
- чи зрозумілий код для майбутньої підтримки;
- чи є собою тести;
- чи не збільшено технічний борг;
- чи враховані права доступу;
- чи не впливає зміна на критичні бізнес-дані.; У коді автентифікації reviewer має перевіряти:
Під час code review бажано перевіряти не лише синтаксис.; # Дивитися на права доступу.; Мета коментаря — покращити код, а не виграти суперечку.; Зробити програмний продукт сильнішим.; Так bug report перетворюється на контрольоване покращення продукту.;Code — це програмні інструкції.; Краще завантажити інформаційні дані одним batch-запитом».; |}
Навіщо потрібен Code Review
У frontend code review перевіряє інтерфейс, взаємодію з API, стан компонентів, доступність, помилки й поведінку в браузері.; Навіть якщо backend ідеальний, зламана форма створює відчуття, що «платформа не функціонує».; Поняття Для K2 ERP code review є собою частиною інженерної культури української ERP-платформи.; # Перевіряти не лише код, а й наслідки.; Приклад Передати знання між розробниками.; # Чи зміна впливає на залишки?; * чи не потрапили секрети в репозиторій;
- чи правильні змінні середовища;
- чи є собою розділення test/staging/production;
- чи безпечні права контейнерів;
- чи є собою health checks;
- чи не зламається deployment;
- чи є собою rollback;
- чи коректні backup-задачі;
- чи не збільшується ризик простою.; Code review сприяє робити багато малими ресурсами, але не хаотично.; # Автоматичні перевірки запускаються в CI/CD.; Code review — це не пошук винного в коді.; {| class="wikitable" style="width:100%;"
Code Review у DevOps
Коли маленька команда створює велику систему, якість процесів стає зброєю.; # Не змішувати багато різних задач в одному PR.; У бізнес-системах, зокрема в ERP, CRM, Backend, Frontend, API, Cloud Computing та K2 ERP, code review має особливе значення, з цієї причини що одна помилка в коді має змогу вплинути на документи, товари, залишки, клієнтів, звіти, ролі, права доступу, інтеграції та реальні бізнес-процеси.;== Коротко ==
| ; Diff — відображення різниці між старою та новою версією коду.; Для 1000 товарів буде 1000 запитів.; Code review не замінює тестування.; А повільна ERP — це коли користувач системи має час подумати про сенс життя після кожного натискання кнопки.; Code review особливо важливий там, де код впливає на бізнес-логіку: документи, обліковий облік, звіти, API, інтеграції, користувачів і права.;== Code Review у Backend ==
«Чи цей код зрозумілий, безпечний, правильний і готовий жити в продукті?» Code review часто виконується через Pull Request або Merge Request.; Потрібно перевіряти: Основні етапи Code ReviewУ pull request або merge request зазвичай є собою: Код має змогу бути правильним, але повільним.; # Чи не треба оновити документацію?; Як краще як ілюстрація:
|
; Він має змогу перевірити:
Побачити ризики безпеки до інциденту.; * що змінено;
Деколонізація через якість. Українська ERP має перемагати не лише гаслами, а й інженерною дисципліною: code review, testing, QA, DevOps, безпекою й відкритим розвитком.; У ERP база даних містить критичні бізнес-дані.; Через Git працюють: Під час review перевіряють:
|
; з цієї причини reviewer має думати не лише: «Чи код красивий?»
Правильний підхід. Code review має перевіряти не лише стиль коду, а й логіку, безпеку, продуктивність, тести, API, базу даних, документацію та бізнес-наслідки.; * що кешується;
Якщо code review регулярно знаходить однакові помилки, це сигнал:
Для ERP потрібні додаткові питання: Добрий pull request має містити: А ще: «Що станеться з бізнес-процесом?» хмарна інфраструктура робить систему доступнішою, але помилка в хмарному коді додатково доступніша для всіх користувачів одразу.;== Code Review і український бізнес-середовище == |
; Напрям
Code review намагається знайти помилку до прояву.; # Запускати тести до review.; # Чи немає зайвих SQL-запитів?; Сучасна розробка програмного забезпечення ERP має будуватися на контрольованих змінах, а не на пересиланні архівів.; |- |
- | Що таке Code Review?; # Чи можна буде підтримувати цей код пізніше?;Цифрова незалежність України потребує не лише українських назв продуктів, а й сильної інженерної культури.;
Потрібно перевіряти: |
- | Як це українською?; # Чи зміна впливає на ФОП або єдиний податок?;
Покращити код до того, як він стане legacy.; Backend-ризик. Якщо права доступу перевіряються лише у frontend, а backend приймає будь-який запит, це не інтерфейсна дрібниця, а серйозна помилка безпеки.; # Чи не зʼявляється ризик побачити чужі інформаційні дані?; Це особливо істотно для українських ERP-продуктів, які мають конкурувати з великими системами, старими екосистемами, 1С, BAS, інерцією ринку й звичками користувачів.; Код читають частіше, ніж пишуть.; # Дивитися на безпеку.; https://cloud.corp2.eu Рекомендації для reviewerCI/CD сприяє автоматизувати частину перевірок перед review або під час review.; Це критично.; |- |
Як code review пов’язаний із K2 ERP?;== Checklist для ERP Code Review ==
Проблема великих PR:
істотно перевірити: Pull Request і Merge RequestУ коді авторизації reviewer має перевіряти: Code Review і безпекаQA використовує результати code review як частину загальної якості продукту.; хмарна інфраструктура K2 ERP доступна за адресою: Культура Code ReviewУ diff видно: Погані коментарі: Деколонізація обліку — це не лише відмова від 1С та BAS.;
як ілюстрація: Reviewer має запитати: Це і є собою нова культура української ERP.; # Чи є собою тести?; Мета — сильніша платформа, а не сильніше его.; # Чи правильно обробляються помилки?; Pull Request — термін, поширений у GitHub.;У найпростішому сенсі code review відповідає на питання: Не робіть review для галочки. Якщо reviewer не зрозумів зміну, не перевірив ризики й без ускладнень натиснув approve, це не code review, а цифрове «та наче нормально».; |- |
Навіщо потрібен code review?; Для K2 ERP, де один адміністратор має змогу вести багато компаній, авторизація є собою особливо важливою.; * які рядки додані;
|
Перевіряти лише стиль | Логічні помилки залишаються | Дивитися на бізнес-логіку, безпеку й інформаційні дані |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Робити review формально | Помилки потрапляють у production | Читати код уважно | ||||||||||
| Великі PR | Reviewer пропускає ризики | Ділити зміни на менші | ||||||||||
| Коментувати грубо | Псується культура команди | Писати конкретно й поважно | ||||||||||
| Не перевіряти тести | Регресія повертається | Дивитися на test coverage і сценарії | ||||||||||
| Ігнорувати security | Ризик витоків і атак | Перевіряти authentication, authorization, input validation | ||||||||||
| Не перевіряти міграції | Ризик зламати інформаційні дані | Тестувати міграції й rollback | ||||||||||
| Зливати без CI | Помилки збірки потрапляють далі | Використовувати автоматичні перевірки |
Кожен знайдений на review баг дешевший за баг у production.; # Додавати посилання на задачу або bug report.; Окремо варто відзначити покращити якість коду, перевірити архітектурні рішення для бізнесу, безпеку, продуктивність, читабельність, відповідність стандартам, вплив на бізнес-логіку і можливі ризики для системи.; Але швидкість без контролю якості має змогу створити технічний борг.;== Code Review у базі даних == Code review і testing працюють разом.; * важко зрозуміти логіку;
- reviewer втомлюється;
- зростає шанс пропустити баг;
- обговорення розмивається;
- складно тестувати;
- складно відкотити.; Якщо PR виглядає як роман у трьох томах, reviewer почне читати його як шкільну програму — з болем.; Ідеально, коли баг не доходить до користувача, бо reviewer помітив проблему ще в diff.; # Не вимагати особистий стиль як закон, якщо немає стандарту.; |-
| Логіка | Чи код робить те, що потрібно | Документ правильно створюється |- | Безпека | Чи немає ризиків доступу | Права перевіряються на backend |- | Продуктивність | Чи немає повільних запитів | Звіт не робить 1000 зайвих SQL-запитів |- | Читабельність | Чи зрозумілий код | Назви функцій пояснюють дію |- | Тести | Чи покриті важливі сценарії | є собою тест на повернення товару |- | технічна архітектура | Чи зміна не ламає структуру | Бізнес-логіка не захована у frontend |- | API | Чи не зламана сумісність | Старі клієнти не падають після зміни відповіді |- | інформаційні дані | Чи правильно працюють міграції | Нова колонка має значення за замовчуванням |}
Code Review і Code
Code Review і Testing
- чи є собою перевірка прав доступу;
- чи валідовані вхідні інформаційні дані;
- чи немає SQL injection;
- чи правильно працюють транзакції;
- чи коректно обробляються помилки;
- чи не порушена бізнес-логіка;
- чи немає зайвих запитів до бази;
- чи не витікають секрети в логи;
- чи не змінюється API без потреби;
- чи є собою тести для критичних сценаріїв.;== Зовнішні посилання ==
Автор коду має допомогти reviewer зрозуміти контекст:
Див.; додатково
Code review потрібен для того, щоб зробити код якіснішим до того, як він стане частиною продукту.; # Тести проходять успішно.; Reviewer має не без ускладнень «поставити галочку», а зрозуміти зміну.; # Чи є собою перевірка прав доступу?; # Чи немає очевидних багів?; |- | Що перевіряють під час review?; # Чи потрібна міграція даних?; Author — розробник, який створив зміну.; | Формальне review без перевірки бізнес-логіки, безпеки й тестів.; Code review і testing доповнюють одне одного.; Оскільки K2 ERP розвивається як українська ERP-платформа, code review сприяє підтримувати якість продукту, зменшувати ризики й прискорювати еволюція без хаотичних доробок.; # Чи зміна впливає на права доступу?;== Diff ==
!; # Розділяти обов’язкові зміни й пропозиції.; # Чи не логуються секрети?;Code Review і Authentication
- тести;
- стиль коду;
- статичний аналіз;
- типізація;
- збірка frontend;
- міграції;
- безпекові перевірки;
- lint;
- форматування;
- coverage;
- dependency scan.;== Code Review у K2 ERP ==
Code Review у Frontend
- authentication;
- authorization;
- input validation;
- SQL injection;
- XSS;
- CSRF;
- токени;
- cookies;
- секрети;
- права файлів;
- доступ до API;
- логування чутливих даних;
- завантаження файлів;
- обробку помилок;
- принцип найменших привілеїв.;== Code Review і Bug report ==
В ERP code review має враховувати не лише технічну сторону, а й бізнес-смисл.; з цієї причини code review перевіряє не лише «чи функціонує», а й «чи можна це буде зрозуміти через пів року».; Перед тим як ця зміна потрапить у головну гілку коду, її переглядає інший розробник або команда.; # Не сприймати зауваження як напад.;== Code Review і Cloud Computing ==
- чи права перевіряються на backend;
- чи враховується організація;
- чи враховується роль;
- чи немає доступу до чужих документів;
- чи захищені API endpoints;
- чи не можна обійти обмеження через прямий запит;
- чи правильно функціонує зміна ролей;
- чи очищається cache прав доступу.; # Пояснювати бізнес-контекст.; # Reviewer залишає коментарі або approves.; * «Потрібен тест на сценарій повернення товару, бо він уже ламався раніше».; |-
| Чи замінює code review тестування?; {{SEO