У тікеті майбутня функція майже завжди виглядає скромно: додати поле, вставити фільтр, розширити вже знайомий статус. Саме тому її легко недооцінити. Ризик часто сидить не в новому коді, а в старій поведінці, на яку цей код спирається. Якщо цей маршрут ніхто не перечитував після останнього збою, нова зміна просто поверне стару помилку під новою назвою.

Цей текст не замінює повний аудит. Аудит ширший, у ньому більше доказів і він написаний так, щоб наслідки побачила не лише людина з доступом до репозиторію. Такий окремий прохід описаний у що перевірити спершу і до яких висновків не стрибати. Цей список потрібен раніше. Якщо збігаються кілька ознак, функцію краще ненадовго зупинити й уважно прочитати шлях. Не починайте з переписування. Переписування — це інший проєкт, а не автоматична реакція на кожен незручний фрагмент коду.

1. Ніхто не відповідає за поведінку, яку змінить функція

Поставте просте запитання: хто може словами пояснити, що робить сторінка, коли значення порожнє, коли в людини немає доступу і коли той самий запит прилітає повторно. Якщо у відповідь ви чуєте лише «це видно в коді», то правила як спільного знання немає. Є файл, але немає власника поведінки. Нова функція тоді лише наростить ще одну гілку на те, що ніхто не може відтворити вголос. Почніть рев’ю з кількох звичайних речень про правило. Потім звірте ці речення з кодом. Якщо вони не збігаються, спершу треба визначити правильну поведінку, а вже потім рухати тікет далі.

2. Зміну реально перевірити тільки на живому сайті

Гілка, яку можна випробувати лише на проді, не є дрібною зміною, навіть якщо диф короткий. Це вже викладка без репетиції. Знайдіть команду, пайплайн або звичний ручний крок, через який код потрапляє на живий сайт. Якщо іншого середовища немає, це важливіше за саму нову функцію. Правка на проді лише тому, що більше ніде подивитися, дуже швидко перетворює невелике поле на інцидент. Практичний висновок описаний у чому не варто латати прод через відсутнє тестове середовище. Рев’ю, яке оминає цю обставину й обговорює тільки назви змінних, пропускає головне.

3. Повідомлення «Дякуємо» і реальний запис уже розходяться

Відправте форму, яку нова функція має розширити. Подивіться не лише на екран, а й на те, куди реально дійшли дані: у лист, у рядок таблиці, у картку, яку хтось відкриє зранку. Якщо сайт уже показує успіх тоді, коли запис не доходить до потрібного місця, нове поле не виправить цей розрив. Воно просто пройде тим самим поламаним маршрутом. Типові місця розриву зібрані в чому заявка не доходить і в що ламається між формою і карткою. Спершу треба перечитати цей шлях, а не поспішати з новою колонкою.

4. Ніхто не може назвати, скільки секунд сторінка вже займає

Новий фільтр, додаткова колонка або важча відповідь лягають на сторінку, де користувач уже чекає. Якщо поруч із URL або назвою задачі немає числа, ви не зможете чесно сказати, чи стало гірше після зміни. Спершу треба зафіксувати час. Потім, якщо він доступний, відкрийте повільний журнал за цей проміжок, згрупуйте запит і порівняйте кількість переглянутих рядків із кількістю відданих. Порожній журнал сам по собі не доводить, що сторінка швидка. Порядок такого читання описаний у як читати повільний журнал до рефакторингу. Фраза «наче нормально» без секунд — це лише припущення.

5. Та сама задача вже здатна створити два записи

Повторні спроби, подвійні кліки та вебхуки, які приходять двічі, не є екзотикою. Якщо поточний код сприймає другий запуск як новий факт, наступна функція успадкує ту саму ваду, доки хтось не сформулює правило. Знайдіть операцію, яка має лишатися одиничною: оплату, картку, оцінку, лист клієнту. Перевірте, що відбувається при повторі. Рев’ю нового коду, яке не програє стару задачу ще раз, легко схвалить дубль. У тікеті має з’явитися чітке речення: чи повинен другий запуск щось змінювати, чи ні.

6. Продукт спільний для кількох клієнтів, а сторінку не відкривали під двома акаунтами

