Перевод статьи «Ace your first year as a junior developer with this advice».
Вы – джуниор, начинающий карьеру в сфере разработки программ? Или вчерашний выпускник универа, недавно устроившийся на первую работу? Возможно, разработчик-самоучка, терзающийся вопросом «А что же дальше?»?
Начало карьеры в сфере разработки может быть пугающим, хотя и очень увлекательным делом.
Мне знакомы эти ощущения, я сам их пережил. За последние четыре года я прошел путь от разработчика-джуниора до ведущего разработчика в SaaS-стартапе. И на этом пути я многому научился.
В этой статье я изложил несколько советов на основе собственного опыта. Эти советы нацелены на то чтобы помочь вам не только выжить в ваш первый год, но и продвигаться вперед.
Пробелы в знаниях это нормально
Университет, курсы программирования и онлайн-курсы сделали свое дело: научили вас писать код.
Однако, правда жизни такова, что мир разработки это больше, чем просто написание кода. Вам нужно будет разобраться в таких вещах как:
- Какие технологии лучше подходят для решения различных задач.
- Код, написанный другими людьми.
- Шаблоны проектирования и лучшие подходы к написанию кода.
- Как тестировать код.
- CI/CD, контроль версий, стратегии ветвления.
- Жизненный цикл разработки ПО и различные методологии.
- Работа не только со своей командой, но и с другими, с менеджерами и клиентами.
И это лишь несколько важных вещей.
Возможно, что-то из этого вы уже знаете, а может, никогда не слышали ни о чем из приведенного списка. И это нормально. Вы – джуниор, и ваш менеджер и коллеги об этом знают.
Так что в ваших знаниях в любом случае будут пробелы. Они есть у каждого разработчика! Не пугайтесь, если все это не станет понятным сразу же.
На самом деле часть прелести профессии разработчика как раз в том, что технологии постоянно меняются. Мы всегда будем учиться, независимо от нашего уровня.
Вопросы это хорошо, как и просьбы о помощи
Вы получили свое первое задание и вам не терпится погрузиться в него. И вдруг… вы застряли. Ваш код не работает так, как вы ожидаете, и все, что у вас есть, это странное и сбивающее с толку сообщение об ошибке.
Не зная, что делать дальше, вы подумываете обратиться за помощью к кому-нибудь из других разработчиков в команде, но сомневаетесь:
«Что, если они сочтут меня идиотом? Или подумают, что я не умею писать код? Или будут смеяться надо мной?»
На самом деле ничего такого не произойдет. На самом деле они подумают так:
«ОК, я по-быстрому гляну и прикину, смогу ли помочь. А! Ну да, мне уже встречалась такая проблема. Чтобы поправить дело, можешь воспользоваться someMethod() из somePackage()».
Все не так уж и плохо, правда?
Ваша команда вас поддерживает, особенно на ранних этапах вашей карьеры, так что обращайтесь за помощью.
Аналогично, если вы чего-то не понимаете, задавайте вопросы. Я по-прежнему задаю множество вопросов ежедневно! Нет такой вещи как тупой вопрос. Ваши коллеги охотно вам помогут, чтобы вам не пришлось большую часть дня в замешательстве пялиться в экран.
Ревью кода это ваш друг
Я никогда не забуду свое первое ревью кода. Мой код просматривал опытный разработчик-сеньор. Я очень волновался. И, конечно, он выдал мне бессчетное количество комментариев!
Но сейчас я понимаю, что это было к лучшему.
Цель ревью кода не в критике, а в обучении и предоставлении обратной связи.
Разработчик-сеньор пояснил, что означает каждый из комментариев, а также – почему он их сделал. Нет нужды говорить, что я многому научился. Так что, когда коллеги делают ревью вашего кода, помните, что любой их отзыв призван помочь вам учиться и оттачивать ваше мастерство разработчика.
А когда придет ваша очередь делать ревью кода других людей, вы сможете увидеть, насколько по-разному люди подходят к решению различных проблем. И вы даже сможете помочь им, внеся свои предложения!
Делите все на части, а разделив, делите еще раз
Итак, вы получили свою первую задачу. И, если она большая, вы можете чувствовать растерянность:
«Откуда начать? Пожалуй, я начну с Х, но как насчет Y? А если начать с Y, то есть же еще А, В, С… и что случится с тем же Х?!»
Не волнуйтесь, мы все через это проходили. Пытаясь решить проблему, очень легко заблудиться. В следующий раз, когда перед вами будет стоять большая задача, вспомните эту цитату:
«Как съесть слона? По кусочку за раз».
Другими словами, сделайте задачу, которая кажется неразрешимой, более управляемой. Для этого разделите ее на задачи поменьше.
Но как это сделать?
Прежде чем писать код, запишите шаги решения простыми словами. Возьмем пример.
Как наполнить стакан водой?
Выразить это простым языком можно так:
- Открыть шкаф.
- Взять стакан.
- Поместить стакан под кран.
- Открыть кран.
- Когда стакан наполнится, закрыть кран.
- Убрать стакан из-под крана.
Записывая шаги, вам легче визуализировать каждую часть задачи и придумать решение для каждой из них.
Стремитесь к простоте
Многие начинающие разработчики (и я в их числе) допускают одну и ту же ошибку: пытаются заново изобретать колесо.
Решение проблемы с использованием какого-то супер-красивого подхода в вашем коде может выглядеть впечатляюще. Однако такое решение может привести к другим проблемам:
- Код, сильно отличающийся от других похожих частей рабочей системы, впоследствии будет тяжело поддерживать.
- Ваш код может стать более многословным, чем нужно, к тому же, в нем повышается риск появления багов.
- Вам может потребоваться больше времени для работы над задачей.
Так как же вам поддерживать простоту кода?
- Сделайте рабочий код. Не раздумывайте слишком долго, сделайте то, что ваше чутье подсказывает. Главное, чтобы работало.
- Рефакторинг. Теперь, когда у вас есть рабочий код, можно сделать рефакторинг. Сделайте так, чтобы ваш код было легко читать: выберите хорошие имена переменным и используйте подходящее форматирование.
- Ускорьте свой код. Завершив рефакторинг, вы можете заметить узкие места в производительности своего кода. Настала пора оптимизировать его. Будьте внимательны и не попадитесь в ловушку преждевременной и чрезмерной оптимизации! Делайте это только при необходимости.
Бонусный совет. Подумайте над написанием тестов перед написанием кода. Это называется разработкой через тестирование. Так вы не только получите хорошее покрытие тестами, но и лучше продумаете структуру своего кода.
Учитесь писать чистый код
Умение писать чистый код может выгодно выделить вас на фоне других разработчиков.
Что подразумевается под словами «чистый код»?
- Следование принципам S.O.L.I.D.
- Код можно протестировать и поддерживать.
- Его легко читать.
Другими словами:
«Любой дурак может написать код, который поймет компьютер. Хорошие программисты пишут код, который могут понять люди»,
– Мартин Фаулер.
Я не буду вдаваться в детали, поскольку книга «Clean Code: A Handbook of Agile Software Craftsmanship» (в русском переводе «Чистый код. Создание, анализ и рефакторинг») Роберта К. Мартина даст вам более глубокое понимание этой темы. Если вы серьезно настроены научиться писать чистый код и подняться над уровнем джуниора, я настоятельно рекомендую эту книгу.
Написание чистого кода показывает вашу увлеченность своим делом, а также помогает создавать надежное, поддерживаемое программное обеспечение. Не говоря уже о том, что это немного облегчит жизнь человека, которому придется в будущем работать с вашим кодом.
«Для этого есть библиотека»
Вам случалось рассказывать другу о какой-то своей проблеме, на что он отвечал: «А, для этого есть приложение»?
В разработке программ тоже есть такие ситуации.
Есть множество готовых ответов на проблемы, которые вы пытаетесь решить. Поэтому, занимаясь какой-нибудь задачей, проверьте сначала, не решена ли уже эта проблема.
Сделать это можно так:
- Поискать существующие пакеты и библиотеки.
- Просмотреть такие сайты как GitHub и StackOverflow в поисках похожих решений для вашей проблемы.
Это отнюдь не означает, что можно бездумно копипастить чужой код! Если вы берете чужой код в качестве примера, важно понимать, что делает этот код и почему.
- Почему в этом коде использован определенный шаблон проектирования?
- Почему код написан именно на этом языке? (К примеру, Node.js или Python).
- Какие помехи могут возникнуть? Будет ли этот код работать в вашей текущей кодовой базе?
Если вы не уверены, всегда можно спросить коллег по команде. Поиск в Google также является распространенным подходом к решению задач. Так что не бойтесь обратиться к коллегам с вопросом:
«Я подумываю использовать эту библиотеку Х или этот пакет Y, я видел некоторые примеры вот здесь, что вы думаете по этому поводу?»
Это не только покажет вашу проактивность, но и послужит началом обсуждения этого вопроса в команде. Возможно, вы открыли нечто прекрасное, о чем до сих пор никто не знал!
Научитесь читать код
Все мы видели эти фильмы, где хакер бегло печатает, а по экрану бегут страницы кода.
В реальном мире разработчики тратят больше времени на чтение кода, а не на его написание.
Добавляя новый функционал или исправляя дефект, вам нужно будет разобраться в существующей кодовой базе, с которой вы работаете. Как это сделать? Читать, читать и читать!
Чтение кода это также отличная техника обучения. Читая существующий код, вы можете видеть, как другие люди разрабатывали определенный функционал.
При этом следует обращать внимание на следующие вещи:
- Использование шаблонов проектирования.
- Именование методов, классов и переменных.
- Использование комментариев.
- Как структурировать файлы проекта.
- Использование и структура тестов.
Где найти код для чтения?
- Репозитории на работе.
- Проекты на GitHub.
- Чтение вопросов/ответов на StackOverflow.
- Сайты с задачами на программирование, например, codewars.com, где приводятся ответы.
Удачи!
Если вы примете на вооружение только один совет из этой статьи, пусть это будет следующий: обязательно получайте удовольствие. Наслаждайтесь написанием кода, решением проблем и непрекращающейся учебой. Вы стоите на старте захватывающей карьеры, так что откиньтесь на спинку кресла и получайте удовольствие от путешествия!
Бонусные советы
- Изучайте жаргон. У нас, разработчиков, свой забавный язык, так что убедитесь, что понимаете основные термины.
- Познакомьтесь со своей IDE. Изучите горячие клавиши, сочетания клавиш. Настраивайте все это до тех пор, пока вам не станет удобно. Это повысит вашу продуктивность.
- Исправление багов это отличный способ изучить кодовую базу. Так что не бойтесь браться за это дело!
- Носите с собой записную книжку, внимательно слушайте и все записывайте.
- В свободное время занимайтесь сторонними проектами. Это хороший способ изучения технологий, которые вы не изучаете по работе. Также это улучшит ваше резюме.
- Принимайте участие в мероприятиях на работе – так вы познакомитесь с коллегами. Можете даже организовать собственное.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]