Как опознать плохого разработчика - 9 признаков

Старт:14.12.2024

Срок обучения:

Визуальное исследование

Конструируем смыслы и интегрируем научный подход в свою практику.

7 700 ₽11 000 ₽

Подробнее

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

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

Отказ от обучения и развития. Современная область разработки ПО динамично меняется. Если разработчик не проявляет желания изучать новые технологии и подходы, он рискует отстать от современных стандартов и не выполнять задачи качественно. Обратите внимание на наличие активного профиля в GitHub, участие в открытых проектах, онлайн-курсах и тому подобное. Отсутствие активности - тревожный сигнал.

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

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

Отсутствие понимания задач бизнеса. Разработчик должен быть способен не только писать код, но и понимать, как продукт работает на практике. Его решения должны отвечать на потребности пользователя, а не только на технические параметры. Продемонстрировать понимание задачи - необходимая часть работы.

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

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

Нежелание общаться с клиентами или заказчиками. Разработчик должен понимать нужды и потребности конечного пользователя. Постоянные проблемы и непонимание вызовут конфликты, и, в целом, испортят впечатление от работы. Общение с клиентами – важный компонент успешной работы.

Проблемы с пониманием задач

Разработчик пропускает ключевые аспекты задачи. Обратите внимание на неоднократные уточнения и переспросы, которые требуют от вас повторного объяснения. Если он просит детали, которые явно указаны в ТЗ, это может указывать на непонимание или поверхностное изучение документации.

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

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

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

Невыполнение согласованных сроков разработки. Постоянные дополнительные запросы на уточнение задач, приводящие к сдвигу сроков (а не к корректировке ТЗ), могут быть результатом плохой коммуникации или же неспособности разработчика оценить необходимые затраты на выполнение.

Неспособность к коммуникации

Плохой разработчик часто страдает от проблем с коммуникацией, что приводит к неопределённости и ошибкам в проекте. Обращайте внимание на следующие моменты:

Отсутствие четкого описания задач. Разработчик не может сформулировать задачу или попросить разъяснений. В итоге, выполняется не то, что требовалось.

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

Непонятные или слишком сложные объяснения. Использует жаргон, неадекватную терминологию в общении с клиентами, командой или менеджерами проекта. Это приводит к искажениям понимания и необходимости перепроверки.

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

Затянутые ответы на вопросы. Разработчик долго не отвечает или делает это в неподходящее время (например, поздно ночью). Это приводит к потерям времени и простоям в проекте.

Отсутствие обратной связи. Разработчик не сообщает о возникающих проблемах, задержках или альтернативных решениях. Это может привести к скрытым рискам, которые повлияют на сроки и качество.

Отсутствие объяснения принятых решений. Разработчик принимает ключевые решения без обсуждения и обоснования, что может привести к конфликтам и непониманию внутри команды.

Низкая скорость разработки

Разработчик работает слишком медленно, если:

• Дедлайны постоянно сдвигаются на неопределённый срок.
• На задачи, которые должны были завершиться за 1-2 дня, уходит неделя или больше.
• В sprint-задаче (или задаче, подобной по продолжительности) ожидается процент выполнения значительно ниже, чем у коллег.
• Продуктивная работа прерывается частыми встречами/отключениями на внешние задачи или вопросы.
  1. Необходимо отслеживать и документировать продолжительность этих отвлечений.
• Задержка в прохождении задач заметна во всех этапах разработки – от планирования до тестирования.
• Число ошибок, выявленных на поздних стадиях проекта, значительно выше, чем у квалифицированных разработчиков. Это может свидетельствовать о недостаточно продуманном планировании и отладке.
• При оценке задач разработчик существенно завышает сроки, которые впоследствии не соответствуют реальности.
  • Проверьте, есть ли понятные и согласованные критерии для оценки задач. В противном случае корректная оценка - проблема, а не показатель профессионализма.
• Разработчик не может объяснить причины задержки, ссылаясь на непредвиденные обстоятельства. Отсутствие конкретики – тревожный звонок.
• Разработчик избегает общения по поводу проблем или задержек, не пытаясь найти конструктивные решения и/или общими усилиями минимизировать их влияние.

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

Проблемы с кодом

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

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

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

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

Неправильное использование данных. Убедитесь, что код использует типы данных корректно и соответствуют задаче. Несоответствия типов данных или их некорректное использование ведут к ошибкам. Следите за типизацией данных. Это фундаментальный принцип качества кода.

