В комментариях к прошлой заметке о парном программировании, несколько человек выразили несогласие по поводу моей фразы о неэффективности использования этого подхода для обучения молодых специалистов. Поскольку тема менторства мне близка и интересна, я хочу развить эту мысль.
Итак, прежде всего немного контекста. В прошлой заметке шла речь об анализе классического подхода, описанного Кентом Беком в его «Экстремальном программировании», когда ни одна строка кода не попадает в финальный репозиторий, если над ней не работало два человека одновременно. Это весьма специфический вид совместной работы, главной целью которого является повышение качества кода. Обучение, обмен опытом, интересное время препровождение, все это пусть и полезные, но второстепенные артефакты этой активности.
Работа в паре действительно может быть полезна для обмена опытом, вклиниванием нового сотрудника в проект или для обучения падавана мастером. Но в этом случае, это не будет «парным программированием» в классическом понимании, это будет парная работа с совершенно другим подходом со стороны обоих участников.
Теперь давайте об этом более подробно.
Поскольку я почти год занимался формальным менторством группы из 7 человек, то накопил ряд показательных примеров. За это время было много случаев работы в паре с обучаемым, при этом моя роль была как активной (я педалю), так и пассивной (падаван педалит, а я комментирую).
У процесса обучения есть своя специфика: новая информация прилипает к мозгу падавана за счет боли и страданий ошибок и старания. Эффективное обучение требует подготовленного ума, что требует порционировать новую информацию и повторять некоторые вещи несколько раз. Также полезно ограничивать обучаемого (дабы не распылялся) и направлять его к самостоятельному решению проблемы (не давать готовых решений).
В процессе менторства я сталкивался с несколькими паттернами поведения.
Случай 1. Учебная задача
Ситуация: мы разбираем учебную задачу (это может быть и реальная задача, сути дела это не меняло) и я выступаю в роли мастера, который показывает процесс решения. При этом происходит примерно такой диалог:
Я: - Здесь мы выделяем дополнительный интерфейс, чтобы обеспечить адаптивность дизайна к будущим изменениям за счет уменьшения связанности путем использования стратегии на основе полиморфизма.
Вот что слышит при этом Подаван:
«Здесь бла-бла-бла-бла-бла-бла занудство, непонятности, глупости…» и мысли сразу же переключаются на то, что он будет делать сегодня вечером со своей любимой девушкой.
Другими словами, все мои умные слова сейчас еще ничего не значат. Падаван уважает мастера, но он просто еще не созрел ко всему этому. Поэтому, полезнее использовать другой подход. Я разбираю задачу, задавая вслух определенные вопросы: «Смотри, а будет ли проще, если мы передвинем функциональность сюда, ведь теперь нам не нужно будет думать о том, запускается ли этот код из консоли или UI-я? А что если требования изменятся и нам нужно будет добавить поддержку еще одного формата файлов? А как ты собираешься проверять, что граничные условия обработаны?» и т.п. Это все точно так же пролетает мимо ушей, поэтому эстафета в решении задачи передается ученику, который занимается (самостоятельно) решением задачи.
Через определенное время, решение готово и тут не сильно важно, как именно оно выглядит. Поскольку наступает время перемен. Я говорю, что требования меняются и нам теперь нужно обрабатывать данные параллельно, читать их не из базы, а из файла, не из апп-конфига, а из json-а и т.п. После чего падаван уходит с печальным лицом дорабатывать задание и вот после этого, мы возвращались к тому, что я говорил с самого начала: о разделении ответственностей, о важности тестируемости кода, о важности читабельности и т.п.
Подобный паттерн подразумевает совместную (парную) работу, но мы практически не кодим вместе. Каждый из нас проделывает «домашнюю работу», которую мы обсуждаем совместно.
Случай 2. Дизайн ревью
Первый случай – это чистая учеба. В этом случае работа в паре full time мастера и ученика будет не очень эффективной. Но что насчет случая работы над реальной задачей, когда молодой падаван уже вник в задачу и теперь берется интегрировать или дорабатывать ее с мастером?
В этом случае обычно происходило следующее: падаван представляет свой дизайн, а мастер путем правильных вопросов начинает его модифицировать. Выделяются новые классы, ответственность перемещается из одного места в другое. Зачастую этот процесс выглядит просто и логично с точки зрения мастера и является какой-то магией со стороны падавана.
Казалось бы, падаван должен лучше знать задачу и понимать ее решения, но опыт берет свое. Но просто показать новое решение недостаточно. Давая свои рекомендации, нужно тщательно описывать свой мыслительный процесс, в противном случае в этом не будет смысла. Вот ряд вопросов, которые возникают у молодого специалиста во время подобных ревью: «а почему в этом случае ты выделил интерфейс, а в этом нет?», «а чего ты тут наговнокодил и это нормально, а вот тут сосредоточился на качестве?», «а чем плохое мое решение, ведь оно _по сути_ ничем не отличается от твоего?».
Готовое решение со стороны ментора обычно плохо сказывается на процессе обучения, особенно в вопросах проектирования. Вместо этого лучше снова подтолкнуть существующее решение падавана в нужном направлении. Нужно валидировать готовый дизайн/решение, проверять его на прочность, спрашивая о том, как решение будет тестироваться, как будет расширяться функционал и как будут учитываться другие ограничения. Тут снова можно попробовать изменить требования, показывая, что текущее решение не выдерживает нагрузку реального мира и что доработка потребует слишком большого количества усилий.
Работа в паре и в этом случае получается весьма специфичной: мастер должен сделать очевидной проблему и отправить ученика решать ее самостоятельно. Нет смысла мастеру смотреть за каждым шагом решения. Нет смысла и решать проблему самому на глазах у ученика. Нужно дать подавану возможность ошибиться и осознать это.
Случай 3. Адаптация нового сотрудника
Ну, ок, менторство молодых специалистов – это одно. А как насчет работы в паре для обучения нового сотрудника деталям проекта? Как по мне, то этот случай слабо отличается от предыдущих двух.
Вклинивание в любой реальный проект требует времени и усилий. Можно взять нуба, посадить его рядом со сторожилом проекта и дать им работать вместе. Но это вряд ли будет эффективным. Если нуб – это нуб, то для него полноценное решение задачи более опытным коллегой будет выглядеть, как рандомный порядок действий: «Так, давай откроем этот проект и добавим сюда новый класс. Теперь перейдем сюда и сгенерим проксю. Теперь вот сюда и добавим текстовый файл, чтобы наш кодо-генератор подхватил новую модельку.» Бр… Нуб через 40 секунд зарабатывает buffer overflow и дальше сидит со стеклянными глазами, и только лишь кивает на странные фразы по поводу понятности проблемы и решения.
Адаптация нового сотрудника – это не просто совместная работа. Это правильная задача, которая потребует понимания разумно-небольшого числа конструкций в существующем коде. Это сессии с архитектурными обзорами, обзорами дизайн-решений и ограничений. Это свобода путешествия нуба по коду за его собственным компом с отдельными сессиями вопросов и ответов. И это самостоятельное решение задачи с последующим код-ревью за одним столом. Вот на этом этапе работа в паре будет полезной и продуктивной. Но не ранее.
Заключение
Работая в паре нужно понимать, какую проблему эта практика должна решить. Если это вопрос менторства, то должен быть один подход. Если это обучение нового сотрудника, то другой. Если это дизайн нового решения – то третий. А если классическая работа в паре, когда один пилит тесты, а другой лабает продакшн код – то четвертый. Ведь все эти активности довольно разные и объединяет их лишь то, что в определенный момент времени два человека находятся за одним компьютером и «работают в паре».
Комментариев нет:
Отправить комментарий