Содержание:
Привет! Меня зовут Максим Морев, я эксперт Центра разработки и техлид проекта «Цифровой рубль». Мой путь от обычного студента до руководителя бэкенд-разработки в банке занял 12 лет и был не самым легким. Но теперь благодаря этому опыту я могу помочь новичкам быстрее расти в профессии. В этом тексте я собрал то, что хотел бы знать в начале карьеры.
Почему я хочу поделиться своим опытом
Еще в институте я был фанатом Linux, собирал его на дискете. С третьего курса работал системным администратором, а позже — фулстек-разработчиком в корпорации. Потом начал изучать Java и стал Java-разработчиком на позиции джуниора.
Через некоторое время я решил, что корпорации — это не для меня. Занимался тем, что привлекало, изучал совершенно разные вещи — от дизайна до истории искусств — и работал в интересных для меня стартапах.
Затем снова вернулся в корпорацию уже на позицию мидл-разработчика Java. В это же время проникся идеей Agile, подписал Agile Manifest и стал продвигать его в командах, где работал.
Постепенно дорос до сеньор-разработчика. В этот момент узнал о Software Craftsmanship — подходе к разработке как к мастерству. Это расширило границы, которые я видел для себя. Сейчас совмещаю роли скрам-мастера, тимлида, архитектора решений. Одновременно продвигаю и популяризирую идею Software Craftsmanship, подходы TDD (Type Driven Development), DDD (Domain Driven Design) и Clean Code.
На основе этого опыта я составил дорожную карту на 3–5 лет. Она поможет человеку, который только начинает карьеру в разработке, сэкономить время и не набивать шишки,
как я.
как я.
С чего начать путь в профессию и как развиваться дальше
Начинающему бэкенд-разработчику придется многое изучить. Я собрал список книг с понятным и кратким материалом для новичков:- «Думай как математик: Как решать любые задачи быстрее и эффективнее», Барбара Оакли.
- «Грокаем алгоритмы. Иллюстрированное пособие для программистов», Адитья Бхаргава.
- «SQL: быстрое погружение», Уолтер Шилдс.
- «JAVA. Эффективное программирование», Джошуа Блох.
- «Чистый код», Роберт Мартин.
- «Идеальный программист. Как стать профессионалом разработки», Роберт Мартин.
- «Как на самом деле работают компьютеры», Мэтью Джастис.
- «Компьютерные сети», 5-е изд., Эндрю Таненбаум, Дэвид Уэзеролл.
- «Java. Руководство для начинающих», Герберт Шилд.
Полезно посмотреть, как реализованы структуры и алгоритмы в стандартных библиотеках Java. Еще помогают разобраться в деталях Study Guide для подготовки к экзаменам на сертификаты Java OCA, OCP.
Если хотите пойти в веб-разработку, будет полезно почитать SQL Tuning Дэна Тоу. Тем, кто интересуется Kotlin, рекомендую книгу Дмитрия Жемерова и Светланы Исаковой Kotlin in Action.
Список книг для специалистов разных уровней будет ниже.
Старайтесь сразу применять все новые знания. Это поможет отработать навыки и собрать первое портфолио. Задачи можно придумывать самостоятельно — отталкивайтесь от того, что интересно лично вам. Например, найдите потребность, которую можете закрыть приложением, и напишите его — что угодно, хоть календарь настроения. Или поднимите свой http-сервер, сделайте демо социальной сети или интернет-магазина. Ищите простые и красивые решения. Но чтобы научиться видеть их, нужно изучать лучшие подходы и паттерны.
Если совмещать работу над своим проектом и изучение лучших практик от экспертов, прокачаться до уровня джуниора можно за полгода.
С небольшим портфолио можно идти на собеседования и устраиваться на первую работу. После этого предстоит еще многому учиться, чтобы расти по карьерной лестнице.
Если хотите пойти в веб-разработку, будет полезно почитать SQL Tuning Дэна Тоу. Тем, кто интересуется Kotlin, рекомендую книгу Дмитрия Жемерова и Светланы Исаковой Kotlin in Action.
Список книг для специалистов разных уровней будет ниже.
Старайтесь сразу применять все новые знания. Это поможет отработать навыки и собрать первое портфолио. Задачи можно придумывать самостоятельно — отталкивайтесь от того, что интересно лично вам. Например, найдите потребность, которую можете закрыть приложением, и напишите его — что угодно, хоть календарь настроения. Или поднимите свой http-сервер, сделайте демо социальной сети или интернет-магазина. Ищите простые и красивые решения. Но чтобы научиться видеть их, нужно изучать лучшие подходы и паттерны.
Если совмещать работу над своим проектом и изучение лучших практик от экспертов, прокачаться до уровня джуниора можно за полгода.
С небольшим портфолио можно идти на собеседования и устраиваться на первую работу. После этого предстоит еще многому учиться, чтобы расти по карьерной лестнице.
Джуниор-разработчик должен разбираться в базовых вещах: теории баз данных, структурах и алгоритмах. Основы можно изучать в институте, на курсах или самостоятельно. Главное — не останавливаться на теории, а сразу применять ее на практике.
В любой компании джуниору понадобятся навыки работы с Git и Linux, понимание основ Docker. Достаточно самых базовых: запуск, настройка, основные команды. Дальше станет понятно, что именно изучать глубже.
Джуниор должен уметь писать эффективный и правильный код. Для этого — можно снова посоветовать изучать и применять подходы из книг Роберта Мартина и Джошуа Блоха.
Наконец, джуниору нужно проверять и тестировать все свои решения, как минимум — уметь писать юнит-тесты. Кстати, не все тесты одинаково полезны — понять это поможет книга Владимира Хорикова «Принципы юнит-тестирования».
Бэкенд-разработчик полностью вовлечен в проект уже на уровне джуниора. Он интересуется работой коллег, задает вопросы и разбирается, как действует система: от нажатия кнопки пользователем до конкретной маленькой фичи в бэкенде.
В хорошей команде все должны быть заинтересованы в том, чтобы научить джуниор-бэкенд-разработчика всему необходимому, показать проект со всех сторон. На бэкенде замыкаются многие процессы, поэтому придется задавать вопросы, уточнять и разбираться практически во всех деталях.
В любой компании джуниору понадобятся навыки работы с Git и Linux, понимание основ Docker. Достаточно самых базовых: запуск, настройка, основные команды. Дальше станет понятно, что именно изучать глубже.
Джуниор должен уметь писать эффективный и правильный код. Для этого — можно снова посоветовать изучать и применять подходы из книг Роберта Мартина и Джошуа Блоха.
Наконец, джуниору нужно проверять и тестировать все свои решения, как минимум — уметь писать юнит-тесты. Кстати, не все тесты одинаково полезны — понять это поможет книга Владимира Хорикова «Принципы юнит-тестирования».
Бэкенд-разработчик полностью вовлечен в проект уже на уровне джуниора. Он интересуется работой коллег, задает вопросы и разбирается, как действует система: от нажатия кнопки пользователем до конкретной маленькой фичи в бэкенде.
В хорошей команде все должны быть заинтересованы в том, чтобы научить джуниор-бэкенд-разработчика всему необходимому, показать проект со всех сторон. На бэкенде замыкаются многие процессы, поэтому придется задавать вопросы, уточнять и разбираться практически во всех деталях.
Что почитать джуниору:
- «Чистый код», Роберт Мартин.
- «Чистая архитектура», Роберт Мартин.
- «Java. Эффективное программирование», Джошуа Блох.
- «Принципы юнит-тестирования», Владимир Хориков
Мидл-разработчик углубляется в архитектуру приложений. Умеет работать с микросервисами. Понимает, что такое Kubernetes, например может развернуть мини-куб на своем ноутбуке. Чаще работает с SQL, NoSQL, хотя конкретные инструменты зависят от проекта.
Отлично, если мидл знает и применяет методологию TDD (Test Driven Development) — разработку через тестирование. Этот подход помогает писать более чистый и качественный код. А как при этом писать меньше тестов, делать их эффективнее, избегать подводных камней, рассказывает Владимир Хориков.
Бэкенд-разработчик этого уровня понимает, что такое пирамида тестирования, как она работает и для чего нужна. Он взаимодействует с тестировщиками, участвует в автоматизации, поэтому должен разбираться в способах и видах тестирования.
Что почитать мидлу:
Через три года (если включить год джуниором) вы станете хорошим мидлом и сможете претендовать на следующую ступень.
- Методология «Двенадцатифакторное приложение».
- Статья 7 Software Development Principles That Should Be Embraced Daily.
- «Приемы объектно-ориентированного проектирования. Паттерны проектирования», Эрих Гамма, Джон Влиссидес, Ральф Джонсон, Ричард Хелм.
- «Создание микросервисов», Сэм Ньюмен.
- «Микросервисы. Паттерны разработки и рефакторинга», Крис Ричардсон.
Через три года (если включить год джуниором) вы станете хорошим мидлом и сможете претендовать на следующую ступень.
Сеньор-разработчик отвечает за качество работы всей команды. Он надежда и опора для остальных разработчиков — и особенно для джуниоров. Это «старший брат», к которому можно обратиться за советом. Если в компании работают по скраму, сеньор может попробовать себя в роли скрам-мастера, продвигать Agile.
Кроме того, сеньор много общается с бизнес-заказчиками. Чтобы не спорить о приоритетах, а вместе искать лучшее решение, он должен хорошо понимать бизнес и быть немного менеджером.
Сеньор-разработчик лучше всех знает, насколько важен дизайн кода в разработке. Именно на этом этапе становятся видны взаимосвязи микро- и макромира: как и на что влияют технологии и паттерны, которые он изучил раньше. Например, понимает: трехуровневая архитектура в приложении работает так же хорошо, как и в коде. Опытный разработчик укладывает в единую систему знания, которые получил за всё прошедшее время.
Для более глубокого погружения в дизайн сеньор-разработчик может изучить DDD, или предметно-ориентированное проектирование. Этот подход отталкивается от предметной области и нужд бизнеса.
Я начал изучать топик DDD c книги Domain Modeling Made Functional Скотта Влашина. Затем прочитал DDD The First 15 Years. После этого начал изучать труд Эрика Эванса «Предметно-ориентированное проектирование», в котором он много пишет об общих подходах к разработке и взаимодействии с людьми. Советую вам такой же порядок чтения.
Другой подход, который полезно знать сеньору, — TDD, или разработка на основе типов. Он связан с математическим моделированием и строгим описанием типов. Подход описан также у Скотта Влашина и в книге DDD The First 15 Years.
Наконец, сеньор-разработчик должен отлично знать предметную область. Он отвечает за качественную работу каждого элемента в проекте.
Кроме того, сеньор много общается с бизнес-заказчиками. Чтобы не спорить о приоритетах, а вместе искать лучшее решение, он должен хорошо понимать бизнес и быть немного менеджером.
Сеньор-разработчик лучше всех знает, насколько важен дизайн кода в разработке. Именно на этом этапе становятся видны взаимосвязи микро- и макромира: как и на что влияют технологии и паттерны, которые он изучил раньше. Например, понимает: трехуровневая архитектура в приложении работает так же хорошо, как и в коде. Опытный разработчик укладывает в единую систему знания, которые получил за всё прошедшее время.
Для более глубокого погружения в дизайн сеньор-разработчик может изучить DDD, или предметно-ориентированное проектирование. Этот подход отталкивается от предметной области и нужд бизнеса.
Я начал изучать топик DDD c книги Domain Modeling Made Functional Скотта Влашина. Затем прочитал DDD The First 15 Years. После этого начал изучать труд Эрика Эванса «Предметно-ориентированное проектирование», в котором он много пишет об общих подходах к разработке и взаимодействии с людьми. Советую вам такой же порядок чтения.
Другой подход, который полезно знать сеньору, — TDD, или разработка на основе типов. Он связан с математическим моделированием и строгим описанием типов. Подход описан также у Скотта Влашина и в книге DDD The First 15 Years.
Наконец, сеньор-разработчик должен отлично знать предметную область. Он отвечает за качественную работу каждого элемента в проекте.
Что почитать сеньору:
Бэкенд-разработчик может строить карьеру в стартапе или крупной компании. В первом случае процессы могут быть очень разными в зависимости от предпочтений команды. А во втором — будут достаточно строгие правила и регламенты. Поэтому начинающим программистам полезно заранее узнать, как строится разработка в энтерпрайзе.
- System design, Алекс Сюй.
- «Предметно-ориентированное проектирование. Структуризация сложных программных систем», Эрик Эванс.
- DDD The First 15 Years, сборник статей разных авторов.
- Domain Modeling Made Functional, Скотт Влашин.
- «Шаблоны корпоративных приложений. Исправленное издание», Мартин Фаулер.
- «Джедайские техники конструктивного общения», Александр Орлов.
Бэкенд-разработчик может строить карьеру в стартапе или крупной компании. В первом случае процессы могут быть очень разными в зависимости от предпочтений команды. А во втором — будут достаточно строгие правила и регламенты. Поэтому начинающим программистам полезно заранее узнать, как строится разработка в энтерпрайзе.
Как происходит бэкенд-разработка в энтерпрайзе
Для большинства компаний главное в процессах — их прозрачность и гибкость. Это значит, что все в команде понимают, из каких шагов состоит каждый этап работы, и нет секретных знаний, которые доступны только одному человеку. Тогда все участники проекта знают свою роль, и проект успешно продвигается по пайплайну разработки.Работа над проектом проходит примерно одинаково в любой корпорации. Для начинающих бэкенд-разработчиков полезно знать этот пайплайн в общем виде.
Новые проекты в корпорации начинаются с проработки бизнес-требований. Их готовят бизнес-технологи или аналитики. Затем по этим требованиям одновременно начинают разрабатывать дизайн фронтенда и концептуальный дизайн.
Концептуальный дизайн — это архитектурная идея проекта, похожая на первый набросок здания. В нем нет плана коммуникаций или поэтажной планировки, но отражена общая идея будущего дома.
Следующий этап — согласование концепции и дизайна с требованиями безопасности. Специалисты оценивают потенциальные уязвимости, на которые нужно обратить внимание при разработке.
В гибких структурах, например, agile-командах, в первых этапах участвуют все разработчики. Если среди них есть джуниор, его тоже привлекают к проектированию и оценке. Таким образом человек учится, задает вопросы и глубже погружается в проект.
Когда подготовительная работа завершена, специалисты готовят общее техническое архитектурное решение (ОТАР). Продолжая аналогию с постройкой дома — это план, в котором учтено все необходимое: расположение водопровода, канализации и электропроводки, толщина несущих стен и расположение дверей и окон.
По готовому ОТАР начинается разработка прототипа приложения и инфраструктуры. Его работоспособность проверяют на тестовом полигоне.
Иногда прототип приложения разрабатывают намного раньше, еще на этапе проработки бизнес-требований. Это помогает в самом начале понять, стоит ли использовать ту или иную технологию. Такой подход экономит много ресурсов.
Когда инфраструктура готова, есть пайплайны для доставки приложения в продакшен, а прототип достаточно хорошо протестирован, можно выпускать MVP (Minimal Viable Product) — минимальную рабочую версию продукта. Она доступна пользователям, поэтому позволяет проверить гипотезы и определить, что делать дальше, а также наладить поддержку.
Затем цикл разработки замыкается между разработкой новых функций в формате MVP, их тестированием и выкаткой в продакшен.
Концептуальный дизайн — это архитектурная идея проекта, похожая на первый набросок здания. В нем нет плана коммуникаций или поэтажной планировки, но отражена общая идея будущего дома.
Следующий этап — согласование концепции и дизайна с требованиями безопасности. Специалисты оценивают потенциальные уязвимости, на которые нужно обратить внимание при разработке.
В гибких структурах, например, agile-командах, в первых этапах участвуют все разработчики. Если среди них есть джуниор, его тоже привлекают к проектированию и оценке. Таким образом человек учится, задает вопросы и глубже погружается в проект.
Когда подготовительная работа завершена, специалисты готовят общее техническое архитектурное решение (ОТАР). Продолжая аналогию с постройкой дома — это план, в котором учтено все необходимое: расположение водопровода, канализации и электропроводки, толщина несущих стен и расположение дверей и окон.
По готовому ОТАР начинается разработка прототипа приложения и инфраструктуры. Его работоспособность проверяют на тестовом полигоне.
Иногда прототип приложения разрабатывают намного раньше, еще на этапе проработки бизнес-требований. Это помогает в самом начале понять, стоит ли использовать ту или иную технологию. Такой подход экономит много ресурсов.
Когда инфраструктура готова, есть пайплайны для доставки приложения в продакшен, а прототип достаточно хорошо протестирован, можно выпускать MVP (Minimal Viable Product) — минимальную рабочую версию продукта. Она доступна пользователям, поэтому позволяет проверить гипотезы и определить, что делать дальше, а также наладить поддержку.
Затем цикл разработки замыкается между разработкой новых функций в формате MVP, их тестированием и выкаткой в продакшен.
Почему бэкенд-разработчику нужно много общаться
В команду разработки входят несколько разных специалистов: бэкенд- и фронтенд-разработчики, QA, владельцы продукта, аналитики, DevOps. Каждый из них решает свои задачи, но все так или иначе будут связаны с бэкендом.
Это значит, что бэкенд-разработчику нужно уметь общаться с каждым членом команды. И чем выше уровень, тем больше он взаимодействует с коллегами. Джуниор чаще общается с наставником или отдельными специалистами по точечным вопросам. Сеньор общается со всеми и очень часто, потому что ему нужно глубоко разбираться в проекте.
Развивать навык общения не так сложно, как кажется. Я интроверт, но периодически прохожу курсы по работе с аудиторией. Мне это нужно, чтобы успешнее продвигать лучшие практики в своей команде, выступать на конференциях, доносить важную информацию до новичков. Но также это нужно и в обычной работе, в разработке продукта.
На уровне джуниора общение даст возможность погрузиться в работу и найти то, что нравится. Позже — делать более качественный продукт, в котором учтены все детали. Хороший код — результат продуктивного общения с аналитиками, бизнесом, экспертами и другими разработчиками.
Чтобы быть на одной волне с командой, стоит базово познакомиться с инструментами, которыми пользуются разные специалисты. Например, для качественного разговора с фронтенд-разработчиком нужно хотя бы немного знать о технологиях разработки на React или Flutter. Тогда будет проще понять, как работает фронтенд и что ему может дать бэкенд как сервис.
Говорить на одном языке с аналитиками легче, если самому писать документацию. Также полезно исследовать хорошие примеры документации в open source и коммерческих решениях, например, у Stripe или YooMoney.
Чтобы было проще общаться с QA, стоит поднять проект с автотестами и научиться их писать. Разработчику нужно понимать суть e2e-тестирования, ценность и количество интеграционных тестов, место в пирамиде тестирования.
Бэкенд-разработчик уровня сеньора может совместно с DevOps работать над пайплайном.
Наконец, очень важно много и качественно общаться с владельцем продукта. Именно он лучше всех знает, какие задачи приоритетные, какая фича сделает продукт лучше и принесет большую прибыль.
Развивать навык общения не так сложно, как кажется. Я интроверт, но периодически прохожу курсы по работе с аудиторией. Мне это нужно, чтобы успешнее продвигать лучшие практики в своей команде, выступать на конференциях, доносить важную информацию до новичков. Но также это нужно и в обычной работе, в разработке продукта.
На уровне джуниора общение даст возможность погрузиться в работу и найти то, что нравится. Позже — делать более качественный продукт, в котором учтены все детали. Хороший код — результат продуктивного общения с аналитиками, бизнесом, экспертами и другими разработчиками.
Чтобы быть на одной волне с командой, стоит базово познакомиться с инструментами, которыми пользуются разные специалисты. Например, для качественного разговора с фронтенд-разработчиком нужно хотя бы немного знать о технологиях разработки на React или Flutter. Тогда будет проще понять, как работает фронтенд и что ему может дать бэкенд как сервис.
Говорить на одном языке с аналитиками легче, если самому писать документацию. Также полезно исследовать хорошие примеры документации в open source и коммерческих решениях, например, у Stripe или YooMoney.
Чтобы было проще общаться с QA, стоит поднять проект с автотестами и научиться их писать. Разработчику нужно понимать суть e2e-тестирования, ценность и количество интеграционных тестов, место в пирамиде тестирования.
Бэкенд-разработчик уровня сеньора может совместно с DevOps работать над пайплайном.
Наконец, очень важно много и качественно общаться с владельцем продукта. Именно он лучше всех знает, какие задачи приоритетные, какая фича сделает продукт лучше и принесет большую прибыль.
Что еще важно для бэкенд-разработчика
Искренне интересоваться профессией, изучать лучшие практики и применять их в работе. Без постоянных экспериментов и улучшения своего же кода не будет развития.Изучать смежные области и работу других членов команды, чтобы лучше их понимать. К тому же это помогает развиваться и находить новые, необычные решения для своей работы.
Не переживать, что результат труда будет не очень заметным. Работа бэкенд-разработчика невидимая, в отличие от фронта, но она напрямую влияет на качество сервиса или приложения.
Сохранять позитивный настрой. У разработчиков есть общая цель, которую можно достичь разными путями. Но всем станет лучше и проще работать, если в команде будет дружеская атмосфера, хорошее настроение и драйв от совместной работы.
Главное — делайте то, что любите. Учиться придется постоянно, настройтесь на это сразу. Ищите задачи, подходы и инструменты, которые вас драйвят. Только в этом случае сложный и длинный путь бэкенд-разработчика будет интересным.
