Разработчики любят простые принципы. Один из самых популярных — YAGNI («You aren't gonna need it»), который гласит: не усложняй систему тем, что может никогда не пригодиться. Но, как у любого правила, у него есть исключения. Сегодня поговорим о новом принципе разработки — YAGRI («You are gonna read it») - вам это пригодится.
Автор этого подхода, Скотт Антипа, предлагает взглянуть на хранение данных немного иначе. Вместо минималистичного подхода, когда мы оставляем только самое необходимое, он призывает сохранять чуть больше информации, особенно метаданные, которые почти гарантированно пригодятся позже.
🔍 Почему минимализм может быть опасен?
В стремлении избежать переусложнения мы часто сохраняем только те данные, которые напрямую требуются интерфейсом приложения. UI-дизайнер нарисовал форму, пользователю надо видеть три поля — мы и храним ровно эти три поля в базе.
Проблемы начинаются тогда, когда возникает нестандартная ситуация. Например, пользователь жалуется, что пропали важные данные. Или руководство спрашивает, почему была удалена критически важная запись. И тут оказывается, что необходимой информации, чтобы восстановить цепочку событий, просто нет.
Именно такие случаи описывает Скотт Антипа, предлагая задуматься заранее и сохранить чуть больше контекста, даже если это явно не прописано в техническом задании.
📌 Что хранить обязательно?
Автор приводит примеры наиболее важных полей, которые стоит добавлять почти в каждую таблицу:
- 🕒 created_at (когда запись была создана)
- ♻️ updated_at (последнее обновление данных)
- 🗑️ deleted_at (дата удаления, вместо физического удаления записи)
- 👤 created_by, updated_by, deleted_by (кто сделал эти действия)
- 🔑 permission (какие разрешения были использованы при создании, обновлении или удалении данных)
- 💬 контекст удаления (почему запись была удалена, если это возможно отследить)
Такие поля делают систему более прозрачной и значительно упрощают жизнь разработчикам и администраторам при возникновении проблем.
🛠️ Техническая сторона вопроса (soft delete и метаданные)
Один из технических аспектов, который сильно облегчает жизнь разработчику, — это использование подхода soft delete (мягкое удаление). Вместо того, чтобы физически удалять данные из таблицы (DELETE FROM table WHERE id = 1), лучше помечать запись удалённой (deleted_at = NOW()).
Технически это выглядит так:
UPDATE users
SET deleted_at = NOW(), deleted_by = 'admin', delete_reason = 'Запрос пользователя'
WHERE id = 1;
Теперь данные не потеряны навсегда, и, если случится критическая ошибка или возникнут юридические вопросы, восстановить картину будет просто.
⚖️ Где проходит грань между YAGRI и избыточностью?
Важно помнить, что принцип YAGRI — это не призыв сохранять абсолютно всё подряд. Если пойти этим путём, база быстро превратится в хаос из ненужной информации и сложно поддерживаемых таблиц.
Оптимальное решение — сохранять метаданные, которые отвечают хотя бы одному из следующих условий:
- 💡 могут помочь понять причину возникновения ошибки;
- 📊 будут полезны для внутренней аналитики;
- ⚠️ позволяют восстановить последовательность событий и действий пользователя;
- 🛡️ помогают выполнить требования безопасности и аудита.
🗣️ Личное мнение автора
На мой взгляд, YAGRI — это очень полезный принцип, который может здорово сэкономить время и нервы команде в долгосрочной перспективе. Конечно, добавление таких полей требует некоторого начального труда и дисциплины, но это ничто по сравнению с теми проблемами, которые могут возникнуть, если этих данных не окажется в нужный момент.
Один раз лично столкнувшись с потерей данных, которые были «удалены безвозвратно» из-за отсутствия soft delete и метаданных, начинаешь намного внимательнее относиться к подобным вопросам. YAGRI — не универсальное правило, но оно близко к здравому смыслу и точно заслуживает внимания.
📈 Заключение: стоит ли внедрять YAGRI?
Однозначно да. Особенно в тех системах, где цена ошибки высока, а пользовательские данные являются критически важными. Даже одна сохранённая строка в базе может спасти ситуацию, сохранить репутацию компании и нервы команды.
Главное — не переборщить и найти золотую середину между лаконичностью данных и их полнотой. И пусть однажды собранные заранее метаданные станут вашим спасением, а не очередной головной болью.
🔗 Оригинальная статья автора: YAGRI: You are gonna read it