“Что скажешь?”. Когда мне первый раз задали этот вопрос на ревью спринта, у меня не нашлось ответа. Тогда я был начинающим разработчиком, и он просто поставил меня в тупик. Я что-то бормотал, начал ерзать и смотрел на руководителя с намеком о помощи — слов найти никак не удавалось.
На тот момент я только закончил свой первый проект от начала до конца и был горд этим. Но когда учредитель задал мне вопрос “Что скажешь?”, у меня просто не нашлось ответа.
Я знал, как работает мой проект и на этом все. У меня не было представления, какую роль он играет в системе. Мне ничего не было известно о контексте.
Тогда я не осознавал, что это вообще важно. Мне предоставили список задач, и я реализовал их в коде. Мне и в голову не приходило, что его написание являет собой лишь малую часть всего процесса разработки ПО.
Если вы хотите вырасти из отдельного участника в архитектора решений — необходимо изучать контекст. Перед вами обязательно должна быть общая картина. Здесь уже речь идет не о написании кода, а о понимании взаимодействия систем.
Первые шаги в мире архитектуры могут быть очень неловкими. Откуда стоит начинать? Как вообще можно выработать навыки, необходимые для этого? На деле же все оказывается не столь сложно, как выглядит поначалу.
Абстрагируйтесь
Как разработчик ПО, вы получаете задания писать код для решения конкретных задач. В зависимости от предыдущего опыта у вас может быть или не быть понимания бизнес-контекста вносимого вами изменения.
Чтобы начать перестраивать модель мышления с разработчика на архитектора, нужно взглянуть на все со стороны, абстрагироваться. Спросите себя: “Какое влияние вносимое мной изменение окажет на приложение?”
Выделите элементы, которые определяют работу этого приложения. Состоит ли оно из нескольких взаимодействующих модулей? Серверное это приложение или клиентское? Является ли оно многоуровневым?
Вашей целью будет понять, как все элементы взаимодействуют друг с другом. Как только вы выясните схему работы приложения, абстрагируйтесь дальше.
Какую роль это приложение играет в общей экосистеме? Если ваша компания предлагает несколько продуктов, то является ли оно частью их набора? Взаимосвязано ли оно с другими приложениями? Как оно используется, и какое от него ожидается поведение?
Представьте, что код, который вы пишете, это поршень в двигателе автомобиля. Он выполняет определенную функцию, помогая двигателю работать. Сам по себе он бесполезен, но в связи с остальными частями мотора его значение огромно.
Ваше приложение — это двигатель. Он состоит из движущихся частей, правильная работа которых зависит от их правильного взаимодействия. Но и двигатель сам по себе не особо полезен.
Здесь в виде аналогии можно представить экосистему и набор предлагаемых компанией продуктов как машину. Ваше приложение выступает в ней в роли двигателя. Это всего лишь часть, но она необходима для работоспособности всего автомобиля.
Продолжая абстрагироваться, вы поймете, что понимание общей картины необходимо для успешного становления архитектором решений. Продолжайте расширять свой обзор, пока он не охватит весь окружающий ландшафт.
Научитесь спрашивать “Почему?”
Здесь я позволю себе сделать предположение, что, будучи разработчиком ПО, вы стремитесь разбираться в том “Как?” и “Почему?” все работает. Это отлично, потому что является необходимой чертой хорошего архитектора решений.
Вам не доводилось смотреть ТВ-шоу, где маленький ребенок доводит родителей, то и дело спрашивая: “Почему? Почему? Почему?”. Если доводилось, то у вас есть идеальный пример того, что нужно делать.
Однако понять, как все работает — это только половина дела. Вторая состоит в том, чтобы разобраться, почему все делается именно так.
Почему поршень важен, и как работает двигатель? Почему он был спроектирован именно такой формы и расположен именно в этом месте?
Вопрос “Почему?” является ключом к переходу от понимания к полноценному осмыслению. Если взглянуть на систему, разработанную архитектором, обладающим только пониманием того, как все работает, это станет очевидно.
Понимание взаимодействия элементов даст вам достаточно информации для решения задачи. Вы сможете брать представленные вам компоненты и объединять их в единую структуру. Вы сможете находить комплексные решения для комплексных задач.
Но если вы поистине разберетесь во всех внутренних особенностях имеющихся компонентов, то сможете полностью осмыслить принципы их работы и спроектировать систему, качество которой возрастет экспоненциально.
Осмысление открывает двери для креативных и в то же время простых решений.
Связывайте задачи с известными решениями
Став архитектором решений, вы уже не будете все свое время посвящать исключительно написанию кода. Теперь уже будет недостаточно просто разработать решение, реализовать его и переходить к следующему.
Как только вы закончите проектирование, потребуется всем его объяснить. Разработчикам, учредителям, отделу реализации, поддержке, можете продолжить список — все эти люди должны понимать ваше решение.
С учетом этого навыки общения становятся чрезвычайно важными. Способность говорить уверенно и эффективно становится вашим самым мощным инструментом.
Лично я преуспел в развитии навыка донесения мысли с помощью метафор. Связывание ваших идей с простыми знакомыми другим людям понятиями упрощает передачу основного замысла.
Если вы сможете эффективно доносить сложные технологические решения технически неподготовленной аудитории, то вы созданы для этой работы.
Но связывание задач с существующими решениями не упирается в устную передачу. Здесь также присутствует элемент заимствования.
Под заимствованием я понимаю использование идей, приближенных к окружающей нас жизни. Нет нужды снова изобретать колесо. Есть тысячи паттернов и примеров, которые можно непосредственно применить для вашего проекта.
Если вы создаете приложение, управляющее загрузкой и обслуживанием файлов, почему бы не обратить внимание на Google Drive и подумать, какую функциональность этого сервиса можно позаимствовать?
Или если, например, вы проектируете систему, генерирующую рабочее расписание сотрудников, то почему бы не поискать сопутствующие идеи у Outlook или Lotus Notes? Это очень успешные приложения, которым будет только на руку, если вы позаимствуете у них проектные паттерны.
Будучи архитектором решений, важно понимать, что не все ваши идеи обязательно должны быть оригинальными. Можно совмещать компоненты из разных решений в единую структуру собственного приложения. Именно это и характеризует успешного специалиста.
Черпайте идеи отовсюду!
Смотрите наперед
Великие архитекторы решений живут в будущем. Они проектируют системы для сегодняшнего дня, но с учетом выгодного влияния на развитие компании в дальнейшем.
Будьте внимательны, когда принимаете “безвозвратные” решения (решения, которые нельзя отметить или исправить. прим.). Если вы примите их сейчас, то будете вынуждены жить с их последствиями в будущем. Лучше всего стараться откладывать такие решения до последнего ответственного момента.
Когда вы проектируете систему, определите, как вы себя позиционируете. Закладываете ли вы в нее возможность дальнейшего модулирования? Можете ли вы оказаться в замкнутом сценарии, из которого не получится найти выход?
Возвращаясь к аналогии с машиной, собираетесь ли вы создать Ford Pinto или Ferrari?
Помните, что при переходе из разработчиков в архитекторы необходимо понимание общего плана. В каком направлении стоит стремиться работать? Каковы цели компании на ближайший год, пять или десять лет?
Не позволяйте сегодняшним недочетам существенно повлиять на ваш план. Пусть они влияют на проект. Учитесь на своем опыте. Но помимо всего прочего, убедитесь, что своей работой расширяете возможности компании в будущем.
Практикуйте
Одна из лучших черт разработчиков ПО состоит в том, что они любят свое ремесло. Я не встречал разработчика, который бы не имел хотя бы один сторонний проект. Мы любим работать и учимся с удовольствием.
С учетом этого, если вы хотите практиковать проектирование решений, то занимайтесь этим в свободное время. Возьмите в качестве образца уже существующую систему, например любимый сайт, и начните постепенно разбираться в ее архитектуре. Воспользуйтесь обратным подходом.
А еще лучше, если они у вас еще не задокументированы, составьте схемы приложений, над которыми работаете в основное время. Они непременно пригодятся компании и помогут вам углубить свое понимание.
Есть и другие варианты освоения профессии архитектора решений. Можно, например, пройти сертификацию AWS. Получение сертификата повысит вашу ценность как разработчика, а также расширит ваше понимание специфики этой работы.
Используйте каждую доступную возможность. Найдите наставника. Есть немало людей, которые с удовольствием помогут вам добиться успеха.
При этом также очень важно получать от всего процесса удовольствие! Проектирование систем — это невероятно творческая деятельность, которая привносит радость в мою повседневность. Уверен, что и для вас она окажется тем же.
Удачи!
Читайте также:
- 10 полезных инструментов для разработчика
- Лучшие приёмы HR от Google
- Почему я перешёл на Linux после 10 лет работы на Windows
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Allen Helton: How To Switch From Software Developer to Solutions Architect
