Типичные ошибки junior-разработчиков. Вы можете быть одним из них

Узнали у middle и senior программистов, какие ошибки чаще всего совершают джуны. Также попросили рассказать, как этих ошибок можно избежать. Вот, что они ответили.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Юлия Румянцева

Руководитель отдела Web-разработки ГК Альфа-Лизинг

Младшие разработчики мало внимания уделяют названию методов и переменных. Зачастую они придумывают название функции, которое не отражает её предназначение, в итоге сами путаются в том, что написали.

Ошибки бывают связны с изобретением “велосипеда”, когда вместо готового кода, разработчики пишут свой. Или другая крайность – использование готовых библиотек, не разобравшись в логике их работы. Бывают ошибки по невнимательности и из-за спешки. Чтобы избежать недочетов можно отдавать код на ревью старшим коллегам, обсуждать планы по реализации до старта разработки, не паниковать и не спешить.

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

Типичные ошибки у начинающих разработчиков при работе с Git - нарушение методологии ветвления и слияния. Обязательно нужно соблюдать стандарты и регламенты в своей команде и никогда не пользоваться —force атрибутом при публикации.

Если эта проблема системная - рекомендуется изучить спиральную модель разработки и стремиться ее внедрять в процесс и определять на входе четкие критерии приемки (Defenition of Done).

Если это личная проблема разработчика, то можно попробовать себя в TDD, уточнить критерии приемки или переносить задачи на улучшения кода в техдолг. Ну и помним, что совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать.

Даже нейтральные слова могут оставить неприятный осадок, если мы не умеем правильно реагировать на замечания в свой адрес. Нужно учиться отделять конструктивную критику от субъективных оценок. Рекомендация полезной книги на эту тему – "Спасибо за обратную связь” Д. Стоуна и Ш.Хин.

Чтобы избежать проблем с производительностью приложений, рекомендуется использовать микросервисную архитектуру, библиотечный код, паттерны разработки – это то, что можно заложить в приложение уже на начальном этапе.

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

Самый простой способ не потерять мотивацию и развиваться - начать смотреть на ошибки, как на возможности. Возможности для роста и развития. Сходите на Fails Night, где сеньоры делятся своими рабочими провалами, возможно это вас вдохновит!

Александр Чередников

CTO Qtim

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

Джуны чаще всего допускают банальные ошибки, как правило связанные со стилем кода или незнанием архитектурных подходов и принципов разработки. Чтобы избежать таких проблем, стоит использовать CI\CD (непрерывная интеграция). При такой методологии запускаются соответствующие линтеры и производится тестирование кода.

• Начинающие разработчики могут столкнуться с проблемами управления памятью. Они характерны для языков программирования с ручным управлением памятью: C или C++.
• Трудности могут вызывать обнаружение и устранение ошибок в алгоритмах. Это связано с логическими ошибками,  которые трудно выявить.
• Рекурсивные алгоритмы также могут быть сложны для понимания и отладки. Особенно если новичок не разработал интуицию относительно базовых случаев и выхода из рекурсии.
• Junior-специалисты часто не знают, как выбрать наиболее эффективную структуру данных для конкретной задачи. Это может привести к неэффективным решениям, которые усложнят код и растянут процесс разработки.

• Начинающие разработчики могут упускать из вида вопросы, связанные с производительностью и масштабируемостью архитектурных решений. Часто это приводит к проблемам в будущем, т.к. нет возможности развивать уже реализованное решение и приходится переписывать код с нуля. 
• Неопытные специалисты фокусируются на технических аспектах архитектуры. При этом недооценивают важность понимания бизнес-требований заказчика и потребностей пользователей.
• Еще одна проблема джунов – недостаточное понимание принципов программирования, таких как SOLID, DRY, KISS. Они помогают не писать лишнее, делать проще и понятнее.

Основная проблема заключается в том, что работа с Git ведется на базовом уровне. Начинающие разработчики не знаю команды «rebase» или « squash», которые помогают поддерживать чистую историю разработки. ….  

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

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

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

Одна из основных проблем это работа с базами данных и SQL. Зачастую начинающие разработчики не знают о нюансах своей СУБД, с которой они работают. Чтобы справится с этой проблемой, стоит анализировать такие запросы.

Еще одна из проблем — отсутствие знаний об инструментах профилирования, дебаггинга. В каждом языке программирования есть такие инструменты, как дебаггеры, профилировщики, которые нужно изучать и использовать в работе, чтобы не допустить проблем в продакшене. 

