Программисты, какие навыки вам нужны, чтобы стать архитектором?

Архитектура
Программисты, какие навыки вам нужны, чтобы стать архитектором?

обрати внимание на" Это ветеран брата」，赋能程序人生！ КнигаУказатель предсерийных статей:

  1. Почему программисты должны разбираться в архитектуре?
  2. Что такое архитектура, вы знаете?
  3. Какие бывают архитектуры и как выбрать?
  4. Чем занимаются архитекторы, вы знаете?

Архитектор,Основное направление для наших программистов сражаться с монстрами и апгрейдиться, это не то что некоторые навыки можно получить подав заявку на обучающий класс. Есть много навыков, необходимых для того, чтобы быть компетентным в архитектурных работах, как сложных, так и мягких. Как говорится: с одного укуса не потолстеешь. От программиста до архитектора это не может быть достигнуто за одну ночь. Это сложный процесс постепенного и постоянного улучшения. На каждом этапе есть навыки, которые необходимо освоить на каждом этапе, и существует последовательность между несколькими навыками. Если вы хотите как можно быстрее трансформироваться и повыситься до архитектора, вы должны сознательно сохранить эти навыки в своей повседневной работе.Далее брат-ветеран поделится своим личным опытом.

架构师之硬技能

1. Тяжелые навыки

В отличие от продуктов, управления и других направлений, которые в большей степени полагаются на общие навыки, относительно легко начать работу с технических направлений и перейти к продуктам или управлению. Однако перейти от продукта или управления к архитектуре сложно, архитекторы должны начинать с позиций разработки и тестирования, постоянно повышать профессиональные навыки и накапливать практический опыт в своей работе, начиная с модуля, заканчивая подсистемой, всей системой и т.д. наконец, к множественным системам, это пошаговый процесс улучшения сложных навыков, и его также можно рассматривать как построение сложных навыков архитекторов «точек, линий и поверхностей».

1,1 балла

Брат-ветеран, когда я впервые пришел в отрасль, я был инженером-разработчиком. Меня назначили в группу проекта автоматизированной тестовой платформы вместе с несколькими другими выпускниками. Вся система была разработана старшими коллегами в отделе. Мы отвечали за разработку нескольких модули одной из подсистем. На этом этапе я в основном сосредотачиваюсь на детализации функций, классов и модулей.Чтобы хорошо выполнять свою работу, я должен изучить язык программирования C/C++ и быть знакомым с использованием библиотек кода, таких как Visual C++ MFC. и Сокет. Мы также проводили еженедельные встречи по обзору кода и приглашали коллег комментировать написанный нами код.В то время я был молод и энергичен, и получение положительных или отрицательных комментариев было для меня отличной мотивацией. После этого этапа опыта мои навыки программирования значительно улучшились, я также выработал более стандартизированную привычку кодировать и научился проектировать функцию, класс и модуль.

Этот проект занял около двух лет до и после, а следующие полгода я также занимался некоторыми вещами, связанными с продвижением системы и обучением. Позже мы запустили сценарий автоматизированного тестирования, используя язык сценариев Python в качестве сценария автоматизированного тестирования. В этом проекте я отвечал за предварительные исследования механизма интерпретации сценариев Python и разработку подсистемы агента тестирования. Опыт этого проекта заставил меня перейти к детализация подсистем. Мне нужно рассмотреть, какие обязанности у этой подсистемы в системе в целом и как она взаимодействует с другими подсистемами или тестируемой системой. В то же время я также отвечаю за дизайн этой подсистемы, определяя, из каких модулей она состоит, какие классы содержатся в каждом модуле и так далее.

На этом этапе у меня есть способность и уверенность в создании одной подсистемы, на задней части работы, которую я также использую различные типы языков программирования, чтобы построить слишком много различных типов подсистем, но они на самом деле укрепляют способность строить Одиночная точка дерева навыков включает в себя: операционные системы, языки программирования, контейнер для прикладного контейнера, рамки развития, многопоточность.

1.2 строки

