Если вы хотите узнать о том, как я перешел к разработке, вам следует прочитать Как я перешел от продаж к Front End Developer за 16 месяцев.

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

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

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

Избегайте похлопывания плечом

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

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

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

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

Использование Git с командой

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

Удобство использования более продвинутых рабочих процессов git было бы огромным преимуществом. Легкий способ бросить вызов самому себе - это слить код с мастером только через PR из ветки.

Изучите такие инструменты, как Husky, и посмотрите, сможете ли вы запустить автоматический линтинг, прежде чем делать коммит. Это отличный способ убедиться, что вы удалили все нежелательные console.log перед развертыванием!

Жизнь после localhost: 3000

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

Очевидно, что ваш код не может вечно жить изолированно на вашем компьютере. Как только вы начнете работать в производственной команде, все будет работать через конвейер непрерывной интеграции и непрерывной доставки (CI / CD).

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

Самый простой способ создать свой собственный конвейер CI / CD - создать новый сайт из Git на Netlify и создавать его всякий раз, когда вы нажимаете на master. Если вам интересно узнать о более продвинутых инструментах, загляните в Действия Github, Travis CI или Jenkins.

Тестирование и машинопись

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

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

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

Что теперь?

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

Подкасты

Статьи

Блоги

Не будь чужим! Не стесняйтесь писать, если у вас есть какие-либо вопросы: пришлите мне рекомендации по любимым книгам по электронной почте, свяжитесь со мной в Linkedin или подпишитесь на меня в Twitter!