Чего ждать в первую неделю в должности разработчика программного обеспечения

1656627491 chego zhdat v pervuyu nedelyu v dolzhnosti razrabotchika programmnogo obespecheniya

от Гарриет Райдер

RYO2lWPKnPng9QjfUdZX6bNVOMuiXhUneDjR

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

Я не мог вообразить свою первую неделю на новой работе. Вы сразу начинаете кодировать? Что делать, если они используют язык/фреймворк, который вы не выучили? Как вы осваиваете кодовую базу и знаете какие приоритеты? Легко ли попасть в команду? Вы просто… открываете редактор и начинаете кодировать? Что делать, если вы что-нибудь ужасно попадете не так и все сломаете?

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

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

Фон

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

Все сервисы работают на AWS, мы используем NodeJS и Ruby.

День 1: в основном настройка

Я пришел в офис в 9 утра. На моем столе меня ждал новый блестящий MacBook Pro с адаптерами и двумя экранами. Команда разработчиков привела меня на завтрак в соседнее кафе, а когда мы вернулись, я сел и принялся настраивать свой аппарат.

Поскольку я настраивал бесчисленное количество сред для разработчиков, работая на учебном курсе по кодированию, это было достаточно просто и не заняло у меня много времени. Однако я только один раз настроил среду Ruby/Rails на своем ноутбуке, поэтому эта часть заняла у меня немного больше времени.

Мне предоставили лист формата А4 с указанием требований, номеров версий и т.п., которые я внимательно соблюдал. Я также получил доступ к разным сайтам, таким как BitBucket, менеджер паролей, AWS и Gitlab, и настроил мои ключи SSH на моей новой машине.

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

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

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

День 2: Тестирование

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

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

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

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

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

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

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

День 3: AWS

В рамках выпуска, который мы проводили, нам нужно было решить, как развернуть службу, которую мы создавали. Мы использовали AWS, но был выбор между использованием экземпляра EC2, который был бы самым простым выбором, поскольку это просто сервер в облаке, на котором запускается ваше приложение, или чем-то более модным, как Elastic Container Service. Преимущество ECS заключается в том, что он будет управлять масштабированием нескольких экземпляров EC2 и будет хорошим вариантом для будущего. Но пока это было не совсем важно.

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

Это потребовало много обучения для меня, поскольку я раньше не использовал ECS Amazon, плюс приложение было приложением Rails, и я был гораздо меньше знаком со всей экосистемой Ruby/Rails. Я потратил, возможно, 30 часов на изучение Ruby, прежде чем присоединиться к компании, поскольку знал, что это часть их стека, но я едва коснулся Rails. Кроме того, задача предполагала небольшую работу с Docker, что тоже было для меня новым.

Мой технический лидер побуждал меня начать с того, что в основном было 1-часовым вступлением в Docker, что было чрезвычайно полезным. С этого момента я потратил большую часть дня, создавая новую программу Rails и следя за разными статьями, документами и примерами, чтобы увидеть, смогу ли я запустить это на ECS. Я почти дошел, но интеграция базы данных оказалась камнем преткновения. Просто было так много нового.

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

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

День 4: создание пара и наставничество

Я прибыл в офис в 8 утра, и пока я ожидал прибытия других, я прошел часть Docker курс, который я смотрел на Pluralsight. Я все еще хотел завершить вчерашний всплеск, но понял, что мне нужно больше основываться, по крайней мере, на одной из новых технологий, с которыми я работал.

Я потратил около часа на курс, прежде чем в офис прибыло больше людей, и мы решили, кто будет что делать. Еще один новый разработчик, начинавший немного раньше меня, только что вернулся из отпуска. Мы решили, что объединимся в одну задачу. Мы создавали новую функцию в приложении Rails. Это была довольно простая задача, но Rails был новым для нас обоих, поэтому было отлично работать вместе. Когда нам нужно было что-то объяснить, мы просто спрашивали кого-то из других разработчиков лично или у Slack. У нас было несколько отличных обсуждений, и я начал понимать, как работает Rails.

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

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

День 5: Встречи и слияния

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

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

Мы также идем на завтрак, чтобы подружиться, что здорово!

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

Во второй половине дня мы с моей парой смогли завершить, над чем работали, пригласить проверку кода, внести поправки и открыть запрос на объединение нашей работы в программу. Мы не развернулись, поскольку это была пятница днем, но мы сделали в следующий понедельник. ?

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

Буду рад услышать ваши комментарии и опыт!

Добавить комментарий

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