Для системы несколько большего масштаба она неизбежно делится на несколько подсистем, и требуется связь между подсистемами или с внешними системами, что равносильно соединению двух изолированных точек, т. е. соединению точек в линию. Этот процесс отличается от навыков, необходимых для разработки отдельных подсистем, которые требуют знаний и навыков, связанных с сетевым программированием. В те годы, когда мы с братом-ветераном только начинали работать, веб-приложения еще не стали основной формой приложений, архитектура браузер/сервер (B/S) еще не появилась, а протокол HTTP не получил широкого распространения. (C/S), наиболее важным протоколом связи является IP/TCP, на данном этапе я накапливаю знания и навыки, связанные с сетевым программированием.

Как только мы захотим разрабатывать клиентские или серверные программы, нам нужно быть знакомым с сетевым программированием Socket, включая привязку прослушиваемых портов, прием запросов на подключение, одновременную обработку запросов и т. д., а также написание всего этого с нуля. мне позже понять механизмы сетевого взаимодействия.Очень полезно. Чтобы удовлетворить требования взаимодействия между подсистемами, нам необходимо настроить специальный протокол прикладного уровня на основе протокола IP/TCP, в том числе сформулировать двухуровневую структуру заголовка сообщения и тела сообщения, хотя это проще, чем HTTP, FTP, SMTP и другие протоколы, но этот опыт дал мне глубокое понимание принципов реализации протоколов прикладного уровня, таких как HTTP. Кроме того, нам также необходимо учитывать группировку пакетов, когда содержимое пакета слишком длинное, потерю пакета и повторную передачу, когда сеть ненормальна, а также кодирование и декодирование содержимого пакета.

Поэтому программистам, заинтересованным в развитии по технической линии, необходимо восполнить этот навык. За почти 15 лет технической карьеры мы с братом-ветераном решили многочисленные существующие сетевые проблемы, многие из которых связаны с системным взаимодействием и связью.С помощью различных инструментов захвата и анализа сетевых пакетов мы, наконец, можем найти проблему. Основной причиной является неправильное использование сетевого протокола, поэтому я рад, что у меня был такой опыт в моей прошлой работе.

С бурным развитием Интернета веб-приложения стали самой важной формой приложений, и в то же время HTTP, более удобный для пользователя сетевой протокол связи, стал самым популярным интерактивным протоколом. В процессе перехода от разработки приложений клиент/сервер (C/S) к разработке приложений браузер/сервер (B/S), брат-ветеран, я посвятил время изучению протокола HTTP, пониманию принципа его работы и механизма управления, особенно Функция каждого поля в заголовке протокола, включая метод запроса, формат кодирования, механизм тайм-аута, механизм кэширования и т. д. Самое впечатляющее, что доктор Рой Томас Филдинг опубликовал статью REST «Архитектурные стили и проектирование сетевых архитектур программного обеспечения», которая дала мне новое понимание HTTP.Знайте, эти знания и навыки очень помогают для понимания и освоение сервис-ориентированной архитектуры в эпоху облачных вычислений.

Помимо IP/TCP и HTTP, считаю необходимым освоить протоколы, относящиеся к Message Queue, этот тип протокола больше подходит для построения системы событийно-управляемой архитектуры, которая поддерживает не только синхронизацию, но и асинхронность. Раньше я руководил системой мобильного интернета, в которой подсистема отвечала за ведение различных моделей терминалов мобильных телефонов и информации об устройствах. Партнерам нужно было своевременно получать самую свежую информацию из этой подсистемы. Изначально мы внедрили ее по опрос и извлечение по протоколу HTTP.Однако с увеличением количества партнеров и частоты обновления информации этот механизм синхронизации информации сталкивается с узким местом.Позже мы элегантно решили эту проблему, внедрив промежуточное ПО очереди сообщений.

1.3 Лица

