Как BBC iPlayer обеспечивает рентабельное обучение инженеров инженерами?

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

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

Зачем создавать техническую мастерскую?

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

Индивидуальные семинары могут быть эффективным способом обогатить навыки разработчиков. Вот некоторые из преимуществ:

  • Материалы семинара могут быть адаптированы для решения конкретной задачи или проблемной области. Например, переключение с обратных вызовов на обещания в Javascript или использование лямбда-выражений в Java.
  • Формат семинара может быть гибким. Например, самостоятельная, парная или групповая работа.
  • Своевременность. Планирование семинара может быть выполнено в соответствии с потребностями команды и включено в сеансы планирования.
  • Скорее всего, дороже, чем заказ книги, но дешевле, чем внешний обучающий курс.
  • Практические занятия по программированию. Фактическое «время клавиатуры» - важная часть обучения разработчиков.
  • Знакомство с новой технологией можно получить с помощью упражнений на семинаре и выявить недопонимание / предположения. Лучше ошибаться во время обучения, чем в производственной среде (хотя все мы ошибаемся).
  • Помимо людей, посещающих семинар, это также может быть отличной кривой обучения для автора.
  • В зависимости от контента и формата возможно повторное использование семинаров и потенциально открытый исходный код контента.

Хорошо, звучит здорово, но каковы недостатки? :

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

Как написать семинар по программированию?

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

Примером этого является асинхронный семинар.

Цели содержания заключались в следующем:

  • Получите знания об асинхронности / ожидании Node
  • Попрактикуйтесь в рефакторинге до asnyc / await из обратных вызовов / обещаний
  • Последствия использования async / await. Например, меньше полагаться на сторонние библиотеки для обработки асинхронного поведения.
  • Получите опыт реализации асинхронных шаблонов (например, ограничение карты, уменьшение и т. Д.)

Семинар реализован как Node-проект. Разработчики выполняли ряд упражнений, которые обычно включали завершение или исправление некоторого кода. Каждое решение подтверждается соответствующим тестом. Эта практика, конечно же, основана на разработке через тестирование (TDD), которая широко используется в командах разработчиков iPlayer.

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

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

Другие цели

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

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

В рамках разработки iPlayer мы также проводили семинары по аспектам AWS и ElasticSearch; его не обязательно ограничивать языками программирования.

Вывод

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

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

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