Что делают успешные архитекторы программного обеспечения
Меня никогда не волновала должность архитектора программного обеспечения, прежде всего потому, что я думал, что это всегда было частью моей работы с тех пор, как я начал писать код.
Я проектирую, архитектор, кодирую, отлаживаю, тестирую, развертываю.
Оглядываясь вокруг, я не вижу много вакансий для отладчика программного обеспечения?
Мой опыт работы в роли архитектора программного обеспечения в ряде небольших и крупных проектов был в лучшем случае смешанным, где он варьировался от выполнения только архитектуры и дизайна (без кодирования) и/или выполнения всех недостающих функций. работа в команде, ПОТОМУ ЧТО все, что я делал, было архитектурой и дизайном, поэтому, как только все было спроектировано, у меня должно было быть много времени, верно?
Расширяя название, есть множество различных префиксов, которые имеют значительный вес, где бы вы ни работали, — Enterprise, Chief, Solution, Product и т. д., и т. д. С этими добавленными префиксами возникает вопрос, что Software Architect может и делает больше, чем просто архитектор.
Я всегда чувствовал, что существуют некоторые неправильные представления об этой роли и о том, что великие архитекторы программного обеспечения делают в этой роли, что действительно определяет ее успех.
Архитектор кодирования
В любой из ролей, которые я выполнял в архитектуре программного обеспечения, я всегда называл себя архитектором кода — в первую очередь потому, что нет лучшего чувства, чем претворить в жизнь план, который вы придумали, и доказать его.
Должны ли мы расширять наши услуги?
Сделал ли этот шаблон то, что обещал?
Насколько далеко мы отклонились от наших первоначальных идей?
Как строительство дома, это сплошные чертежи, коробки и пунктирные линии, пока вы не войдете туда, не запачкаете руки и не поймете, что это нечто большее. Вы осознаете ограничения API, видите, как масштабируется ваше решение, и понимаете, что работает, а что нет.
Это доказательство в пудинге, и это то, что значительно помогает последующим проектам Архитектора.
Вы учитесь, делая, а не получая обратную связь о том, как все прошло.
Это еще не все
В недавнем проекте, в котором я участвовал, все, что им было нужно, это красивые картинки, которые могли бы показать, насколько отличным будет приложение. Им нужно было тактильное доказательство того, что они создают «корпоративное» приложение с какой-то привлекательной рыночной архитектурой для продажи клиенту.
Я не мог этого сделать.
Дизайн ради дизайна, а не ради самого продукта. Мы отступили и дали им некоторые концептуальные элементы высокого уровня, а затем работали над компонентами более низкого уровня с командой разработчиков, над вещами, которые имели значение — сервисами, каналами связи, тем, что происходит с данными в пути, какие протоколы безопасности должны быть защищены. быть поставлен на место. Все эти концепции были выброшены на этом этапе.
И все они имели значение.
Я хотел снова и снова расклеивать их по доске и говорить «готово», но этого было недостаточно — мне нужно было брать значки, цветовые схемы и шрифты, чтобы они выглядели красиво, — и именно здесь я потерял интерес к роли. .
Он стал больше о том, как он выглядел, и меньше о том, что это было.
Я люблю архитектуру программного обеспечения на командном уровне, когда мы все находимся в одной комнате, передаем маркеры, записываем идеи и делаем то, что мы создаем, гораздо более масштабируемым, надежным, производительным и безопасным. Все остальные диаграммы могут подождать еще день (посижу и подожду, все в порядке).
Как архитектору, мне нравится видеть беспорядочные картинки, потому что именно за ними я хочу следить, именно они показывают суть того, что мы строим, и их никто не может просмотреть.
Сообщите о реализации
Мы думаем об архитектуре программного обеспечения как о чисто технической реализации своей роли — никакого управления людьми, никаких встреч с людьми, только вы, дизайнер и немного кода. Но это далеко не так, как архитектор, вы все время находитесь в пути, делитесь своим видением, доносите информацию, объясняете людям, почему вы приняли решения и каково их влияние, а затем следите за тем, чтобы они приверженность этому видению и следование ему.
У вас может не быть непосредственной команды, но к вам все время приходит множество непрямых людей, чтобы получить рекомендации по реализации, что делать дальше и что им нужно от вас. И это не все легкие разговоры, они требуют времени.
Хорошие архитекторы знают, что нужно, чтобы продать свое видение и заставить людей поверить в него. Они знают API и могут распределять между техническими и концептуальными аспектами, чтобы заинтересованные стороны и пользователи были уверены в том, что они получают.
Если вам нужен кто-то в этой должности в вашей команде, сфокусированный на дизайне, сфокусированный на общей картине либо на уровне решения, либо на уровне предприятия, я полагаю, что у вас есть ряд движущихся частей в вашей системе, которые необходимы и жизненно важны для вашей работы.
Но если вам нужна эта роль, не забивайте их другими вещами, убедитесь, что они могут разговаривать с людьми, напомните им, что дело не только в картинках и искусстве возможного, и что то, что они делают, также должно быть укоренено в практично, сегодня, так, как нужно.
Архитекторы кода, общаются с командой на всех уровнях и сосредоточены на том, что делается сейчас, не продавая изображения, это те архитекторы, которых вы хотите видеть в своей команде, и это то, что делают успешные архитекторы.
Хотите еще? Ознакомьтесь с моей книгой Code Your Way Up — она доступна в электронной или мягкой обложке на Amazon (Канада и США). Подпишитесь на нас в Твиттере @Codeyourwayup и узнайте больше о наших программах Software Leadership здесь.