Отсутствие тестирования. Проверяйте, есть ли у кода тесты. Отсутствие тестов свидетельствует о плохом понимании задачи и риске появления ошибок. Тестирование – важная часть процесса разработки.

Неумение работать в команде

Разработчик, не умеющий взаимодействовать в команде, – прямой путь к проблемам проекта. Обращайте внимание на unwillingness к совместной работе, делегированию и совместному решению задач. Например, постоянное ожидание инструкций (без активного участия в планировании и обсуждении) это первый тревожный звонок. Если разработчик избегает работы в команде либо не готов отвечать за своё задание, он не вписывается в сплоченную команду. Необходимо оценить, умеет ли человек работать с документацией по задачам, обмениваться информацией и своевременно сообщать о сложностях, а не скрывать их. Он должен быть способен, при необходимости, объяснить другим членам команды свою работу.

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

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

Отсутствие стремления к обучению

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

Признаки:

•Отказ от участия в обучающих курсах/вебинарах.

•Неиспользуемые или устаревшие навыки: работа с Python 2.7, когда все перешли на 3.x, проекты на Java, не обновлённые после выхода Java 17, при условии, что это не проект с очень специфическими требованиями, требующими поддержки legacy системы.

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

•Нехватка актуальных знаний о новинках: не ориентируются в современных архитектурах, библиотеках, методах тестирования. В беседе избегают технологий, которые обсуждают коллеги.

•Зависимость от старых решений: даже при очевидно более эффективных альтернативах. При упоминании о современных аналогах таких решений, показывает недоверие, не пытаясь найти объяснения и обоснования.

Советы: Контролируйте, насколько активно соискатель / сотрудник изучает новые технологии. Попросите примеры проектов, где он использовал новые инструменты и технологии.

Проблемы с тестированием

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

Эти признаки сигнализируют о недостаточном подходе к тестированию и могут указывать на низкую квалификацию разработчика.

Вопрос-ответ:

Какие конкретные примеры демонстрируют плохую организацию кода у разработчика?

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

Как понять, что разработчик не умеет работать с системой контроля версий, и что это плохо?

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

Как видно, что разработчик не документирует свой код должным образом, и почему это плохо?

Плохая, или полная, отсутствие документации к коду не позволяет другим разработчикам (или даже самому разработчику в будущем) легко разобраться в логике проекта. Это сильно усложняет его поддержку, модификацию, и расширение. Отсутствуют комментарии, мало или вообще нет пояснения к новым функциям. Такой код быстро превращается в "черный ящик", что не позволяет разрабатывать совместных проект с максимальной эффективностью. Трудно внести изменения в такой код, без рисков вносить ошибки. Программа станет не поддерживаемой.

Какие признаки показывают, что разработчик не умеет правильно работать с задачами и требованиями?

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

Какие симптомы указывают на проблемы с коммуникацией разработчика, и как это влияет на успешность проекта?

Недостаточная коммуникация – отсутствие ясного и понятного общения с другими членами команды о прогрессе, проблемах, или решениях. Слабая обратная связь с заказчиком. Отказ от обсуждения альтернативных вариантов решений. Проблемы с делегированием задач и получение обратной связи не позволяет команде скоординировано работать. Это создаёт напряжение, замедляет темпы проекта и повышает вероятность ошибок. Разработчик не стремится получить и использовать полезную обратную связь.

Как понять, что программист не справляется с задачей, если он вроде бы и код пишет, но программа всё равно не работает?

Проблема может быть не только в коде, но и в понимании задачи. Хорошие разработчики не просто пишут код, а активно обсуждают требования, выясняют все особенности поведения программы, проверяют возможные варианты. Если разработчик не задаёт уточняющих вопросов, не просит дополнительных данных, не предлагает разные подходы к решению проблемы, это может указывать на поверхностное понимание задачи. Важны тщательная проверка понимания задачи, уточнение деталей и анализ ошибок, который должен включать не только изучение кода, но и обдумывание реального поведения программы в различных ситуациях. Нужно обратить внимание на то, как разработчик реагирует на ошибки — ищет причину или просто исправляет симптомы. Также полезно проверить, насколько разработчик использует тесты для проверки кода и, если использует, то с какой тщательностью и покрывает ли они все ситуации.

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

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