Призначення чек-листа

Чек-лист призначений для структурованої перевірки pull request у проєктах на Solana. Він допомагає ревʼюєру не пропустити критичні помилки в смарт-контрактах на Rust та Anchor, а автору — підготувати код до затвердження без зайвих ітерацій. Ресурс охоплює етап між написанням коду та злиттям гілки, але не замінює перевірки перед деплоєм, яка описана окремо.

Блоки перевірки

Коректність логіки та обробки помилок

  • Усі математичні операції з токенами виконуються з урахуванням кількості знаків після коми (decimals) і не призводять до переповнення чи втрати точності.
  • Передані облікові записи (accounts) перевіряються на відповідність очікуваним типам через constraint в Anchor або ручну перевірку owner та key.
  • PDA (Program Derived Address) ініціалізуються з коректними насінами (seeds), а повторна ініціалізація викликає помилку.
  • CPI-виклики (Cross-Program Invocation) містять перевірку поверненого значення та обробку помилок, а не ігнорують їх через unwrap().
  • Усі гілки логіки мають явну обробку помилок із зрозумілими кодами, що дозволяють діагностувати проблему з логів.
  • Стан програми після виконання інструкції відповідає очікуваному: баланси, лічильники, прапорці оновлені коректно.

Безпека та управління правами

  • Авторизація критичних дій (зміна конфігурації, зняття коштів, оновлення програми) обмежена авторизованими обліковими записами через явні перевірки.
  • Відсутні невикористані облікові записи в інструкціях — кожен account має призначення і перевірку.
  • Передані токен-акаунти належать очікуваному mint і мають правильного власника.
  • Не залишилося закоментованого коду з відключеними перевірками, тимчасових println! або тестових ключів.
  • Системні програми (System Program, Token Program, Associated Token Program) передаються коректно, а не жорстко прописані константами.
  • Відсутні вразливості, повʼязані з повторним використанням інструкцій (replay attacks) — перевірено наявність унікальних ідентифікаторів транзакцій де це потрібно.

Читабельність та відповідність стилю

  • Назви змінних, функцій та структур відповідають прийнятій у проєкті конвенції (наприклад, snake_case для Rust).
  • Складні ділянки логіки мають коментарі, що пояснюють чому, а не що відбувається в коді.
  • Функції не перевищують розумний розмір — якщо тіло займає більше 50–70 рядків, доцільно розбити на допоміжні.
  • Імпорти відсортовані та не містять неиспользованих модулів (перевіряється cargo clippy).
  • Форматування відповідає налаштуванням rustfmt без відхилень.

Тестове покриття та документація

  • Для кожної нової або зміненої інструкції є хоча б один позитивний та один негативний тест-кейс.
  • Тести перевіряють граничні значення: нульовий баланс, максимальну суму, відсутність прав.
  • Зміни в документації до інструкцій (#[derive(Accounts)], коментарі до модулів) відповідають фактичній логіці.
  • Якщо змінено зовнішній інтерфейс (публічні типи, функції), оновлено відповідні описи для інших розробників або клієнтів.
  • Тести стабільно проходять у ізольованому середовищі (solana-test-validator або локальний test runner) без залежності від мережевого стану.

Критерії затвердження PR

Pull request вважається готовим до злиття за таких умов:

  • Усі критичні пункти чек-листа виконані без винятків.
  • Некритичні пункти мають зафіксовані відхилення з поясненням причин і, за потреби, окремим завданням на доопрацювання.
  • CI-конвеєр пройшов успішно: збірка, лінтинг (cargo clippy, rustfmt), тести.
  • Принаймні один ревʼюєр, окрім автора, підтвердив перевірку за чек-листом.
  • Конфлікти з базовою гілкою вирішені, а коміти згруповані логічно (або виконано squash).

Якщо PR стосується лише документації або конфігурації, достатньо перевірити відповідні блоки чек-листа.

Обмеження чек-листа

  • Чек-лист не замінює автоматизовані інструменти статичного аналізу — він працює разом із ними, а не замість.
  • Він не охоплює перевірку інфраструктури розгортання, моніторингу та налаштування RPC-вузлів — для цього призначений окремий чек-лист deployment на mainnet.
  • Чек-лист не містить перевірок економічної моделі токена, юридичних аспектів або відповідності регуляторним вимогам.
  • Він не адаптований для смарт-контрактів на інших блокчейнах — усі пункти специфічні для Solana та екосистеми Rust/Anchor.
  • Чек-лист не гарантує відсутність вразливостей нульового дня — він знижує ймовірність типових помилок, але не є заміною професійного аудиту безпеки.

Версія ресурсу

Ресурс «Чек-лист code review»: статична версія 1.0. Сторінка містить готовий текстовий чек-лист і готова до практичного використання без очікування окремого інтерактивного інструмента. Остання редакційна перевірка: 2 серпня 2026 року.

Джерела