Роль архитектора программного обеспечения, похоже, востребована как инженерами, так и командами, которые работают с инженерами. Существует основное убеждение, что хорошая архитектура поможет решить многие проблемы в будущем и откроет большую гибкость и скорость внутри команды инженеров.
Хороший архитектор программного обеспечения может иметь большое значение для этих вещей, но, похоже, есть много команд, которые надеются нанять фигуру, похожую на мессию, в качестве архитектора программного обеспечения, которая, мы надеемся, придет и решит все свои проблемы. Хотя нанятый архитектор программного обеспечения является важным сотрудником, самое важное, что ведет к хорошей архитектуре, - это хорошее планирование. Чтобы достичь этого, вам нужно знать, куда вы собираетесь.
Давайте рассмотрим сценарий, в котором заинтересованные стороны бизнеса (или продуктовая команда) описывают новый продукт, который они хотели бы создать, в данном случае лодку.
Первоначальное видение продукта:
Мы хотим построить лодку, на которой может ловить рыбу пара человек.
Команда разработчиков может вернуться с чем-то вроде этого, что, скорее всего, удовлетворит требования и станет хорошей надежной лодкой для потенциального клиента:
Итерация 1:
После получения отзывов от клиентов в лодку необходимо внести некоторые изменения. Клиенты спрашивают место, где можно было бы хранить рыбу, напитки и еду.
Команда разработчиков работает над расширением оригинального дизайна и добавляет на лодку кулер:
Итерация 2:
Команда утверждает, что только что добавленный кулер не остаётся холодным достаточно долго. Мы хотели бы иметь на лодке холодильник, чтобы мы могли хранить все холодным столько, сколько необходимо.
Разработчики не понимают, что значит «достаточно долго», но они решают установить на лодку переносную батарею и нагрудный холодильник:
Итерация 3:
Наши клиенты долгие дни ходили на рыбалку, и им нужна тень на лодке, чтобы защитить их от солнца.
Команда разработчиков добавляет к лодке тент. Это добавило бы сопротивления ветру на более высоких скоростях, но, учитывая размер лодки и небольшой мотор, маловероятно, что это будет проблемой:
Итерация 4:
Дни становятся короче, и нам нужны огни на лодке, чтобы, если мы все еще на воде, когда темнеет, мы могли видеть, куда мы идем.
Достаточно просто, чтобы команда инженеров могла починить, есть запасной штекер на аккумуляторе для подключения некоторых источников света (хорошее архитектурное решение!)
Итерация 5:
Теперь мы используем холодильник и свет, батарея на лодке слишком мала и разряжается. Им нужна сила, чтобы хватило на весь день.
У инженерной группы есть первая часть технического долга, с которой она должна справиться. Удаляют имеющийся аккумулятор и устанавливают более крупный с большей емкостью:
Итерация 6:
Лодка недостаточно быстра, поскольку мы добавили весь дополнительный вес. Сможем ли мы сделать это быстрее?
Инженерная группа устанавливает на лодку подвесной мотор большего размера, который обеспечивает лодке более высокую максимальную скорость. Это начинает заставлять купол раскачиваться на более высоких скоростях и заставляет фары перемещаться, когда купол движется.
Итерация 7:
Теперь, когда мы весь день на воде, нам нужно куда-то пойти в ванную.
Это сложный вопрос, но технически выполнимый ...
Итерация 8:
Лодка слишком мала, нам нужно иметь возможность перевозить больше людей
Команда инженеров разочарована этим запросом. Они говорят такие вещи, как:
«Им следует просто купить лодку у кого-то другого» и «Было бы неплохо узнать об этом немного раньше», но это настоятельная просьба, чтобы клиенты были довольны. Итак, разработанное решение получилось примерно таким:
Итерация 9:
Нам нужно место, чтобы вздремнуть, когда мы весь день в лодке или остаемся где-нибудь на ночь.
После этого запроса несколько инженеров покидают проект и переходят на работу к производителю лодок на ранней стадии, где они могут быть более вовлечены в процесс планирования с самого начала. Оставшаяся команда вместе разрабатывает решение, чтобы удовлетворить требования.
На этом этапе никто не счастлив.
Заказчик начинает искать другие варианты продукта, который соответствует его требованиям и изначально был разработан с учетом этих требований.
Команда инженеров просит поработать с техническим долгом, чтобы изменить архитектуру некоторых фундаментальных частей лодки, чтобы сделать ее более гибкой для нового варианта использования.
Команда разработчиков имеет дело с уходящей клиентской базой, и любые идеи, которые у них возникают, чтобы улучшить текущую ситуацию, встречают с большими инженерными сметами и далеко не идеальными предложениями.
Лучший путь вперед
Читая приведенный выше (драматический) пример, может показаться, что я выступаю за разработку стиля водопада. Хотя мне нравится осмотрительность и планирование, необходимые для осуществления разработки продукта в стиле водопада, быстро меняющаяся конкурентная среда, меняющиеся потребности клиентов и бизнес-требования для более быстрого вывода на рынок первой версии, приносящей доход, делают этот стиль разработки плохо подходящим для сегодняшнего дня. потребности.
Но создание близорукого MVP, а затем надежда продолжить оттуда по мере того, как вы придумываете новое направление и идеи, также сопряжена с серьезными проблемами.
Итак, каков путь вперед?
Лучший способ двигаться быстро, но при этом принимать правильные архитектурные решения - это заранее провести мозговой штурм между командами разработчиков продукта и инженерами относительно текущей дорожной карты и ее возможного развития в будущем. Если команда инженеров сможет лучше понять направление, в котором развивается продукт, они с большей вероятностью построят его таким образом, чтобы он был гибким там, где он должен быть, и прочным в своей основе (это где поможет архитектор).
Вот несколько общих вопросов, которые следует задать на этом этапе планирования, чтобы помочь принять лучшие решения:
- Каким вы видите развитие этого продукта через 3-5 лет?
- Сколько одноразовой работы мы создаем, чтобы просто выпустить первую версию на рынок? Это нормально?
- Имеет ли команда возможность переделать ключевые области продукта, если первая версия выйдет на рынок, чтобы сделать его более стабильным для широкого принятия клиентами?
- Какие конкретные решения мы принимаем сейчас, которые серьезно ограничат возможность изменения или расширения продукта на более позднем этапе?
- Есть ли в продукте какие-либо области, в которых мы можем позволить быструю итерацию в качестве опции (обычно на уровне пользовательского интерфейса), сохраняя при этом основу продукта устойчивой и стабильной?
- С инженерной точки зрения, есть ли области, которые, вероятно, будут заменены в будущем? Можно ли их отделить от основной инфраструктуры, чтобы обеспечить более чистую замену?
При наличии некоторого предвидения, планирования и открытого обсуждения того, в каком направлении будет развиваться продукт, команды могут принимать правильные решения на раннем этапе. Эти ранние решения заложат основу и направление на ближайшие недели, месяцы и годы. Не путайте скорость со скоростью. Хотя важно двигаться быстро, цель - это добраться куда-нибудь.
