18 типичных ошибок Junior’a

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

Код в вакууме

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

Классика: костыли и заплатки

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

Нет защиты от дурака

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

Код в лоб

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

Повторные вопросы

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

«Это невозможно сделать»

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

Грязный код

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

«Этого точно никогда не будет»

Забудьте эту фразу, всегда обрабатывайте невозможные ситуации корректно.

Отсутствие привычки «гуглить» проблему

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

«Я знаю лучше»

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

Отказ от бекапирования

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

Крайняя уверенность в себе

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

Отсутствие самоанализа

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

Отсутствие готовых решений

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

Желание решить задачу максимально быстро

Junior разработчики очень часто стремятся сделать всё как можно быстрее, думая, что тем самым показывают хорошую работу. К сожалению, это не так.

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

Во-вторых, после выполнения задачи разработчик начинает получать обратную связь, которую важно аккумулировать, а не сразу подрываться всё вносить, иначе спешка грозит Junior’у нервным срывом из-за отвлечения на новые правки каждые 10 минут. Про это всегда рекомендую посмотреть выпуск сатирического киножурнала Фитиль №183-02 "Порожняк" (1969) — классическая картина Junior и Senior разработчика (хотя в домино на работе играть не советую:)

Вниманию тех, кто в поиске работы: в команду к Никите как раз нужен Web developer, кандидатуры талантливых Junior’ов тоже рассматриваются.

Боязнь legacy-кода

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

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

Страх задать вопрос

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

Кстати, умение задать правильный вопрос — тоже большое искусство, в котором приходится упражняться не только Junior’ам. Знать абсолютно все невозможно, а если проблема тебе кажется ну уж очень простой и банальной, можно начать с фразы «я сейчас, возможно, глупость спрошу, но…» — и будет уже не так страшно.

Сломать по незнанию

Часто в рамках исправления/доработок какой-то функциональности Junior’ом работоспособность системы нарушается. Как избежать: нужно изучить систему, разобраться во всех основных нюансах ее работы и взаимосвязями между компонентами, внимательно относиться к деталям и поддерживать документацию в актуальном состоянии.

Статья опубликована на geekbrains.ru