Я потратил более 3 лет на программирование dotnet (С#) и теперь хочу посмотреть в фреймворк/дизайн.
Я решил стать хорошим архитектором в будущем. Я знаю, что для этого мне нужно много работать. Я готов это сделать.
Что я не знаю, с чего начать?
Не могли бы вы быть любезными, чтобы помочь мне в правильном шаге.
Спасибо
Обновление: обе ссылки сломаны, я попытаюсь найти какой-то запасной контент, но пока эта страница имеет список разных типов архивов, FWIW: http://en.wikipedia.org/wiki/Systems_architect
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Это зависит от того, что вы называете "" Технический архитектор", а также о том, куда вы хотите пойти. Кроме того, ваш опыт (насколько вы описали его) связан с программированием/программным обеспечением, поэтому термин "Техническая архитектура" может быть не совсем таким, каким вы считаете.
Как я понимаю, технический архитектор больше интересуется стандартами, а не архитектором программного обеспечения, который больше разбирается в коде и шаблонах проектирования.
Мой общий совет для вас таков:
Что нужно учитывать на пути:
FYI, Aspiring Architects" - моя любимая тема.
Обновить январь 2017 - наконец, обновил неработающую ссылку (контент, написанный в 2010 году!), и, кроме того, добавил новую информацию о том, как определить architecture-roles.
Реальные здания, строящие реальное здание, будут проводить большую часть своего времени, исследуя строительный код, управляя планирующими полномочиями и обсуждая затраты с инвесторами.
Таким образом, архитектор решений потратит большую часть своего времени на то, чтобы решение соответствовало различным стандартам безопасности и развития на сайте, соответствовало корпоративным дорожным картам и т.д., а также обсуждало бюджеты и т.д. и связывалось с другими командами, определяющими интерфейсы и планы синхронизации.
Реальный архитектор редко получает шанс стать Ричардом Роджерсом и построить существенное здание на новом сайте для клиента с глубокими карманами, вместо этого они создают дома для кулинарных резаков для спекулятивных разработчиков, добавляют расширения к существующим зданиям или реконструируют старые здания для новых целей.
Таким же образом ИТ-архитектор будет тратить большую часть своей профессиональной жизни на улучшение или замену частей существующей системы в ограниченном бюджете, ограниченный таймфрейм и быть сильно ограничен существующей технологией.
Итак, я советую понять, какие стандарты и процедуры вы работаете, и попытаться понять, как он работает, и использовать жаргон, как он используется в вашей организации. Если вы были хороши программистом, вы уже знаете все необходимые технические материалы.
Я лично узнал больше всего, когда реорганизовал большую унаследованную систему в модульную архитектуру, где вы разбиваете старый код на слои и склеиваете его вместе с некоторыми инъекциями зависимостей или другими абстракциями, основанными на общих шаблонах архитектуры. Как вы видите, какие распространенные ошибки и почему имеет смысл приложить усилия к модульной системе с самого начала.
Я лично не позволил бы кому-либо принимать какие-либо большие архитектурные решения без опыта работы менее 10 лет.
Я считаю хорошим техническим архитектором вы должны быть хорошей командой по шаблонам проектирования, WCF, WPF, средствам отчетности, С#, SQL Server и т.д.