• Основные принципы программирования, такие как SOLID, DRY, KISS, YAGNI, GRASP и другие, предоставляют фундаментальные инструменты и методики для построения эффективного, чистого и легко поддерживаемого кода
• Применение принципов программирования помогает упростить код, облегчая его понимание, модификацию и отладку.
• Знание основных принципов помогает создавать модульный и более  масштабируемый код, что важно для долгосрочной поддерживаемости проекта.
• Принципы программирования способствуют созданию более эффективного кода, что, в свою очередь, поможет улучшить производительность приложения.
• Соблюдение основных принципов программирования помогает уменьшить вероятность ошибок и облегчить процесс отладки.
• Основные принципы программирования являются универсальными и применимы к различным языкам программирования и технологиям, что делает их особенно ценными для разработчиков.
• Пренебрежение теоретической базой  и основными принципами программирования может привести к созданию неэффективного, трудно поддерживаемого и даже ошибочного кода. А это в конечном итоге может привести к серьезным проблемам в практической разработке, таким как увеличение трудозатрат на разработку, ухудшение производительности приложения и увеличение вероятности ошибок.

Сложности в разработке испытывает каждый специалист на любой стадии своего карьерного роста. Главное понимать, что трудности нужно уметь преодолевать, именно благодаря такому опыту мы растем как специалисты. В любом случае всегда есть старшие разработчики, которые помогут и подскажут, как решить проблему. Стоит также понимать, что сложности связаны с отсутствием знанием в конкретной области. Чтобы в следующий раз самостоятельно решить возникший вопрос, стоит изучать дополнительные материалы на эту тему. Это поможет избежать ошибок в будущем и не тратить больше, чем стоило, времени на задачу.

Денис Базарнов

Ведущий консультант, отдел DS сервисов, компания IBS

Более уместен термин «сложность», нежели «недопонимание». Сложность вызвана тем, что при изучении любого языка программирования (далее — ЯП) новичок в основном изучает реализацию несложных математических задач или методов классификации. На практике же ЯП — это универсальный инструмент, который используется ежедневно. И в спектр ежедневно решаемых задач математика или методы классификации или алгоритмические задачки могут и не входить. И у джуна складывается ошибочное впечатление в духе «учили одному, а приходится делать совершенно другое».

Если ответить кратко: еще 10 лет назад наиболее частые ошибки были синтаксические. Новичок приходил с типичным вопросом: «Слушай, у меня тут компилятор/интерпретатор ругается, я все перепробовал, но не понимаю, чего он хочет». Сейчас, когда ИИ уже может писать простой код, когда IDE более совершенны, большинство ошибок — логические. И избежать их не удастся, пока разработчик четко не будет понимать, «как это работает сейчас и как надо».

Проблемы с алгоритмами встречаются редко. Наиболее часто встречаются проблемы с описанием требуемых структур данных посредством типов конкретного ЯП.

Самая распространенная ошибка — конфликты при слиянии. И большинство ошибок начинаются именно с конфликта. Лучшая практика — своя git-методология (см. git flow).

Если не уделять должного внимания код-ревью, то легко можно скатиться к ситуации, когда новички несколько раз будут переписывать свой код и по-прежнему не проходить код-ревью. И обратная ситуация — когда новички объединяются в группы, по-товарищески аппрувят пул-реквесты друг друга и как итог: некачественный код. Поэтому чаще вводятся правила, например: замечания по код-ревью должны быть обоснованными (с ссылкой на раздел, к примеру), мягкими (без оскорблений), но обязательными к выполнению. Ну и, конечно, любой код новичка должен просмотреть хотя бы один более опытный коллега.

Здесь уместна аналогия: может ли человек без соответствующего образования построить небольшой дачный дом? Может. А может ли этот же человек построить небоскреб при наличии всех ресурсов? Нет. Даже если будет выверенный проект здания, человек без образования вряд ли сможет его полностью прочитать и понять. При этом в наших вузах не учат ребят, как проектировать и строить исключительно небоскребы. С программированием та же история: может ли новичок сделать минимальное приложение по примерам из интернета? Да, конечно. Но если речь идет о масштабных проектах, его знаний явно будет недостаточно.

Вы будете удивлены, но я считаю, что проблема мотивации корнями уходят в вопрос: «Как войти в ИТ?». Из моих наблюдений: у большинства новичков, особенно в возрасте от 30 лет и старше, мотивация носит в первую очередь финансовый характер и порой звучит кардинально, например, вот так: «Не важно, что я буду делать, но важно, что мне за это будут хорошо платить». И что мы имеем через 3-6 месяцев? Человек получает ощутимый доход, базовые потребности удовлетворяются и приходит очередь таких внутренних вопросов, как «А мое ли это? Нравится ли мне этим заниматься?» Ну, а раз такие вопросы возникают, ответ очевиден. И все — привет выгорание. Что можно порекомендовать? Не останавливаться. И если еще не начал, то начни подбирать свою специализацию. Наша отрасль очень широка, практически каждый может найти свое направление и ту активность, которой будет нравится заниматься.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.