Transcription
Меня зовут Валерия. Я Python разработчик в компании Vlab.
На этом канале уже выходило видео на тему, какие навыки нужны Junior Python разработчику. А в этом видео я бы хотела затронуть следующую тему, которая, на мой взгляд, очень логично вытекает из предыдущей.
Что необходимо знать и уметь, чтобы претендовать на позицию middle разработчика на Python? Мы поговорим о том, чем данная позиция отличается от позиции junior разработчика.
Какие задачи решает middle разработчик? Коснемся темы технологий и навыков, которые нужны на этой позиции, а также, конечно, не обойдем стороной и тему софт скиллов для мидла.
Давайте начнем с первой темы. Кто же такой middle разработчик и что его отличает от джунов?
С одной стороны, стоит сказать, что junior и middle разработчик зачастую не сильно отличаются по стеку. Многие технологии, с которыми сталкивается в работе middle, так или иначе затрагивал junior в рамках обучения или на проектах.
При наличии коммерческого опыта разработки разница между этими двумя позициями заключается в первую очередь в опыте решения задач и самостоятельности разработчика.
От junior разработчика вполне ожидается и даже иногда поощряется, что он будет обращаться с вопросами к старшим коллегам, например, с уточнениями по вопросам лучшей реализации с точки зрения кода, с разъяснениями ТЗ или с вопросами по выбору технологии для решения той или иной конкретной задачи.
В свою очередь, middle разработчик уже считается вполне самостоятельным разработчиком на проекте, который способен самостоятельно разобраться в ТЗ, увидеть узкие места, оценить риски и обсудить их перед тем, как приступить к выполнению задачи.
Middle разработчик закладывается на возможные изменения в ТЗ и организует свой код с точки зрения архитектуры так, чтобы впоследствии максимально безболезненно можно было внести в него все необходимые изменения при реализации какой-то задачи.
Middle разработчик чаще всего учитывает и неожиданное поведение, какие-то ограниченные кейсы, которые вполне возможно не были описаны в самой задаче. В целом, более глобально смотрит на проект и на реализацию.
Конечно, как и junior, middle разработчик может обращаться за советами, но чаще всего ожидается, что его знания специфики проекта и технологий, которые на проекте используются, вполне достаточно, чтобы он смог самостоятельно принять решение о наилучшей реализации, подобрать подход с точки зрения организации кода или, например, использования библиотек.
В целом, разработчик на позиции middle — это разработчик, который в большинстве случаев самостоятельно решает задачи, пишет понятный код, умеет оценивать риски и видит подводные камни при анализе ТЗ, которые учитывает и при реализации.
Но всё это, конечно, довольно размыто. В чём конкретно заключается разница между задачами middle и junior?
Поскольку проекты и задачи в разных командах очень разные, то, наверное, однозначно ответить на этот вопрос вряд ли получится. Поэтому предлагаю пройтись по нескольким общим темам, с которыми с большой вероятностью можно встретиться на проектах, и на их примерах попробовать понять, в чём разница.
Также затронем тему, какие технологии и знания могут пригодиться именно middle на его позиции. Например, конечно, понятно, что junior разработчик, как и middle, сталкивается с работой с базами данных. Это в целом зачастую такая довольно основная глобальная тема.
Но если junior обычно может в рамках задач добавлять по необходимости какие-то поля в существующие таблицы, изменять старые, чаще всего, конечно, под контролем описанной задачи или под контролем старших разработчиков, то middle разработчик вполне может столкнуться с задачей, например, переработки архитектуры таблиц базы данных или необходимостью оптимизации работы с базой данных и запросов, переноса данных из одной БД в другую или из одной таблицы в другую с учётом разницы между этими таблицами.
Поэтому, на мой взгляд, middle разработчик должен на куда более высоком уровне освоить SQL и ORM, который используется у вас в команде, а также инструмент миграций.
Зачастую в таких задачах недостаточно просто там описать новое поле, запустить команду по созданию миграции и ожидать, что тот же ORM или J всё подхватит и самостоятельно сформирует все необходимые поля в файле и накат.
Зачастую задачи могут быть куда сложнее, поэтому полезно знать, как использовать миграции, например, execute в Alembic или Run SQL migration в J, а также правильно описывать дайд для миграции.
Особенно это важно, когда разработчик работает с уже существующей базой данных, в которой хранятся реальные данные. Конечно, разрабатываем мы локально, но все эти миграции, понятное дело, потом всё равно перекачиваются.
Стоит знать и иметь в виду, но всё равно для middle эти задачи достаточно актуальны, и стоит углубить своё внимание и потратить своё время на то, чтобы в этом разобраться.
Также стоит отметить, что иногда требования по задаче предполагают написание сложных запросов, поэтому здесь может пригодиться использование агрегирующих функций как в Row SQL, так и в ORM, который разработчик использует на проекте, таких как, например, array_aggregate, key_join, build_object и так далее.
Middle разработчику также может потребоваться использование подзапросов, CTE, например, Common Table Expressions или оконных функций.
Под видео я оставлю ссылку на документацию по SQL, где многие такие функции перечислены, а также несколько статей, где можно ознакомиться с CTE и оконными функциями.
Также при работе с базами данных и запросами часто может возникнуть необходимость оценки производительности запросов, а также их оптимизации.
Поэтому хорошо было бы разобраться с использованием EXPLAIN ANALYZE. Особенно это касается навыка чтения и понимания вывода EXPLAIN. Это позволит оценить производительность.
Также для middle разработчика актуально разобраться с темой индексов, понять отличия, какой индекс для чего применяется, что такое селективность, ну и, конечно, как индексы создавать и какие существуют у индексов так называемые подводные камни.
Например, почему не стоит создавать индекс на каждое поле, почему поддерживать индексацию довольно ресурсоемко.
По теме индексов также под видео будет оставлено несколько ссылок.
Ещё один кейс, с которым middle разработчик может потенциально встретиться в рамках работы с базами, это шардирование.
Поэтому хорошим навыком будет понимание, как работает шардирование и партицирование, по каким принципам стоит разделять таблицы, как такие таблицы или записи таблицы впоследствии нить и выполнять операции удаления, вставки, обновления данных.
Ссылки даже прикладываю.
Одним из способов оптимизации работы с БД может также являться кеширование, которое зачастую реализуется с использованием NoSQL баз данных.
Также может использоваться для кеширования результатов запросов, хранения сессий пользователей, хранения каких-нибудь глобальных счётчиков или состояний для восстановления системы после падения, например, ну и многих других задач, с которыми, кстати, middle разработчик вполне часто будет сталкиваться.
Поэтому не будет лишним сказать, что middle хорошо бы иметь представление достаточно глубокое о работе, например, того же Redis.
Как хранить, извлекать данные из хранилища, использовать префиксы для разделения данных, упрощения операций и минимизации коллизий и так далее.
Ссылку даже прикладываю.
Говоря о фоновом выполнении задач, также стоит отметить и работу с Celery. Если говоря о junior разработчиках, я вскользь упоминала о том, что стоит иметь представление об этой технологии, то в случае middle разработчика очень велика вероятность, что на проектах часто придётся сталкиваться с этим инструментом.
Причём как для выполнения фоновых задач, которые можно запускать по крону, так и для запуска мультипроцессорных вычислений, которые также необходимо проводить в фоновом режиме.
Тут стоит почитать, что такое воркеры, как определять файл конфигурации для Celery и запускать воркеры, также какие пулы исполнения поддерживает Celery, какие пулы исполнения подходят для I/O Bound и CPU Bound операций, как, например, запустить сразу же несколько параллельных процессов для выполнения задач и, конечно, как обрабатывать исключения.
Несколько ссылок по работе с Celery я также прикладываю.
А также в рамках работы не на всех, но на многих проектах middle разработчик будет сталкиваться с микросервисной архитектурой.
Вряд ли middle будет отвечать за построение всех элементов в этой архитектуре, но он вполне может заниматься разработкой и поддержкой какого-то одного из сервисов, а может и нескольких.
В проектах, которые реализованы на базе микросервисной архитектуры, часто используются распределённые транзакции, поскольку сервисы, отвечающие за разную логику, хранят данные в независимых базах данных.
Поэтому middle разработчику требуется понимать, как реализовывать распределённые транзакции, как использовать систему отката, то есть отката в случае возникновения каких-то ошибок и исключений для сохранения консистентности взаимодействия.
Для этого может использоваться как HTTP, так и очереди сообщений, такие как уже упомянутый RabbitMQ или, например, Kafka и Redis.
Поэтому от middle всё-таки ожидается, что он понимает, как выстраивается такая архитектура, знает технологии, которые могут позволить обеспечить более успешное выстраивание этой архитектуры.
Полезно будет разобраться также с такими паттернами коммуникации между сервисами, как оркестрация и хореография, использование продуктового двухфазного коммита и использовать их на практике при работе.
Несколько ссылок по всем вышеупомянутым темам я также прикладываю под видео.
Давайте также поговорим немножко про такие в общих чертах дополнительные навыки.
Middle разработчик вполне может сталкиваться с задачами, которые касаются не только непосредственно разработки и написания кода. Среди таких задач может встретиться, например, настройка Nginx для балансировки нагрузки или, например, развёртывание обратного прокси-сервера, описание Docker файла и Docker Compose, а также настройка CI/CD, например, в GitLab CI/CD или GitHub Actions.
Также вполне вероятно, что middle разработчику может придётся сталкиваться в работе с такими технологиями, как OpenShift и Kubernetes, например, для оркестрации контейнеров, особенно если у вас на проекте используется микросервисная архитектура.
Эти инструменты предоставляют дополнительные интерфейсы для управления кластером и кластером контейнеров, или же для управления конфигурацией, секретами, просмотра логов и мониторинга.
Ещё среди прочего стоит отметить, что если мы говорим о веб-разработке, то далеко не всегда в работе будет использоваться протокол HTTP.
Вполне можно столкнуться и с такими протоколами, как SSE, то есть Server-Sent Events, или веб-сокетами, или, например, AMQP, ориентированными на брокеров сообщений.
А где-то может также потребоваться, например, GraphQL, что, конечно, не совсем протокол, но спецификация для запросов и работы с API, которая выступает альтернативой.
Стоит также упомянуть и знание алгоритмов. Конечно, вряд ли в работе вы будете использовать там сортировку пузырьком или вставками. Они больше подходят для изучения, чем для работы.
Но при работе с большим объёмом данных алгоритмы могут очень пригодиться, например, для реализации эффективного поиска или работы с массивами, последовательностями.
И, конечно, очень много будет зависеть от конкретного проекта, на котором вы работаете, и какие-то из технологий, которые я упомянула, могут не встречаться, например, у вас на проекте, или же вы можете работать с такими, которые я не упомянула в этом видео.
В любом случае, надеюсь, что, возможно, вы услышали что-то новое или хорошо забытое старое, а ссылки пригодятся вам для того, чтобы как-то это вспомнить или почитать и узнать что-то новое.
Ну и последнее, о чём хотелось бы поговорить, — это софт скиллы.
Разработчик, активно вовлечённый, умение договориться с командой — это, наверное, один из самых первых навыков, которые стоит упомянуть.
Также вполне вероятно, что на этой позиции вы уже будете выступать в роли ментора для младших коллег, поэтому тут также очень поможет коммуникация и умение объяснить, подсказать, а простым языком объяснить какие-то тонкости и нюансы, которые на самом деле, возможно, простыми и не являются.
А где-то middle разработчик также участвует в превью, поэтому здесь навык общения и корректного донесения своих мыслей будет особенно актуален.
Также, конечно, очень классный навык — это гибкость. Задачи могут быть сформулированы порой неточно, ТЗ может поменяться в процессе, а вам в любом случае эти такие таски придётся закрывать.
И очень важно уметь адаптироваться к таким изменениям, а также стараться мыслить не шаблонно, особенно если вы, например, работаете с каким-нибудь legacy кодом.
Что вполне может произойти, то что задачу когда-то реализовали так, а не иначе, не означает, что нет другого более понятного или оптимального решения.
Старайтесь рассматривать проблемы под разными углами.
И ещё один навык, наверное последний, который я уже упоминала, и мне кажется, что он очень важен для middle разработчика — это самостоятельность.
Если вы понимаете, что вполне сможете самостоятельно найти ответы на возникающие вопросы, то огромным плюсом будет, если вы всё-таки постараетесь это самостоятельно сделать, не отвлекая коллег по каждому возникающему вопросу.
Ну то есть это, конечно, не означает, что обращаться за советом — это плохо. Просто обращаться стоит, когда вы уже попробовали разобраться сами, возможно, поняли какой-то общий бэкграунд по проблеме, но так, например, не смогли до конца разобраться.
Тогда уже со всей полученной информации стоит идти за помощью, и велика вероятность, что пока вы будете разбираться сами, помощь вам больше не потребуется. Вы самостоятельно докопаетесь до сути.
Ну, собственно, на этом всё. Спасибо за внимание! Если остались вопросы, буду рада ответить на них в комментариях. Всем пока! [музыка]