Callbacks створюють неявну бізнес-логіку, яку важко відстежити, тестувати й контролювати.
Ми всі так робили 🙂
Як це виглядає
class Order < ApplicationRecord
after_create :send_email
after_save :update_statistics
after_commit :sync_with_crm
private
def send_email
...
end
end
Спочатку — зручно.
Потім у моделі вже 6 callback-ів.
А потім ти не можеш пояснити, чому щось запускається двічі.
У чому проблема
🔹 Логіка стає неявною
🔹 Побічні ефекти розкидані
🔹 Важко зрозуміти порядок виконання
🔹 Тести стають крихкими
🔹 Дебаг займає більше часу, ніж написання
Callbacks — це implicit behavior.
А implicit behavior складно масштабувати.
Де особливо небезпечно
• фінансові операції
• інтеграції з зовнішніми сервісами
• зміна статусів
• створення пов’язаних записів
Особливо якщо callback викликає ще одну модель… яка має свої callbacks.
Що робити замість цього?
1️⃣ Явна бізнес-логіка
CreateOrder.new(params).call
Service object робить те, що написано.
2️⃣ after_commit замість after_save
Якщо вже використовуєш callback — не роби побічні ефекти до коміту в БД.
3️⃣ Мінімізувати кількість callback-ів
Якщо їх більше 2–3 — це сигнал задуматись.
Маленьке правило, що рятує нерви
Якщо ти не можеш швидко відповісти “чому цей код спрацював” — подивись у callbacks.
Скільки callback-ів максимум ви бачили в одній моделі? 😄
TikTok | Instagram | Telegram