9 законов (принципов) программирования — это база.

0⃣ Закон Брукса — если ты посадишь трёх разрабов за одну задачу, они не сделают её в три раза быстрее. Чем больше твоя команда, тем сложнее становится координация и планирование.

1️⃣ Закон Гудхарта — чем жёстче твои KPI и метрики для измерения эффективности, тем сильнее они отвлекают от выполнения самих задач. В самых запущенных случаях люди забивают на задачи и переключаются только на KPI.

2️⃣ Закон Хайрама — чем больше юзеров у API, тем сильнее они полагаются на незадокументированные особенности, превращая их в «обязательные» функции. Из-за этого любые изменения становятся сложными, ведь легко сломать что-то для тех, кто уже привык к старым фишкам.

3️⃣ Закон Конвея — структура программ часто повторяет организационную структуру команды, которая её создала. Если слепо следовать границам в команде, софт получится неоптимизированным.

4️⃣ Закон Линуса — база опенсора. Чем больше людей проверяют код, тем больше шансов найти ошибку.

5️⃣ Закон Хофтшадтера — дедлайн всегда нужно ставить с запасом. Мы склонны занижать количество времени, необходимое для выполнения задачи.

6️⃣ Закон Кернигана — код всегда должен быть простым и понятным. Сложный код всегда становится неподъёмным в отладке и сопровождении — это только вопрос времени.

7️⃣ Закон Питера — софт- и хард-скиллы, это разные навыки. Так, топовый разраб не обязательно обладает такими же способностями к управлению людьми, руководству командами или выполнению стратегических требований лидерства.

8️⃣ Закон Парето — усилия должны быть избирательными. Чтобы 20% усилий приносили 80% результатов, сначала нужно понять, куда прикладывать эти усилия. Качество всегда перевешивает количество, а результат важнее времени затраченного на задачу.


#dev #baza #pareto #laws #programming #engineering

📊 Как избежать хаоса с данными?
Способы обеспечения согласованности показателей в хранилище

Если ты работаешь с аналитикой, ты, вероятно, сталкивался с ситуацией, когда один и та же метрика рассчитывается по-разному в разных отделах. Это приводит к путанице, снижает доверие к данным и замедляет процесс принятия решений. Расскажу основные причины этой проблемы и два эффективных варианта решения.

🧐 Почему показатели расходятся?
Причина кроется в спонтанном росте аналитики:
🔘 Аналитик пишет SQL-запрос для расчёта метрики.
🔘 Затем другие команды создают свои собственные версии на основе этого запроса, внося незначительные изменения.
🔘 Со временем возникают расхождения, и команда аналитики тратит всё больше и больше времени на устранение несоответствий.

Чтобы избежать такой ситуации, стоит внедрить единые стандарты управления метриками.

✏️ Два подхода к обеспечению согласованности

▶️▶️Семантический слой
Это промежуточный слой между данными и инструментами аналитики, где метрики определяются централизованно. Они хранятся в статических файлах (например, YAML) и используются для автоматической генерации SQL-запросов.

🙂 Плюсы:
✔️ Гибкость — адаптируется к различным запросам без предварительного создания таблиц.
✔️ Прозрачность — единые определения доступны для всех команд.
✔️ Актуальность — данные обновляются в режиме реального времени.

🙄 Минусы:
✖️ Требует инвестиций в инфраструктуру и оптимизацию.
✖️ Может увеличить нагрузку на вычисления (это ты сможешь решить с помощью кэширования).

📌 Пример инструмента: Cube.js - одно из немногих зрелых open-source решений.

▶️▶️Предварительно агрегированные таблицы
Здесь заранее создаются таблицы с предварительно вычисленными метриками и фиксированными измерениями.

🙂 Плюсы:
✔️ Простая реализация, удобная для небольших проектов.
✔️ Экономия вычислительных ресурсов.
✔️ Полный контроль над вычислениями.

🙄 Минусы:
✖️ Сложно поддерживать по мере увеличения количества пользователей.
✖️ Возможны расхождения, если метрики определены в разных таблицах.

😎 Какой метод выбрать?
Оптимальный подход - гибридное использование:
🔘 Реализуй семантический слой для масштабируемости.
🔘 Используй предварительно агрегированные таблицы для критических показателей, где важна минимальная стоимость вычислений.

#de #engineering #chaos