Менторинг и парное программирование

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

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

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

Теперь давайте об этом более подробно.

О парном программировании

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

До последнего времени у меня не было личного опыта парного программирования, поэтому мое мнение было сугубо теоретическим. За последние полгода у меня появился какой-то опыт, и именно им и хотелось бы поделиться.

Итак, начнем с проблем.

Hero Pattern

На некоторых особо популярных мировых галерах нередко можно встретить заболевание под названием Hero Pattern. Идея его в том, что гребец трудится усердно и много, монополизируя некоторый фронт работ, чтобы показать свою ценность и получить годовые плюшки с возможным повышением по службе.

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

Динамичность рынка труда требует роста на всех уровнях. Гребцы поматерее выдвигаются в рулевые, что автоматом выстилает дорогу в синьеры всем желающим. Просто нахождение тела на проекте автоматом дает ему шансы на продвижение независимо от талантов и умений. Наличие головы на плечах позволит довольно уверенно двигаться наверх внутри конторы. А в случае проблем на текущем месте, всегда найдется другой епам, которому позарез нужно стартовать очередной проект, и который не пожидится на +500 в месяц за тебя красивого.

О шаринге знаний и компетенций с коллегами

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

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

Для меня – делиться знаниями, даже скудными, это означает узнавать что-то лучше самому. Когда приходится рассказывать об архитектуре или используемых паттернах своему коллеге, то ты автоматически воспроизводишь все решение в голове и оцениваешь его валидность/корректность. Если коллега опытный, то он легко подправит твое понимание проблемы. Если же он новичок, то его стеклянные глаза будут прекрасным индикатором кривизны архитектуры или показателем полного отсутствия у тебя скила по донесению сложных вещей слушателю.

Инкапсуляция и сокрытие информации

В области проектирования существует два понятия, которые часто используются совместно – инкапсуляция (encapsulation) и сокрытие информации (information hiding).

Понятие инкапсуляции обычно используется в контексте ОО-языков и означает сокрытие данных (*). Открытые изменяемые (**) данные нарушают инкапсуляцию, поскольку теперь любой клиент класса сможет изменить внутреннее состояние объекта без ведома самого класса. Это может нарушить некоторые инварианты, т.е. условия на которые расчитывал автор класса и на которые, формально или неформально, должны полагаться его клиенты.

(*) – иногда понятие инкапсуляции применяется в более широком смысле. Например, говорят, что фабрика «инкапсулирует» информацию о конкретном типе создаваемого объекта. В этом контексте инкапсуляция является синонимом сокрытия информации.

(**) – хотя принято считать, что у класса недолжно вообще быть открытых данных, но с практической точки зрения, открытое неизменяемое поле хоть и нарушает инкапсуляцию, обычно не приводит к таким же серьезным проблемам сопровождения, как открытые изменяемые данные.

Что не так с оператором switch?

В обсуждении одного из моих ответов на ru.stackoverflow в G+ был поднят вопрос по поводу того, является ли оператор switch design или code smell-ом?

Тут нужно быстро вспомнить, откуда ноги вообще растут (ИМХО). В наших с вами разных языках программирования существует много разных способов решения одной и той же проблемы. Например, когда у нас есть определенная задача (нарисовать фигуру?!) и несколько разновидностей входных данных (круг, квадрат, прямоугольник?), то решить ее можно разными способами. Можно взять впихнуть тип в структурку и в методе draw перебрать все возможные варианты.

С точки зрения серьезного объектно-ориентированного программиста, такой подход считается негодным, нерасширяемым и вообще, неправильным. Ибо об этом писал дядюшка Боб Мартин, который будет потом приходить по ночам в страшных снах и мучить бедных программистов страшными вещами, типа добавлением новой фигуры каждые 42 минуты.

Принцип YAGNI

На ru.stackoverflow.com недавно был задан вопрос, который, ИМХО, стоит вашего внимания: Нарушает ли OCP и DIP (из SOLID) принцип YAGNI?. Ниже представлен немного более развернутая версия моего ответа.

Разные принципы проектирования направлены на решение противоречащих друг другу задач проектирования. Можно сказать, что разные принципы «тянут» дизайн в разные стороны и нужно найти правильный вектор, наиболее полезный в данном конкретном случае. SRP толкает в стороны простого решения, а OCP – в сторону изоляции компонентов, а DIP – направлен на построение правильных отношений между типами.

Следование одному принципу может привести к нарушению другого. Так, например, любое наследование *можно* рассматривать как нарушение SPR, поскольку теперь за одну ответственность (рисование фигур) отвечает целая группа классов. Принципы DIP и OCP, которые часто требуют наследования, могут привести к появлению дополнительных «швов», т.е. интерфейсов/базовых классов в системе, что, опять-таки, приведет к нарушению SRP и/или ISP.