Я был разработчиком около 10 лет. Я хочу знать, как я могу считать себя техником уровня артефакта? Как разработчик может перейти от разработки уровня кода к архитектору?
Я, очевидно, хочу подняться по технологической лестнице, и архитектура кажется привлекательной.
Вторым вопросом будет вопрос, как узнать о архитектуре приложения (большой картинке) с точки зрения структуры 3.5?
Любые рекомендации приветствуются.
Существует два критерия для архитекторов программного обеспечения:
(1) Вы должны называть себя одним.
(2) Вы должны убедить кого-то заплатить вам за программное обеспечение архитекторов.
Все остальное - просто леса. Если вы хорошо разбираетесь в разработке и планировании "большой картины", попробуйте продать себя в качестве архитектора при следующем поиске работы. Если кто-то покупает его, вы архитектор.
Рискуя подвергать себя нитпикеры и слово-парсеры,
Будучи "архитектором", вы должны иметь возможность разрабатывать программное обеспечение "Системы", состоящее из нескольких "компонентов", работающих вместе свободно связанными способами для решения довольно сложной бизнес-задачи и иметь возможность "вести" или "наставник" других разработчиков при построении указанной системы.
В дополнение к тому, чтобы быть экспертом в технологиях (-ях), необходимых для решения проблемы, это также означает, что вы должны понимать проблему бизнеса с точки зрения бизнеса и иметь возможность свободно говорить об этом как с экспертами бизнес-домена (используя их язык) и с разработчиками, которые будут создавать компоненты (на их языке)
Быть архитектором - не более, чем состояние ума. Есть потенциально плохие коннотации, которые сопровождаются статусом архитектора. В частности, потому что никто не может действительно ответить на вопрос: "Что такое архитектор?"
Прежде всего...
Если это так, это то, над чем нужно работать, я думаю... но как к нему можно работать, просто "составляя решения"? Практический опыт является обязательным условием и должен. У действительно хорошего программиста в конечном итоге есть хорошие навыки решения проблем. Хороший решатель проблем в конечном итоге знает, как создавать хорошие решения.
На мой взгляд, если сосредоточиться на том, чтобы стать отличным программистом, навыки решения проблем естественно начнут развиваться. Неизбежно, что это будет признано. Когда-то узнав, люди начнут просить мнения о лучших способах решения проблемы X. Когда кто-то начинает задавать эти типы вопросов, один из них становится архитектором.
В корпоративных организациях можно перейти к этому состоянию ума и потенциально иметь физическое название (и потенциальную плату), чтобы представлять это состояние ума. Но мы не должны забывать, что для этого требуется АКТУАЛЬНОЕ развитие хороших решений проблем. Это то, что в конечном итоге приводит нас к этому состоянию ума.
В конце концов, это просто слово, которое очень мало говорит о человеке, несущем титул.
Я думаю, вы спрашиваете, как продвигаться по карьерной лестнице внутри компании, и что обсуждает другой процесс, чем предыдущие комментаторы. Он также значительно отличается от одной компании к другой, но по-прежнему существуют навыки и практика, которые важны для всех.
Наиболее очевидная вещь - широта видения. Вы должны быть знакомы со всеми частями системы, которую вы обсуждаете. Это означает, что у вас должно быть желание работать в разных областях кода, даже если вы не знаете о них столько, сколько области, над которой вы работали. Вы должны быть готовы и в состоянии помочь другим людям с вещами, которые вы знаете. Это не означает, что вы нажимаете на них свою информацию, это означает, что они ответят, когда они спросят. Если ваш совет будет полезен, люди придут к вам. Очевидное место, чтобы начать с этого, помогает людям, которые взяли на себя ответственность за то, что вы недавно отошли от.
Архитекторы беседуют с людьми, работающими над другими проектами, потому что их спросили мнение об этом другом проекте и потому, что они выясняют, кто другие эксперты, и задают им вопросы, когда у другого человека больше опыта в области.И, конечно, код и проекты, которые вы оставляете, говорят за вас. Если ваш код не читается и надежный, то не имеет значения, сколько проектов вы посетили. Ваша собственная работа также должна быть впечатляющей.
Если вам нужно задать второй вопрос, вы еще не готовы стать архитектором.
Чтение и запись кода. Будьте универсальным, а не специалистом. Взгляните на обзор 3.5 и убедитесь, что вы сделали что-то во всех областях. Этого достаточно, чтобы распознавать проблемы и знать, где и кому искать ответы. Взгляните за пределы .net и посмотрите, как схожие проблемы решаются в других средах (cocoa, java, rails, glass, LAMP, delphi, flex)