Почти год уже прошел как я переехал жить и работать в Ереван из Москвы. В этой истории я расскажу вам не про свою жизнь в этом замечательном городе (здесь очень здорово), а про более приземленные вещи. А именно, про практики которые мы применяем при разработке нашего продукта в Vineti.

Если вам все еще интересно, то добро пожаловать под кат.

В Vineti мы используем extreme programming методологию и активно применяем парное программирование. Когда я пришел в Vineti для меня экстремальное программирование было чем-то новым и неизведанным, но спустя год разработки в таком стиле могу сказать, что теперь одиночное написание кода для меня стало чем-то не слишком удобным и продуктивным.

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

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

Преимущества подхода

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

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

В Vineti мы используем TDD в процессе парного программирования, что позволяет изначально разбить большую и сложную задачу на маленькие части и продумать архитектуру решения еще до момента написания кода. Также в решении сложных задач сильно помогает наличие партнера с которым можно обсудить выбранный подход к решению задачи и проанализировать его оптимальность прямо в процессе работы без необходимости планировать дополнительные встречи внутри команды.

Ну и последнее, парное программирование хорошо сочетается с методологией TDD. В Vineti, обычно, один инженер пишет тесты и старается описать как можно большее количество ситуаций. Второй инженер пишет код фичи, когда первый инженер подсказывает каким образом можно упростить код, тем самым реализуется red-green-refactoring круг.

Недостатки

К недостаткам данного подхода, я бы пожалуй отнес сложность наладки самого процесса и необходимость правильного подбора участников в парах, что требует от лидера команды дополнительных усилий и тонкого понимания навыков и привычек всех членов его команды.
Если говорить о человеческом факторе, важно чтобы инженеры которые в данный момент находятся в паре на период совместной работы имели общий режим прихода в офис, обеда и т.д. Это не всегда просто сделать и необходимо формировать пары с учетом этой особенности.

Поддержание общего стандарта

Одно из условий эффективного парного программирования — это наличие строго и максимально стандартизированного подхода к написанию кода внутри команд. Например, мы используем eslint, prettier, rubocop для того, чтобы код находился в едином стиле в процессе его написания. Как среду разработки используем VS Code, а терминал iTerm c zsh. Данная стандартизация позволяет быстро совершать ротации инженеров внутри пар минимизируя период адаптации.

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

Парное программирование с Сан-Франциско

Лично у меня был опыт удаленного парного программирования с коллегой из американского офиса Vineti, для этого мы использовали Live Share plugin для VS Code. Опыт интересный, но данная ситуация имеет ряд недостатков по сравнению со стандартным парным программированием. Первое — это отсутствие непосредственного личного общения. В моем случае, это еще и сильная разница в часовых поясах. Мне приходилось писать код после почти полного рабочего дня, что, для меня лично, было очень утомительно.

Как адаптироваться к парному программированию

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

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