Звіт, пошук, експорт або нічна задача в багатоклієнтському продукті потребують дуже приземленої перевірки. Візьміть два акаунти й пошукайте чужий рядок саме на тій сторінці, яку розширює функція. Не на демо, не на безпечному прикладі, а на реальному маршруті цієї зміни. Один чужий рядок — це вже інцидент, а не дрібна суперечка про стиль. Типові місця розриву меж зібрані в де рветься ізоляція даних. Рев’ю, яке дивиться тільки акаунт автора, часто не бачить join без межі.

7. Процес уже росте, доки хтось його не перезапустить

Якщо минулого тижня все завершилося перезапуском, новий цикл у функції легко приведе до того самого результату ще раз. Зафіксуйте пам’ять до дії, на піку й після завершення. Додаткова RAM лише відсуває повторення, але не пояснює причину росту. Такий прохід описаний у що перевірити до покупки пам’яті. Рев’ю, яке обговорює новий клас, але не питає, що саме процес утримує в пам’яті, пропускає ознаку просто перед собою.

8. Секрет для цієї функції вже лежить у чаті або в репозиторії

Новій інтеграції часто потрібен ключ. Якщо попередній ключ передавали в повідомленні або він досі сидить у закоміченому файлі, у рев’ю вже є висновок ще до перегляду дифа. Треба назвати систему і сам факт витоку, але не копіювати секрет у коментар. Перенесіть його туди, де команда вже зберігає приватні дані, і переконайтеся, що копії в репозиторії більше немає. Якщо рев’ю схвалює виклик API, але залишає ключ у гілці обговорення, воно додає нову проблему до тікета, який нібито був лише про поле.

9. Остання викладка здивувала тих, хто потім усе пояснював

Таке здивування майже завжди означає розрив між зміною і її описом. Була неясна гілка, неясна команда або незрозуміло, хто взагалі мав право це запускати. Інколи нічна задача падала до ранку, а команда потім відновлювала результат вручну. Перед тим як додавати ще одну рухому частину, відкрийте журнал помилок за останній тиждень. Зберіть повторювані рядки й прив’яжіть кожен повтор до конкретної операції: лист не пішов, картка не створилася, звіт довелося набирати заново. Функція поверх нічного збою дає два сюрпризи замість одного. Разовий шум можна лишити на потім, але повторюваний нічний збій лишати не варто.

10. Запропоноване рев’ю вже стало переписуванням, хоча шлях ніхто не читав

Неідеальний код, який виконує один зрозумілий запит, не обов’язково є сьогоднішньою аварією. Фраза «спершу треба все переписати» часто лише відсуває читання реального шляху, яким піде нове поле. Відкиньте це як перший висновок. Спочатку прочитайте шлях заявки, секунди й шлях викладки. Лише після цього можна вирішувати, чи безпечно додавати функцію на наявному коді.

Черга або кеш теж можуть бути передчасною відповіддю. Фонова задача, яка виконує той самий цикл, усе одно читає ті самі рядки. Людина просто бачить стан «обробляється» замість прямого очікування. Витрата не зникла, вона лише змінила місце. Коли черга справді доречна, робота має піти з кліку, а повтор не повинен дублювати побічний ефект. Це вже інше рішення, і воно описане в коли черга доречна поруч із застосунком.

Що має бути в рев’ю замість цього

Корисне рев’ю перед функцією зазвичай коротке й предметне. Назвіть операцію. Додайте докази: секунди, результат другого запуску, перевірку двома акаунтами, місце, куди реально дійшла заявка. Окремо напишіть, чого ви поки не змінюєте. Про структуру варто говорити лише там, де вона ховає один із цих фактів. Довгий список зауважень про назви без зв’язку зі збоєм — це беклог, а не рішення для цього тікета.

Коли друга пара очей і є головною роботою

Команда, яка вміє відкривати журнали, може пройти цей список самостійно. Другий погляд потрібен, коли журнал лежить там, куди ніхто не заходить, коли поведінку можна пояснити лише на живій базі, або коли тікет уже скотився до переписування без секунд і без шляху заявки. Надішліть операцію, секунди й результат однієї тестової відправки. Сирий журнал із даними замовників надсилати не треба.

Саме таке читання і є роботою. Послуги охоплюють швидкодію, відновлення систем, які вже працюють на проді, і зв’язки навколо них. Обрані роботи показують результат поруч з операцією, яка його дала. Якщо у вас уже є сторінка й одна з ознак із цього списку, надішліть саме їх. Рядки замовників залиште в себе.