mirror of
https://github.com/salmer/CppDeveloperRoadmap.git
synced 2025-12-17 04:24:39 +03:00
7.5 KiB
7.5 KiB
Middle C++
Кто это?
Это разработчик, который понимает технический контекст разработки и способен создать дизайн и решения для функционала внутри компонента/приложения даже в случае неполноты требований. Также имеет практический опыт работы на проектах и в рамках принятых бизнес-процессов.
В основном решает технические задачи, но, в отличие от джуна, способен делать это самостоятельно или под менторством синьора/тимлида.
Что ожидается по умению написания кода?
- Компилятор и язык его больше не пугают и практически не приносят сюрпризов, а если и приносят, то способен самостоятельно генерировать гипотезы, проверять их и копать вглубь
- Ориентируется в базовых концепциях языка и понимает, какие ещё языки существуют и чем они отличаются
- Пишет понятный и поддерживаемый код
- Знает базовые принципы дизайна и на их основе способен принять техническое решение
- Понимает не только язык программирования, но и его технический контекст, то есть понимает весь технический цикл, через который проходит код и ориентируется в инструментах, которые помогают этот цикл поддерживать:
- Написание кода (IDE, текстовые редакторы, практики программирования, качество кода)
- Хранение исходного кода и продуктов (системы контроля версий, пакетные менеджеры, серверы)
- Компиляция (компиляторы, системы сборки, библиотеки)
- Тестирование (фреймворки, стратегии тестирования)
- Доставка
- Выполнение на целевой системе
- Глубже понимает и знает базовую информатику (структуры данных, конечные автоматы, алгоритмы)
Что ожидается по общим навыкам?
- Способен самостоятельно ориентироваться в технической части проекта и принимать решения, которые вписываются в него
- Понимает, когда нужно остановиться, чтобы не переусложнить решение
- Имеет практический опыт работы в команде
- Способен формулировать и доносить идеи и мысли до других членов команды
- Имеет практический опыт работы по различным методологиям: Kanban, Agile/Scrum, Waterfall и т.д.
- Помогает другим членам команды
Рекомендации и советы
Про обучение
- Начинайте прокачивать софт-скиллы, если хотите вырасти в синьора. На синьорском уровне техническая экспертиза часто отходит на второй план, а на первый выходит умение вести диалог и договариваться. Хороший разработчик, не тот кто пишет много кода, а тот, кто понимает как решить проблему максимально просто и эффективно. В идеале - без написания нового кода, а ещё лучше - если ещё удалится пара десятков/сотен строк.
- Стадия миддла самая энергозатратная с точки зрения обучения. От вас требуется не только прокачивать технические скиллы, но также навыки коммуникации и погружение в проблемы бизнеса. Это значит, что вам требуется одновременно развиваться в нескольких направлениях одновременно. Уделяйте внимание в равной степени как "хард", так и "софт" скиллам.
- Должное внимание "софт" скиллам также повышает вероятность того, что вы быстрее станете востребованным профессионалом на рынке. Вы можете попытаться стать узконаправленным техническим специалистом и игнорировать коммуникативные навыки, но, во-первых, компаниям нечасто нужны подобные кадры в больших количествах, во-вторых, вам придется конкурировать с лучшими из лучших. Если вы действительно готовы состязаться с лучшими специалистами на рынке, то смело идите вперед, но все же рекомендуем подумать о диверсификации своих навыков.
Про опыт
- Основная ловушка для многих мидлов: фанбойство по технологиям, фреймворкам, внедрением паттернов или подходам к разработке. Постарайтесь прагматично подходить к выполнению задач на проекте. Не нужно пытаться затянуть все последние новинки, только чтобы поиграться с ними или ради строчки в резюме. На этом этапе очень велик соблазн проявить свое мастерство через обилие технологий или оверинжиниринг.
- Если вы действительно считаете, что проекту нужна новая библиотека или фреймворк - обсудите это с синьором/тимлидом. Предложите им попробовать создать прототип, где сможете проверить их в действии прежде чем втягивать в проект. Пожалуйста, никогда не втягивайте их в обход всей команды или втихаря! Для вас - это развлечение, но для проекта/тимлида это станет головной болью в будущем, т.к. это повысит стоимость поддержки проекта и принесёт неожиданные проблемы.