Начинайте практиковаться с точек и линий.Со все большим количеством связей в конечном итоге будет сформирована плоскость, то есть распределенная система.Это та площадка, которую должны пройти наши программисты на пути к архитекторам. Сначала мы использовали Интернет только для публикации поисковой информации, а затем наше мгновенное общение и социальное взаимодействие переместились в Интернет. Позже такие вещи, как покупки и путешествия, также можно было делать через Интернет. Теперь все, что связано с нашей едой , одежда, жилье и транспорт используются Интернетом, что эквивалентно тому, что виртуальный мир становится все более и более сложным. Изначально сложность разрабатываемой нами программной системы была еще ограничена, в лучшем случае она была разделена на несколько подсистем, а количество внешних систем, которые необходимо было ассоциировать и взаимодействовать, также было очень ограничено. Однако по мере того, как бизнес становится все более и более изобилующим, сложность отдельной системы резко возрастает, а также появляется множество связанных с ней внешних систем, которые постепенно превращаются в перекрестную сеть, которую мы называем «лицом». Как поддерживать сложность в такой сложной сети и гарантировать, что система по-прежнему соответствует атрибутам качества, таким как простота использования, производительность, надежность, стабильность, безопасность и т. д., что требует от программистов практических навыков, связанных с распределенными системами.

Брат-ветеран, в процессе разработки мобильных интернет-систем я столкнулся с более сложным сценарием: в то время мы хотели построить экосистему, аналогичную Apple App Store, система, за которую мы отвечали, состояла из шести или семи подсистем. Системное стыковочное взаимодействие многих вышестоящих и нижестоящих партнеров. Если соединение с каждой внешней системой принимает свои собственные стандарты, по мере увеличения количества систем доступа сложность соединения в конечном итоге выйдет из-под контроля. Кроме того, типичные бизнес-сценарии, такие как покупка подписки на приложение, требуют взаимодействия нескольких систем, что включает в себя распределенные транзакции, и обеспечение согласованности данных является большой проблемой. Согласно общепринятой логике, по мере того, как сложность системы продолжает расти, вероятность простоя системы будет увеличиваться, но пользователи все еще надеются, что система сможет обеспечить обслуживание в течение 7*24 часов без тайм-аута или сбоя обслуживания. ситуациях, это вызов, принесенный "лицом".

С этого момента у меня появилась возможность изучать и практиковать распределенную архитектуру. Самой ранней из них является сервис-ориентированная архитектура SOA, то есть технические стандарты, такие как веб-служба и SOAP.Оглядываясь назад, этот стек технологий был слишком тяжелым и громоздким, но в то время распределенные системы были новым вызовом для всей отрасли. Решения предлагаются традиционными софтверными гигантами, такими как Compaq, HP, IBM, Lotus, Microsoft, SAP. Он стандартизирует каждый сервис в распределенной системе через язык описания веб-сервисов WSDL, а затем стандартизирует взаимодействие между сервисами через простой протокол доступа к объектам SOAP.С определенной точки зрения, чем больше сотрудничество, тем более унифицированным должен быть стандарт. , и спецификации.

Тем не менее, традиционные софтверные гиганты редко имеют опыт работы с Интернетом на передовой.В отличие от BAT, они очень хорошо чувствуют проблемы распределенной системы Интернета.Alibaba на практике вывела более легкий, чем веб-сервис и SOAP. Dubbo, он также опирается на теорию сервис-ориентированной архитектуры SOA, но больше ориентирован на онлайн. Этот опыт работы дал мне систематическое понимание распределенной архитектуры.Хотя в последние годы распределенная технология эволюционировала от сервис-ориентированной архитектуры SOA к микросервисной архитектуре MicroService, а техническое промежуточное программное обеспечение было заменено с Dubbo на Spring Cloud, я все еще обладаю этой совокупностью знаний. может применяться для понимания новых технологий.

2. Мягкие навыки

