Привет! Меня зовут Андрей, я бэкенд-тимлид в KTS.
Когда у вас в компании появляются стажёры или джуны, на первых порах они погружаются в процессы, подтягивают хард-скилы и знакомятся с командой. Стажёр постепенно становится джуном. Чтобы продолжить рост и стать мидлом, ему необходимы начальные навыки проектирования. Проблема в том, что часто взять эти навыки просто негде.
В статье расскажу про методику обучения проектированию в нашей компании.
Содержание:
Задачи джунов и стажёров после появления в компании
На первых порах новичок занимается погружением: знакомится с инфраструктурой, CI/CD и экосистемными приложениями, потихоньку начинает вливаться в коллектив и получает понятные задачи. Вместе с наставником он принимает участие в дейли-встречах, получает задачи и подробно разбирает их, тоже с наставником: мы проговариваем весь цикл, как сделать и как протестировать.
На этом уровне об опыте именно в проектировании речь не идёт. Стажёр просто реализовывает полностью оговоренное решение.
В какой-то момент стажёр становится уверенным джуном, который хочет расти в сторону мидла. И тут мы сталкиваемся с проблемой.
Что должен уметь джун, чтобы стать мидлом
Скоп проблем мидл-разработчика шире, чем у джуна. Джун выполняет понятные задачи с небольшой долей неопределённости. Мидл уже немного умеет проектировать.
Вот характеристики грейда «Мидл 1» из нашей матрицы грейдов:
-
Участвует в обсуждении реализации блоков функционала
-
Зона влияния: часть проекта / небольшой проект
-
Задачи по разработке: может решить практически любую продуктовую задачу (фича / фикс багов), может быть наставником
-
Навык проектирования: проектирует простые задачи самостоятельно. Участвует в проектировании сложных задач.
Проблема нехватки навыка проектирования
На этом месте у джуна может появиться ступор. Раньше ему нужно было решать только понятные задачи. А чтобы стать мидлом, джун уже должен уметь что-то проектировать. Получается, что нужно сделать прыжок от юнлинга до джедая: в траектории развития есть точки: «Джун» → «Мидл», но между ними не хватает промежуточного этапа «Джун, который учится проектировать».
При этом конкретно в нашей компании есть дополнительное требование. У нас работают разные команды с разной спецификой. Например, может быть один большой длительный проект, как «Личный кабинет сотрудника Пятёрочки», а может быть много небольших — как в отделе рекламных спецпроектов. В каждом направлении есть какие-то скилы, которым уделяется больше внимания.
Вывод: нужен этап, когда человек может получить опыт проектирования.
К этому процессу есть дополнительные требования:
-
джун не должен набить серьёзных шишек, чтобы не растерять мотивацию
-
джун не должен подорвать эффективность рабочих проектов, пока набирается опыта
-
желательно, чтобы при обучении джун закрывал пробелы, которые неизбежно возникают из-за разной специфики работы над проектами
Варианты решения
Парное проектирование
Плюсы
-
Наставничество. Джун работает в паре с опытным специалистом, что позволяет быстро учиться на практических примерах.
-
Обзор различных подходов. Джун может увидеть разные стили и методы проектирования, применяемые в командах.
-
Качество. Решения, принятые вдвоём, часто более обдуманные.
Минусы
-
Требует координации. Нужно согласовывать рабочие графики и обеспечивать постоянное взаимодействие участников. Поэтому часто проводить такое не получится.
-
Стресс. Для джуна может быть сложно представить свою работу на ревью перед опытными специалистами.
Самостоятельно обучение по курсам и книгам
Плюсы
-
Стандартизация. Все джуны получают одинаковые знания и навыки.
-
Масштабируемость. Одни и те же курсы можно использовать для обучения большого числа сотрудников.
-
Гибкость. Джуны могут изучать материалы в удобное для них время и темпе.
-
Большой выбор ресурсов. Существует множество книг, курсов и статей по проектированию.
Минусы
-
Менее персонализированный подход. Не учитываются индивидуальные нужды каждого стажёра.
-
Отсутствие практики. Теоретические знания без практики могут быть неэффективными.
-
Риск изучения устаревших или нерелевантных материалов. Не все доступные ресурсы актуальны для конкретной компании.
-
Невозможно убедиться, что материал хорошо усвоен.
Наша методика
Мы в компании используем подход учебного проектирования. В результате сотрудник получает необходимую насмотренность, повышает грейд и дальше развивается в этом направлении самостоятельно.
1. Постановка и описание задачи
Берём максимально понятные и при этом интересные платформы. Делаем скриншоты. В задании должны быть загвоздки и подводные камешки: важно, чтобы стажёр поломал голову над реализацией, в этом вся польза.
После этого к скриншоту каждой механики добавляем описание. Какие-то задачи стажёры уже делали, некоторые я давал в рамках технических заданий на собеседованиях в KTS. Так у меня сформировался список пояснений к кейсам. Например, если в задачах я видел повторяющиеся ошибки, то сразу добавляю в список того, что буду спрашивать на сдаче задания. Тогда джун заранее подумает над этим.
После каждого выполнения подопечным дополнительно дорабатываем и расширяем кейсы. Помечаем допущенные ошибки, чтобы спросить о них следующего подопечного и закрыть больше пробелов в квалификации.
Любая задача на разработку по макетам примерно так и выглядит: дизайнер нарисовал картинки, а бэкенд и фронтенд должны вместе посидеть, подумать и сделать «как на картинке».
Примеры задач с описанием
Ниже прикладываю примеры задач со скриншотами экранов, описанием механик, подсказками учащимся и заметками для того, кто будет проверять это задание. Одна итерация может включать разное количество задач-экранов в зависимости от сложности.
Для примера возьмём приложение для изучения иностранного языка.
Экран 1: Настройка тренажёра
Описание
Настройка своих занятий, где пользователь выставляет норму-челлендж в N тренировок в день. Тренировкой считается попытка выполнить N заданий по словам.
Параметры тренировок:
-
Количество тренировок в день
-
Длительность тренировок
-
Типы упражнений, которые будут в тренировке:
-
написание
-
аудирование (прослушать аудиозапись и выбрать верный перевод)
-
выбор правильного изображения
-
проверка произношения слова (соответствие эталону)
-
-
Наличие неправильных глаголов
Подсказки-вопросы студенту:
-
Как хранить специфичные настройки приложения с возможностью будущих доработок?
-
На что влияет настройка тренажёра (данные в БД в предложенной схеме), и как это отражается на текущем числе тренировок, которые надо сделать сегодня?
-
В настройках указываются абстрактные параметры, понятные и удобные пользователю. Действительно ли удобно так хранить параметры?
-
Нужно ли хранить историю изменения этих настроек?
Заметки проверяющему:
-
Хранить данные нужно так, чтобы при каждой смене дизайна не пришлось менять API. Поэтому это должно быть число слов, количество упражнений
-
Часто джуны, которые учатся проектировать, хотят приводить всё к одной нормальной форме. В случае настроек смело можно пользоваться JSON-полями в БД
-
Обсудить структуру JSON-поля, чтобы типы тренировок и остальные будущие доработки можно было настраивать действительно гибко
Экраны 2-3: Статистика
Описание
Активность занятий пользователя:
-
Подробная статистика тренировок за неделю, физические 7 дней
-
Агрегированная статистика за последние N месяцев
Подсказки-вопросы студенту:
-
Как хранить эту статистику?
-
Как обрабатывать галочку о выполнении всех заданий?
-
Представьте, сколько места будет занимать статистика по всем пользователям, которые каждый день учат слова. Какие оптимизации можно предложить, основываясь на этих макетах?
-
Обратите внимание на то, что подробная статистика по неделям показывает количество делений: сколько тренировок пользователь планировал пройти и сколько действительно прошёл
Заметки проверяющему:
-
Рассказать про snapshot. Можно хранить подробную статистику за крайний месяц, а всё остальное агрегировать фоновыми задачами, сохранять слепки и удалять лишние записи
-
Спросить у подопечного, как можно сделать дополнительную подписку, с которой можно увидеть более подробную стату. Идея в том, что фоновые задачи не будут удалять записи пользователей, которые платят за это деньги
-
Нужно добавить требование, что в статистике за неделю нужно видеть план по тренировкам в определённый день недели. Т.е. в зависимости от настроек количество делений в каждый день недели должно меняться
-
Нужно подвести к выводу, что нужно хранить историю изменения настроек тренажёра
-
Предложения о флажке в API «все задания выполнены» сразу отметаем. Если данные не отображаются (6/6) заданий, это не значит, что фронт не справится с отрисовкой компонента с условием
2. Подготовка решения
Несколько экранов-задач вместе составляют один большой блок.
Подопечному отводится неделя на то, чтобы подумать над его полной реализацией. На выходе должна получиться схема в Miro или Draw.io и документация в Swagger / Postman.
Процесс такого учебного проектирования не быстрый: человеку нужно разобраться и как следует подумать. Работа состоит только в проектировании. Мы останавливаемся на том, чтобы вычленить все сущности, прописать связи, запросы, продумать, как их оптимизировать, поискать паттерны для реализации той или иной механики. В итоге джун сделал API, подумал, как он должен выглядеть и как запросить картинки с фронтенда, чтобы это выглядело достаточно качественно.
Реализация подобного решения вместе с пет-проектом заняла бы кучу времени. Нас интересует именно верхнеуровневое проектирование.
Когда джун-подопечный разобрался с одним блоком задач, можно выдать следующий. Например, выше мы взяли механики тренажёра слов — это будет первой итерацией. После этого возьмём какой-то другой сервис. Будем докручивать микросервисную архитектуру, единую авторизацию сервисов, усложнять задачу и добавлять интересные механики. Так от маленьких схем это может стать большой системой и быть тренировкой уже не джуна, а мидла первого или второго уровня.
3. Сдача готового решения
Для сдачи мы назначаем личную встречу.
На проверке я смотрю схему и задаю каверзные вопросы, связанные с оптимизациями: скорость запросов, оптимизация по памяти, нормализация и денормализация данных. В вопросах пробрасываю заведомо ошибочные выводы, чтобы проверить подопечного на внимательность и погруженность в вопрос. Копаю в сторону того, что подопечный, скорее всего, не учёл, или где его решение будет неэффективным.
Даю подопечному самому додуматься до правильного ответа. Цель таких разговоров с подопечными — чтобы они самостоятельно дошли до какой-то проблемы. Не нужно говорить напрямую, что именно не так. Например, на код-ревью мы сразу говорим — вот здесь ошибка, здесь неоптимально. Тогда человек просто правит ошибки, возможно, без понимания.
До каждой проблемы в решении нужно дойти окольными путями, чтобы учащийся сам осознал её, придумал решение и принёс исправление на следующей итерации.
Обычно со 2-й итерации решение уже выглядит хорошо, и его не стыдно было бы передать в разработку при проектировании реальной системы.
Важно серьезно отнестись к проверке и каверзным вопросам. Если такое мероприятие провести просто для галочки, разработчик может переоценить свои силы вместе с ментором и при первой же ответственной задаче сильно облажаться.
В ходе реальной работы всегда попадаются подводные камни. При учебном проектировании ментор должен создать эти камни сам: подопечный предлагает решение, а ментор выступает в роли менеджера и моделирует такие ситуации, когда предложенное решение перестаёт быть хорошим. Тогда нужно откатиться назад и перепроектировать сервис, чтобы решить проблему, но не увеличивать энергозатраты.
Роль ментора — задать все каверзные вопросы, чтобы максимально проверить подопечного на прочность. Если джун-стажёр просто набросал схему — скорее всего, он нигде не ломал голову и мало что усвоил. Чем больше вы его подловите, тем лучше.
Ниже — пример проверки подопечного по задаче проектирования тренажёра слов. Все остальные этапы проверяются и проговариваются схожим образом.
Экран 1, настройка тренировок для изучения слов
Текущее решение. Чтобы хранить количество тренировок и типы зданий, используется many-to-many.
Проблема: В настройках тренажёра стоят три варианта с минутами, но на самом деле при работе с БД этот параметр ничем не поможет. Внутри минут — всегда количество слов, которое им соответствует:
-
3 минуты — 10 слов
-
5 минут — 16 слов
-
10 минут — 33 слова.
Бэкенд должен отображать глобальную ситуацию и состояние пользователя, а не визуальный интерфейс.
Если формат типа заданий поменяется, и вместо минут будут повторения, то с каждым редизайном придётся переделывать модель.
Решение: Т.к. тренировка — это всегда какое-то количество слов, именно с ним мы и работаем в БД. Тогда неважно, какие данные отправлять, все внешние изменения будут происходить на фронтенде.
Поэтому размер тренировки на бэкенде всегда равен количеству слов.
В чём ещё польза таких тренировок
Если человек начинает хорошо справляться с такими заданиями, в какой-то момент он точно научится проектировать.
А вот что ещё дают подобные тренировки.
Прокачаете знания, которыми редко пользуетесь. Например, у нас есть отдел спецпроектов с очень высокой загрузкой. Многие механики в спецпроектах похожи, о чём мы рассказали в другой статье. Проекты надо выпускать очень быстро и помногу, поэтому разработчикам часто не нужно думать о вещах, связанных с масштабированием и ростом проектов. Работа с кейсами для самостоятельного проектирования позволяет закрыть подобные пробелы в знаниях, которые нечасто нужны в работе, в насмотренности чего-то нового и необычного.
Познакомитесь с новыми технологиями. За свою карьеру вас, возможно, уже не раз переводили на новый проект, и вы тоже сталкивались со ступором перед новыми неизвестными задачами. Так же и джун впервые сталкивается с задачами на проектирование. Тренировочный кейс закроет проблему «чистого листа», и вы будете знать, куда двигаться.
Проверите познания в широком диапазоне. Это своеобразный скрининг. Например, вы думали, что ваш подопечный уже хорошо справляется, но возможности широко проверить скилы не было. Кейсы тренировочного проектирования комплексные и объёмные, которые подсветят то, чего не хватает разработчику.
Сократите цену ошибок. Все принимали неправильные решения, из-за которых срывались сроки проектов или появлялись дополнительные проблемы с бюджетом. Тренировочное проектирование позволяет уменьшить эти потери. Всё, что ментор разберёт со своим подопечным на таких заданиях, учащийся сохранит в память. Он уже не будет совершать такие же ошибки, будет иметь представление о вещах, которые ещё не проектировал в реальных условиях.
Научитесь отстаивать решение. Бэкендер может получить задание от менеджера вида: «Нужно, чтобы всё приходило за один запрос». Джун должен сам разобраться, где хорошо пойти на уступки, где нужно подумать, а где вообще нельзя идти на компромисс, потому что это решение сломает систему при масштабировании.
В моменте проектирования API разговор про всё это обязательно заходит, и сотрудник будет знать больше кейсов, что можно делать, а что нельзя.
Советы при внедрении методики
Встречи с наставником
Если в вашей компании тоже развита культура наставничества, то можно постепенно внедрить подобные активности через встречи менторов и подопечных. Например, если на встречах нет чётких целей, можно посмотреть разные сервисы и попробовать для начала вместе разобрать некоторые фрагменты. Если дело пойдёт, дальше можно немного расширить задание.
Тренировочное проектирование в других направлениях
Прыжок между грейдами, когда не хватает опыта в новых задачах, есть везде: в бэкенде, фронтенде, девопсе, мобильной разработке, аналитике. Взяв за основу нашу схему, можно провести обучение для любого специалиста.
Отзывы джунов, выполнявших задание
Дмитрий Долинский, бэкенд-разработчик KTS
На этой практике я отработал умение проектировать и прокачал другие навыки:
-
Лучше познакомился с концепцией индексов в базе данных: узнал о необходимости индексирования foreign key и разобрался, как готовые решения типа Django ORM снимают большую часть работы с разработчика
-
На примере увидел применение денормализации
-
Понял, как удобно хранить неструктурированные данные в базе в формате JSON
-
Ближе познакомился с принципами работы технологии websocket при проектировании чата. Понял, что это не так просто, как казалось на первый взгляд: необходимо обдумывать такие моменты, как отправку сообщений при обрыве соединения и получение сообщения при восстановлении соединений
Дмитрий Ивахненко, бэкенд-разработчик KTS
Я считаю, что любое обучение происходит эффективнее с наставником, и проектирование — не исключение. Ментор акцентирует внимание на неочевидных моментах, предлагает альтернативы. Благодаря тому, что процесс разбивается на несколько итераций и проводится в формате one-to-one, есть возможность спокойно обдумать подсвеченные ментором проблемы или ответить на поставленные вопросы. Думаю, что это уникальный опыт и хороший способ отвлечься от рутинных задач и багфиксов.
В чем ёще может быть интерес у джунов:
-
Ново. Решать простые рутинные задачи в какой-то момент становится скучно. А на тренировках мы берём совсем новые горизонты с микросервисами, Kubernetes-кластерами и 5 млн пользователей. Конечно, у начинающего сотрудника таких проектов в портфолио обычно нет
-
Безопасно. Людей очень расслабляет, что эта новая архитектурная ответственность не свалится на их плечи уже завтра. Это тестовый режим, и все хотят попробовать эту серьёзную нагрузку на тренажёре
-
Интересно. Многие говорили, что некоторые механики они никогда не видели. Например, можно зайти в Notion, посмотреть API и текущее решение команды, поискать собственное решение. Такие челендж-задачи могут быть интереснее, чем задачи на проектах
Заключение: пайплайн обучения
-
Ментор выдает подопечному часть выделенных в один блок экранов на проектирование. Пример задач
-
Подопечный выполняет задачу в соответствие с требованиями и подсказками
-
После каждого блока проводится ревью, на котором подопечный рассказывает о своей реализации и защищает её. Все недочёты обсуждаются и фиксируются
-
Ментор даёт обратную связь по итогам созвона. Если были допущены тривиальные или недопустимые для грейда ошибки — например, неверно реализованный M2M — можно отдельно указать на это. Но удачные, хорошие решения тоже нужно подчеркнуть
-
Подопечный исправляет недочёты. Эта часть проходит без ревью, потому что вы это уже проговорили
-
Ментор выдаёт новый блок приложения. Задача аналогичная. Cо второй итерации можно начинать обсуждать микросервисную архитектуру. В процессе проектирования можно изменять ранее проверенные схемы в целях оптимизации
-
Повторение пунктов 3-5
-
Сдача
Другие наши статьи по бэкенду и асинхронному программированию для начинающих:
-
Цикл статей «Первые шаги в aiohttp»: пишем первое hello-world-приложение, подключаем базу данных, выкладываем проект в Интернет
Другие наши статьи по бэкенду и асинхронному программированию для продвинутого уровня:
ссылка на оригинал статьи https://habr.com/ru/articles/761298/
Добавить комментарий