Почему я перестал писать код и начал проектировать
Раньше я думал, что разработка программного обеспечения — это написание фич. Я считал, что моя работа заключается в создании сущностей, написании контроллеров и подключении баз данных.
Недавний проект изменил мой взгляд на вещи. Я понял, что написание кода — это лишь часть решения. Настоящая работа начинается еще до того, как вы напишете первую строчку кода.
Вы должны определиться с архитектурой. Вы должны задаться вопросами: почему она подходит, сколько это стоит и какие риски она устраняет.
Вот мои основные уроки:
• Архитектура должна соответствовать стадии продукта. Соблазн сразу использовать микросервисы, Kubernetes и сложные очереди событий велик. Для нашего проекта мы выбрали многослойную архитектуру в рамках одного процесса. Это позволило нам разделить зоны ответственности без головной боли, связанной с распределенными системами. На старте простота часто оказывается лучшим выбором.
• Некоторые решения дешевы сейчас, но дороги в будущем. Мы добавили TenantId в нашу модель данных с первого дня. Несмотря на то, что у нас был всего один клиент, это облегчило будущий переход на модель SaaS. Если слишком долго откладывать внедрение многоарендности (multi-tenancy), миграция превратится в кошмар.
• Проектирование предотвращает тупиковые ситуации в будущем. Программирование решает сиюминутную задачу. Проектирование решает задачу так, чтобы не закрывать двери в будущее. Мы на ранних этапах начали использовать контейнеры, чтобы упростить переход на другую инфраструктуру. Мы использовали интерфейсы, чтобы сделать замену провайдеров простой процедурой.
• Изменения в бизнесе диктуют технические изменения. Система переходит на микросервисы, потому что растет бизнес. Приложение для одной клиники превращается в SaaS-платформу для сотен клиник. Этот сдвиг меняет подходы к биллингу, подпискам и масштабированию.
• Надежность требует грамотных паттернов. Мы перешли от синхронных вызовов к событийно-ориентированной архитектуре (event-driven architecture). В медицинской системе медленная служба уведомлений не должна приводить к сбою при записи на прием. Мы использовали паттерн Outbox, чтобы гарантировать сохранность данных, даже если брокер сообщений выйдет из строя.
• Паттерны должны соответствовать предметной области. Не используйте паттерны вслепую. Медицинский диагноз требует строгой согласованности (strong consistency). Вы не можете полагаться на согласованность в конечном счете (eventual consistency), когда речь идет о безопасности пациентов. Не используйте кэширование для конфиденциальных клинических данных, если это нарушает цепочку аудита (audit trail).
• DevOps — это не то, о чем вспоминают в последнюю очередь. Развертывание, проверки работоспособности (health checks) и пайплайны являются частью первоначального проектирования. Вы должны оценивать затраты и выбирать компоненты, которые действительно отвечают вашим потребностям.
Разница между программистом и дизайнером заключается в вопросе «почему».
Программист спрашивает: «Как заставить это работать?» Дизайнер спрашивает: «Почему это правильное решение именно для этой конкретной проблемы?»