Java Technical Lead одного из крупных банков России Никита Летов, поделился с нами своим экспертным мнением о том, что нужно знать разработчику, что бы быть максимально эффективным при решении задач, а также всегда быть востребованным кадром на рынке труда.
Чем занимается разработчик. Бытует мнение, что разработчик только пишет код и никогда не сталкивается с вопросами архитектуры системы, ее поддержкой и решением инцидентов. На самом деле это не так. Даже в очень крупных компаниях (Не говоря уже о небольших, где разработчик является сам себе архитектором, аналитиком, менеджером и техподдержкой) разработчики участвуют в проектировании систем, и на их экспертизе и строится целевая архитектура, ведь порой только разработчик может подсказать какая технология или даже язык программирования подойдут для реализации той или иной задачи. Даже когда я еще не был Тех-лидом, а был старшим разработчиком я часто участвовал в архитектурных комитетах.
Почему знание архитектурных паттернов важно. Паттерны проектирования крайне важная тема в любом ЯП, особенно в Java. При написании программ c использованием фреймворка Spring очень легко запутаться в подходах, ведь данный инструмент позволяет решить любую задачу множеством способов, и не зная паттернов проектирования приложения, разработчик может запросто получить несвязное и неоптимальное решение даже внутри одного отдельного сервиса.
Системный дизайн и зачем он нужен. Сегодня тема системного дизайна является неотъемлемой частью любого собеседования в крупную компанию на роль разработчика. И если вдуматься в данное понятие,
“Системный дизайн – это процесс проектирования систем с учетом всех их компонентов и взаимодействий”
может показаться, что данные знания нужны только прикладному архитектору, разработчик же только код пишет. В реальности, разработчику важно понимать, как проектируется системы, и какие аспекты в его языке программирования помогут реализовать то или иное решение, или же станут блокирующими для реализации. Еще до того, как понятие системный дизайн стало мейнстримом мне удалось применять на практике идеи проектирования систем, разработав и внедрив критически важный модуль в систему обмена информацией с банками в АО Финам, а в ПАО Росбанк разработав и внедрив систему оповещения пользователей WEB версии ДБО обеспечив при этом максимальную производительность, не нарушая масштабируемости и отказоустойчивости всей системы. Сейчас я использую знания о системном дизайне в своей работе постоянно, вплотную взаимодействуя с прикладными архитекторами, чтобы учесть все тонкости разработки ПО на Java и Spring еще на этапе проектирования системы.
Как понимание архитектурных принципов помогает быть востребованным специалистом. Практически на любом собеседовании на роль разработчика ПО инженер может столкнуться с вопросом — а как бы вы построили ту или иную систему? К примеру, спроектировать оптимальную систему для сбора, агрегирования и аналитики большего объема данных с доступом в реальном времени. И очень часто такие вопросы ставят разработчиков в ступор. Разработчик не обязан знать все тонкости проектирования, но если он знает подходы для решения той или иной задачи, то он запросто сможет их предложить и выбрать подходящие технологии и связи между ними. По итогу, при найме сотрудника, компании в большинстве случаев отдадут предпочтение именно такому разработчику, ведь его экспертиза может оказать огромную поддержку аналитикам даже не этапе поставки задач. Кроме того, разработчик, разбирающийся в архитектурных принципах системного дизайна, еще на этапе ознакомления с новой задачей на разработку будет понимать с какими проблемами придется столкнуться и как их решить, а значит будет более производительным.
Итоги. Подводя итоги, я считаю, что разработчик, не важно Junior, Middle или Senior должен обладать знаниями по проектированию систем и пониманием технологий, решающих ту или иную бизнес-задачу. Такой специалист всегда будет востребован, он более самостоятельный и производительный, сможет помочь советом архитектору или аналитику. При этом, горизонт развития карьеры у такого разработчика становится намного шире и не ограничивается только написанием кода.