В чем разница между мягкими и жесткими навыками? Брат-ветеран, я думаю, какое ремесло человек полагается есть, тогда навыки, связанные с этим ремеслом, являются жесткими навыками, а навыки, которые помогают сложным навыкам создавать большую ценность, являются мягкими навыками, которые аналогичны требованиям для «Т». -образные таланты.Необходимо иметь достаточно превосходные и первоклассные основные навыки атаки, а также множество комплексных навыков. Хард скиллы очень важны, я думаю никто не будет возражать против этого, но многие люди не осознают важность гибких навыков. Для техников, от разработки к архитектуре, от архитектуры к техническому директору, от разработки к продукту или управлению, будь то продвижение или трансформация, мы укрепляем профессиональные навыки, увеличивая долю социальных навыков, даже первоначальных профессиональных навыков. мягкий навык, а мягкий навык, который изначально был вспомогательной ролью, стал жестким навыком. Далее я расскажу о том, какие soft skills важны, основываясь на своем личном опыте разработки архитектуры трансформации:

  • общаться:По сравнению с инженером-разработчиком, должностные обязанности архитектора определяют, что ему нужно общаться с большим количеством заказчиков выше и ниже по течению, а требования к коммуникативным навыкам намного выше.В конце концов, разные роли имеют разные способы мышления и точки зрения, и архитектор должен знать как использовать разные Общаясь и взаимодействуя с этими ролями и думая с другой позиции, мы можем обнаружить реальные потребности, а затем использовать профессиональные навыки, чтобы сбалансировать потребности всех сторон и, наконец, вывести архитектурное решение, которое удовлетворит все стороны. .
  • письмо:Как разработчик, мой основной результат — это код. Хотя иногда пишутся некоторые технические документы, обычно это технические документы для самостоятельного чтения или инструкции по эксплуатации продукта для использования. После преобразования в архитектуру доля моего написания кода уменьшилась.Чтобы все заинтересованные стороны могли понять и утвердить мой план архитектуры, в дополнение к устным объяснениям, самое главное - полагаться на техническое письмо, а документы, написанные другим, являются совершенно чистыми записями.
  • дизайн:Будь то устное общение или распространение документов, независимо от того, насколько хороши язык или навыки письма, это не может сравниться с легендой дизайна.Информация, содержащаяся в легенде, многомерна, более интуитивно понятна и проста для понимания. Обычно я рисую дизайн перед написанием технического документа.Процесс рисования дизайна - это процесс выпрямления идей.На этой основе становится все легче и легче организовать текст или язык, что эквивалентно смотреть на картинку и говорить.
  • речь:Власть и неавторитетное влияние, архитекторы в основном полагаются на неавторитетное влияние при выполнении своей работы. Между архитекторами и различными заинтересованными сторонами нет подчиненных отношений.Для того, чтобы команда и партнеры признали и реализовали ваш архитектурный замысел, вы должны полагаться на свою профессиональную способность убедить другую сторону. В прошлом школьном образовании или процессе роста мне самому не хватало накопления этого аспекта, и чтобы успешно трансформироваться в архитектора, я сознательно тренировался и совершенствовал свои способности в этой области.

Подводя итог, чтобы хорошо работать на новой платформе архитекторов, нам необходимо улучшить наши возможности ввода, проектирования и вывода. В прошлом мы получали информацию из внешнего мира, в основном, читая документы, но теперь нам необходимо усилить трехмерную и разнонаправленную коммуникацию. Что касается вывода, наша форма вывода в прошлом была слишком простой, и теперь нам приходится осваивать мультимедийные методы, такие как текст и речь. Конечно, ядром являются профессиональные навыки архитектурного проектирования, центр ввода и вывода.

3. Система знаний

Я поделюсь им здесь сегодня. Ветеран поделится расширенным руководством от программистов до архитекторов в будущем, включая карты программного обеспечения и навыков, которые необходимо освоить на каждом этапе (как показано на карте заголовка). обратитесь к статье:Есть ли короткий путь от программиста до архитектора?Если вам интересна эта тема, не забудьте сначалаобрати внимание на Ой!

Нелегко настаивать на оригинальности. Если вы считаете, что это ценно, пожалуйста, переместите палец и нажмите следующее "👍», чтобы больше друзей могли его увидеть, а у ветерана было бы больше мотивации продолжать делиться. Кроме того, я поделюсь своим опытом в планировании карьеры, собеседованиях, повышении квалификации и построении влияния в будущем.обрати внимание наЭта колонка или Фальшивая буква принцессы»Брат ветеран ИТ"!

微信公众号「 IT老兵哥 」


Мягкие навыки - Популярные статьи: (первый публичный счет)

  • Как сохранить «код» на пути к наращиванию влияния? (новый)
  • Наступает 2020 год, а ваш 2019 год запечатан? (новый)
  • «Причудливая» глубина увольнений, знаете ли вы?
  • Столкнулись с увольнениями, как пережить психологический кризис?
  • Раскрыта стратегия программиста «обращаться за поддержкой»


Hard Skills - Популярные статьи:


Категории