Хорошие и плохие привычки разработчиков-джуниоров

Перевод статьи «Good habits to have as an aspiring/junior developer — and habits to avoid».

Хорошие и плохие привычки разработчиков-джуниоров

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

Хорошие привычки

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

Частые коммиты

Скорее всего вам уже попадались такие слова как «Git», «GitHub», «контроль версий». Если нет, –

  1. Где вы были?!
  2. Вы можете узнать о них здесь.

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

Стоит ли говорить, что контроль версий невероятно упрощает жизнь, когда речь идет о работе в команде. Я даже представить не могу совместную работу без этого инструмента. Как же тогда — пересылать код по email или через slack?! *Дрожит*.

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

Нет никаких жестких правил относительно того, когда следует «сдавать» ваш код. Кроме упомянутых мной есть и другие подходящие для коммита моменты:

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

Есть только одно важное правило, касающееся коммитов:

Код должен быть успешно собран, тесты должны быть пройдены.

Или это два правила? В любом случае, это важно. Сломанный код гарантированно задержит работу команды. Поэтому, прежде чем сделать коммит, обязательно проверяйте свой код!

Наконец, непременно оставляйте хорошие сообщения коммитов. Фраза «Исправлен баг» не столь информативна, как «Исправлена проблема с кнопкой «сохранить todo», которая не вызывала функцию onClick должным образом». Такие сообщения будут полезны не только вам, но и вашим товарищам по команде.

Работа в команде

Используйте понятные имена для переменных, функций и файлов

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

Выбирая имена для переменных, функций и файлов, старайтесь сделать их как можно более описательными. Зачем?

  • Это облегчает беглый просмотр кода. Если вы видите метод getUsers(), вы даже не заглядывая в него можете быть уверены, что он будет возвращать список пользователей.
  • Это способствует разделению ответственности. О, новый загадочный термин! Не волнуйтесь, это означает всего лишь совместное хранение связанных друг с другом вещей. Например, если в Node.js-приложении у вас есть конечная точка /users и конечная точка /products, вы можете поместить логику users в одном файле (например, в usersService.js), а логику products —в другом. Так будет куда проще искать нужные вещи, не так ли?

Вот простая функция с плохим неймингом. Можете догадаться, то она делает?

const function1 = (x, y) => {
    return x + y
}

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

Вот та же функция, но с лучшим неймингом:

const addNumbers = (num1, num2) => {
    return num1 + num2
}

Теперь стало немного понятнее, что эта функция делает и каковы должны быть параметры.

Занимайтесь отладкой

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

К счастью для нас, веб-разработчиков, многие IDE имеют встроенные отладчики, что очень облегчает работу.

Как заниматься отладкой кода эффективно? Вот несколько рекомендаций:

  • Воспроизводите проблему. Воспроизводите баг несколько раз, чтобы точно понять, что именно вызывает его появление.
  • Думайте. Прежде чем погрузиться в код и начать бесцельно чистить все вокруг, остановитесь и подумайте. Почему все происходит именно таким образом? Какой участок кода отвечает за это?
  • Исследуйте код. Когда у вас есть предположение, какие участки кода скорее всего связаны с возникшей проблемой, начинайте копать. Вы можете обнаружить корень проблемы, прочитав код. Если не вышло, пришла пора запускать отладчик.
  • Отладка. Запускайте отладчик и идите по коду строка за строкой. Обращайте внимание на значения переменных (и как они меняются), а также на то, какие функции вызываются (а какие — нет). Верны ли вызываемые ветви if-предложений? Должным ли образом осуществляются вычисления?
Отладка

Планируйте, прежде чем писать код

Вы проснулись, хорошо выспавшись. Завтракаете — и вдруг у вас рождается идея для нового проекта. Она просто фантастическая! Революционная!

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

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

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

Я не буду углубляться в детали, поскольку ранее написал отдельную статью о том, как продумываются и проектируются веб-приложения. Здесь я вкратце упомяну, о чем следует подумать:

  • «Что это приложение делает?» — запишите, какие функции должны быть в вашем приложении.
  • «На что это похоже?» — кратко опишите, сделайте набросок того, как должно выглядеть приложение.
  • «Как я буду позиционировать элементы? Какие стили буду использовать?» — сделав общий набросок, начинайте продумывать, как все будет располагаться на странице.
  • «Как приложение должно вести себя?» — Подумайте о функционале, о том, что должно происходить, когда пользователь на что-то кликает или еще как-то взаимодействует с приложением.
  • «Каким будет мой код?» — Начинайте планировать свой код, памятуя о необходимом поведении приложения и его функционале. Какие компоненты вам понадобятся? Нужны ли будут обработчики событий? Как насчет состояния объектов?
  • «Что мне нужно будет протестировать? Что может пойти не так?» — Подумайте о тестах, edge cases и частях кода, с которыми могут возникнуть проблемы.

Плохие привычки

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

Слепое копирование кода

Все мы при написании кода сталкиваемся с различными проблемами. Это часть игры, и наша задача — разобраться, как решить эти проблемы.

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

Проблемы возникают тогда, когда мы слепо копируем код, не понимая его.

Но он же работает, так в чем проблема?

Резонное замечание. Вот причины, по которым слепое копирование кода может привести к проблемам:

  • Что произойдет, когда нужно будет изменить этот код? Внести изменения в код, который вы не понимаете, очень сложно.
  • Если мы не понимаем код, как мы можем быть уверены, что он решает нашу проблему?
  • Можем ли мы быть уверены, что этот код не повлияет негативным образом на другие части кодовой базы?
Копирование и вставка

Как избежать подобных проблем?

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

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

Привычка обходиться без тестов

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

  • Тест доказывает, что ваш код работает. Если ваш код прошел тест, никто не может сомневаться, что этот функционал рабочий.
  • Тестирование помогает проверить, не сломал ли что-то новый функционал. Запускайте тесты регулярно по мере написания кода. Таким образом вы будете узнавать о проблемах на ранних стадиях разработки, а не когда-нибудь и случайно.
  • Тестирование это ремень безопасности при рефакторинге. Напишите ваш код. Напишите ваши тесты. Сделайте рефакторинг. Запустите тесты. Они успешно пройдены? Значит, все по-прежнему работает! А теперь попробуйте внести изменения в код, не имея набора тестов для запуска. Как теперь доказать, что все работает должным образом?

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

Привычка пропускать написание документации

Документация. Скучная вещь, сопровождающая все проекты. Как кто-то сказал,

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

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

Документация это важно, так что вот вам несколько советов насчет того, как практиковаться в ее написании:

  • README — GitHub позволяет вам добавлять readme-файлы в ваши проекты. Это прекрасное место для хранения документации проекта, поскольку такие файлы легко найти.
  • Включайте в документацию сведения о том, что это приложение делает и как его запустить. Это позволит читателю начать его использовать.
  • Поясняйте другие важные вещи — сложную логику, сторонние библиотеки и API, настройки конфигурации.

Надеюсь, вам было полезно узнать о том, какие хорошие привычки стоит приобрести начинающему разработчику.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх