… Если он еще не установлен в вашем продукте

В настоящее время я работаю в небольшом стартапе. Однажды я поздно ночью думал о нашем новом продукте и о том, как его правильно спроектировать. А ниже я подведу пару итогов того вечера.

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

Прежде всего, зададим себе вопрос:

Нужно ли нам тратить часы и часы на подробное планирование всех взаимодействий в нашей системе и каждого из ее компонентов?

Прежде чем ответить на этот вопрос, я поделюсь парой своих мыслей по этому поводу.

Архитектура программного обеспечения не нужна?

Довольно долгое время я считал, что перед тем, как приступить к кодированию, мы должны спланировать. Даже при использовании гибких подходов у нас должен быть дизайн всей системы.

И действительно, наличие твердого плана облегчает разработку. Вы и команда разработчиков оцените, что хорошо сделали диаграммы QML и определения API.

Но. Вместо этого вы отказываетесь от самых элементарных вещей для своего бизнеса. Гибкость. В самом деле, вся суть архитектуры программного обеспечения заключается в установлении границ.

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

Однако, когда вы сужаете границы дальше, определяя один язык или структуру, способ запуска ваших компонентов (например, AWS Lambda или AWS EC Containers) и даже внутреннюю структуру (например, отношения сущностей в форме диаграмм QML), возникает несколько проблем.

Вы не только тратите много времени на то, чтобы не приносить пользу вашему продукту. Вы также предвзято относитесь к возможностям вашей системы. И можете измерить это не только с помощью бизнес-требований, но и на основе облачного замка вашего подхода к проектированию. Иногда довольно легко забыть, что все технические аспекты должны служить продукту, а не наоборот.

Разработка программного обеспечения

Хотя проектировать вашу систему как единое целое довольно утомительно, но я считаю очень полезным и выгодным в долгосрочной перспективе проектирование каждого более или менее автономного модуля как можно более «хорошо».

Это относится не только к микросервисам или бессерверным функциям, но и к отдельным модулям вашего монолитного приложения.

Под «хорошо» я обычно подразумеваю ремонтопригодность, удобочитаемость, тестовое покрытие. Вероятно, вы не будете тратить дни и дни на оптимизацию производительности, поскольку более важным результатом на ранних этапах является получение отзывов от реальных клиентов. Однако об обратном случае я расскажу в одной из следующих статей, так что следите за обновлениями.

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

В конечном итоге последовательная архитектура

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

Вы собрали знания, необходимые для улучшения вашей хаотической архитектуры, при этом потратив на это очень мало времени.

Теперь вы можете позволить себе потратить это время на архитектурные решения и документацию. Кроме того, с этого момента вы, вероятно, будете расти довольно быстро (если бизнес-модель проверена, а отставание достаточно велико), поэтому набор границ будет действительно полезен для создания структуры взаимодействия между разработчиками, а также между приложениями.

Заключение

Поздравляю, вы зашли так далеко.

Итак, наконец, нужна ли нам та вещь об архитектуре программного обеспечения, о которой ребята из Google, Facebook и других крутых людей спросят нас во время собеседований?

Должен признаться, я соврал вам в названии. Нам это нужно. Но не так, как можно было бы думать о чем-то твердом, как сталь, который определяет, что мы можем и что не можем сделать, чтобы сделать наших клиентов счастливыми.

Благодаря чистым и обслуживаемым отдельным компонентам мы сможем реорганизовать их, когда бизнес, в котором мы работаем, будет иметь стабильную бизнес-модель и потребности, которые можно решить с помощью сложной архитектуры.

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