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

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

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

Совет №1: учись решать реальные задачи

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

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

Если человек потратил всё свободное время только на подготовку в собеседованию, то на испытательном сроке у него возникнут проблемы. Знания работы сборщика мусора или принципов аллокации памяти при увеличении хеш-таблицы не помогут при написании нового метода API. Хотя последняя задача является довольно распространенной на проектах с микросервисной архитектурой.

Но что делать, если реального опыта мало, или он вовсе отсутствует? Можно попробовать его получить, участвуя в сторонних open source проектах или, например, создавая собственный проект на гитхабе. Придумать несложное приложение из двух частей. У каждого будет собственная база данных. Отлично, если одна из них является NoSQL, а другая — SQL. Между частями приложения организовать асинхронное взаимодействие с помощью брокера сообщений. Использовать API для управления всей системой. Задача будет очень похожа на то, с чем сталкиваются разработчики на реальных проектах.

Совет №2: накапливай базу знаний

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

И на протяжении всего периода коллегам нужно уделять время новому члену команды, чтобы поделиться с ним экспертизой. Поскольку передача знаний приводит (на короткой дистанции) к снижению продуктивности всей группы в целом, то новичку следует тщательно фиксировать информацию, которой с ним делятся. Ведь у опытных коллег нет времени отвечать на одни и те же вопросы много раз. Для фиксации подойдет любой доступный способ: Obsidian, Notion, избранное браузера или старая-добрая тетрадка. Собственная база знаний поможет сберечь время окружающих и упорядочит свежую информацию.

Совет №3: придерживайся стандартов

Каждая команда живёт по своим правилам. Их спектр невероятно широк. Например, включать камеру во время ежедневной встречи или обязательно начинать её не с рабочих тем; раз в пару недель проводить внутрикомандное обучение; особым образом оформлять задачи для более удобного их сопровождения. Рекомендуется соблюдать принятые в коллективе правила (если они не противоречат внутренним установкам, но это совершенно другая и, наверное, не частая история). Таким образом будет легче наладить с коллегами контакт, а какие-то принятые стандарты позволят увеличить скорость и качество разработки.

Кроме того имеют место правила, принятые внутри компании. Это и есть корпоративная культура. Знакомство с ней позволит также разобраться с широким диапазоном вопросов: от того, как обращаться к коллегам внутри компании, до принципов, которыми руководствуются сотрудники при исправлении ошибок. Если же посещать внутренние выступления руководителей, то можно понять, куда движется компания, что довольно часто влияет на жизнь команд.

Совет №4: пользуйся отладкой

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

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

Отладка кода на своем компьютере значительно уменьшит время выполнения задач. Например, разработчик по какой-то причине не стал использовать локальную отладку и решил разбираться с проблемой с помощью логов на STG-окружении. Так как в компании используется непрерывная поставка (CD), время установки новой версии кода занимает от нескольких минут. Далеко не всегда достаточно одного раза, чтобы понять по логам, что с системой не так. Требуются исправления и новые запуски пайплайнов. Поэтому выполнение задачи может растянуться на дни и даже больше.

Совет №5: пиши чистый код

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

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

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

Совет №6: не забывай про тесты 

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

Конечно, тесты должны быть осмысленными и выполнять перечисленные задачи. Если они покрывают 90% кода, который используется в 10% случаях, то пользы от потраченного на них времени немного. Также сложно работать с негибкими тестами, которые сильно нужно дорабатывать при малейшем изменении кода.

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

Совет №7: участвуй в ревью

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

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

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

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

Совет №8: доводи задачи до прода

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

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

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

Совет №9: берись за новое

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

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

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

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

Совет №10: обновляй документацию

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

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

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

Совет №11: погружайся в SQL

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

• ACID; 

• уровни изоляции; 

• индексы; 

• запросы на объединение; 

• оптимизация запросов. 

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

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

Во-вторых, крайне редко методы API представляют все возможности к манипулированию данными. Уверенное владение SQL позволит, при наличии доступа, быстро исправить некорректно обработанные данные.

В-третьих, попадаются задачи на получение какой-либо аналитики. Навыки работы с командами типа FILTER (WHERE), COALESCE, ROW_NUMBER() OVER (PARTITION BY) или даже CROSSTAB() помогут быстро получить отчёт для дальнейшего анализа.

В-четвёртых, опыт работы с оптимизацией запросов позволит получить быстрый и внушительный результат. Иногда достаточно поменять поля в фильтрации или убрать из SELECT избыточные поля, чтобы производительность значительно увеличилась.

Совет №12: не бойся

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

Например, страх спросить что-то “глупое”. Хотя большинство из нас слышали фразу: “Худший вопрос - не заданный вопрос”. Тем не менее кажется, что выяснение чего-то банального сильно понизит твои шансы на успех. Но это не так. Во-первых, нельзя знать все. Даже у самых опытных разработчиков есть “слабые” места или даже пробелы в знаниях. Во-вторых, обычно коллеги снисходительны к новичку, особенно на испытательном сроке. А, в-третьих, спросить напрямую - самый короткий путь к получению информации, необходимой для решения задачи. Если этого не сделать, то срок выполнения начнет увеличиваться, что приведет к появлению настоящей проблемы. 

Также не стоит бояться ошибок. Есть же известное и очень справедливое: “Не ошибается тот, кто ничего не делает”. Кроме того для грамотного тимлида важнее не столько количество ошибок своего подопечного, сколько его реакция на них. Потому что правильное исправление промахов ведет в будущем к резкому уменьшению их количества.

Заключение

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