От стажера до миддла: как вырасти Python-разработчику

Илария Белова

Ведущий Python-разработчик отдела качества рекламы Яндекса и преподаватель Школы анализа данных

Мидл — следующий этап развития разработчика после стажёра или джуна. Ему доверяют больше интересных проектов и ответственных задач, у него чаще спрашивают совета, ему больше платят. Илария Белова, ведущий python-разработчик отдела качества рекламы Яндекса и преподаватель Школы анализа данных, рассказывает, что отличает хорошего мидла от стажёра.

Необходимый минимум

Когда стажёр только начинает работать, ему достаточно владеть базовыми инструментами и навыками:

• знать базу языка и устройство структур данных в нём;
• уметь работать в командной строке;
• уметь работать с системой контроля версий.

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

Как быстрее перейти в мидла

Однажды к нам в Яндекс пришёл стажёр, которого быстро подняли до мидла без стадии джуна. Его отличало то, что он сам инициировал задачи, которые нужно сделать: «Здесь у вас плохо. Можно сделать вот так, и станет лучше». Мы отвечаем: «Хорошо. Если это не мешает твоим основным задачам — делай». И он всё успевал делать в рабочее время и разумные сроки — не было такого, что взялся за что-то и не сделал.

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

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

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

Разбираться в структуре проекта

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

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

Умение разбираться в экосистеме проекта приходит с опытом. Чем больше разработчик погружается в проект, тем лучше он понимает его структуру. Но важно не просто «работать над проектом», а интересоваться им, пытаться понять, почему сделано именно так и для чего нужна та или иная штука. Также помогает участие в разных проектах: чем больше проектов видит разработчик, тем быстрее он учится разбираться в них.

Не бояться править чужой код

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

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

Писать чисто

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

Мы прививаем следующий подход: сделал функциональность — напиши на неё тесты, обнови документацию, поправь аннотации, сделай user-friendly тексты ошибок. Если сделал костыль и он правда нужен, то напиши об этом подробный комментарий и объясни своё решение.

Не делать фичи «на всякий случай»

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

Брать на себя ответственность

Есть несколько видов ответственности: за принятие решений и за доставку конечного продукта.

Когда во время ревью мы находим ошибки, то спрашиваем: «Почему ты сделал это именно так?» Частый ответ: «Не знаю» или «А как надо было?». Это показывает, что разработчик не пытался оценить разные варианты решения и выбрать из них. Опытный разработчик прорабатывает в голове все возможные варианты и corner-кейсы, выбирает самое целесообразное решение и несёт ответственность за свой выбор. Разница между начинающим и опытным в том, что второй перебирает больше вариантов и делает более осмысленный выбор.

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

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

Развивать критическое мышление

Бывает, ставишь стажёру задачу, а он молча начинает её делать. Если потом спросить его: «Ты понимаешь, над какой проблемой работал? Для кого ты делал задачу? Что она должна решать?», то, скорее всего, внятного ответа не будет. Это может быть чревато тем, что задачу сделали, но никакой проблемы она не решает. Например, если формулировка была неполной или не учли подводные камни. Также в голове не образуется связки, которая учит в будущем идентифицировать проблемы и подбирать адекватные решения.

Ещё нередкая ситуация, когда извне прилетают задачи, которые на самом деле делать не нужно. В таких ситуациях нужно посмотреть на задачу, понять её суть и сказать: «Тебе поможет не эта фича, а вот эта. Такое решение есть, и тебе лучше обратиться к другому отделу, вот к этому». Это отличает начинающего разработчика от опытного: смотришь на задачи, отсекаешь ненужное и фокусируешься на важном.

Изучать и следовать best practices

Для развития начинающего разработчика очень важно хорошее код-ревью. Например, в ШАД ревьюеры тщательно смотрят код, оставляют подробные комментарии, делятся своим опытом и объясняют, почему что-то не сработает. Не просто «Поправь тут», а «Это важно с точки зрения потребления памяти. Сейчас здесь мало данных, и код работает нормально. Но когда объём возрастёт в 10 раз, это может выстрелить».

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

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

Что почитать, послушать и посмотреть

Курс «Язык Python» от ШАД. Мы рассказываем про устройство языка, структуры данных, тестирование, документирование, а также затрагиваем прикладные темы: MapReduce, асинхронность, работу с сетью. На каждую тему есть много заданий, решения которых мы затем разбираем. Курс поможет не только освоить все необходимые навыки, но и разобраться в различных сферах применения языка, выбрать себе специализацию, подготовиться к собеседованию. Это задаст необходимый вектор роста.

«Чистый код» и «Чистая архитектура» (Роберт Мартин), «Совершенный код» (Стив Макконнелл). Эти три книги будут полезны для всех разработчиков. Они не привязаны к конкретному языку, но объясняют основные принципы хорошего и компактного кода. Такого, который принято использовать в промышленной разработке для упрощения поддержки и масштабирования.

«Head First Design Patterns» (Эрик Фримен, Элизабет Робсон). Это весёлая книга для тех, кто хочет узнать
больше про паттерны, но с трудом понимает академический текст. В книге собраны проверенные временем паттерны, которые используют разработчики для создания гибкого кода.

Refactoring.guru. Тут есть и про паттерны, и про best practices на разных языках, в том числе на Python, а ещё и с картинками. Много понятных примеров, на которые будет полезно взглянуть.