Часто менти-разработчики приходят с вопросами, на которые по-хорошему нет точного ответа. Множество наших диалогов можно свести примерно к следующему::
- Я могу сделать так?
- Можешь.
- Есть еще вот такие варианты. А как будет лучше?
- Зависит от контекста…
- Ну а как бы ты сделал?
Расскажу о методе, который спасает наши проекты от неоправданных решений и превращает хаос в эволюцию.
Ваши системы должны развиваться итеративно.
- Закоммититься на подход к mvp, позволяющий рассмотреть фичу/весь флоу с наиболее разных сторон и собрать понимание о работе в системе.
- В процессе, у вас совершенно точно возникнет несколько идей, как по-вашему мнению сделать лучше.
- Остановитесь, выдохните и зафиксируйте эти идеи. Распишите ваши гипотезы относительно этих идей. Например, заведите “беклог идей” по реализуемой сторе/эпику.
- После внедрения первичного варианта, соберите аналитику. Сравните с вашей гипотезой.
- Продолжайте эволюционно улучшать функционал
С бизнесовой точки зрения такой подход хорошо рекламирует известная книга Бизнес с нуля. Метод Lean Startup
Однако, при принятии технических и архитектурных решений вы точно также можете пользоваться подобной методологией. Сбор метрик и тестирование гипотез помогут избежать преждевременных оптимизации или промаха, ограничивающего функциональные возможности продукта.
Test and Learn!
Часть 2 (в проработке):
С точки зрения реализации, важно настроить следующее:
- Реализуйте решение, дающее максимальную степень свободы в следующей итерации проверки гипотез. Не ограничивайте автоматизацией или валидацией то, что исходно вызывает сомнения.
- В случае проверки гипотез, опасно влияющих на данные, заводите фича-флаги и создавайте ветки логики, обрабатывающие данные параллельно, не модифицируя продакшен (например, пишите независимо пишите что-то в другую таблицу)
- Убедитесь, что, снимаете все необходимые вам метрики. Например, если вы хотели бы принять техническое решение по оптимизации производительности - обязательно снимайте response time, размеры индексов и процент bloat индексов в БД, нагрузку на GC и другие. Если-же принимаете бизнесовое решение, то добейтесь максимальной доступности данных к аналитике: ведите логи действий пользователей в связке с идентификатором процесса/действия, запускайте а/б тестирование функционала