В 03:00 переливка данных легла: скрипт table_for_Ilya упал, а единственный, кто знал, как он устроен, работает уже в другой компании? Метрики не считаются, а тебе приходится разбираться в трехэтажных запросах, логику которых в трезвом состоянии понять невозможно?

Классика: Bus-factor = 1, то есть при встрече аналитика с автобусом (или увольнением) информации о скриптах и процессах теряется.

Это боль аналитиков не только потому, что приходится разбираться в коде:

🔒 Дедлайны ― продакты не сдвигают релизы только из-за того, что «SQL-монстр непонятно что считает» и задача требует больше времени из-за погружения в контекст. 🧢 Метрики — из-за множества подвешенных вопросов в подсчете метрик начинаешь сомневаться и перепроверять. ❓ Эффект амнезии — через 3 месяца после написания даже свой родной код читается как чужой. Если нет хорошего описания, начинаешь путаться и тратишь время для погружения.

А вот 5 анти-Bus привычек:

1. Комментируй запросы сразу -- Это спасет тебя же через неделю от вкатывания в код

2. README к каждой витрине Источники, что отдаем, ограничения, для чего (еще можно отдельно выделять витрины, от которых зависят ключевые дэши)

3. Демо по ключевым скриптам А также задачи на разные витрины для всех аналитиков (чтобы информация о кодовой базе распространялась)

4. Ревью кода Да, ревьюер не всегда полноценно погружается в код запроса и просто смотрит, что все выглядит логично. Но все равно это полезно.

5. Нормальная страница с описанием на вики Где что как зачем лежит, начиная с страницы-оглавления. Если новый сотрудник без кучи вопросов находит информацию — то у вас все ок.

Ну и это уже база: LLM отлично пишет код комменты и README, «закомментируй код», и запрос уже за секунды становится намного более читаемым.

И тогда на поднятие table_for_Ilya команда сразу тратит меньше времени