Бинарный салют, друзья. На связи, как всегда, инженер спок.
Я тут вспомнил об одной очень интересной практике – парном программировании. Бьюсь об заклад, что бОльшая часть моей аудитории слыхом о таком не слыхивала и я решил рассказать об этой, на мой взгляд, очень полезной практике, поделиться личным опытом и дать советы по её применению.
Не будем тянуть хвоста за кот, так что – поехали.
Лайкосы / Подписки / Курсы
- подписывайтесь на группу в телеграме
- подписывайтесь на канал в YouTube
- покупайте курсы по программированию
Прежде чем ответить на этот вопрос, давайте зададимся другим: «с какими проблемами постоянно борется любая команда разработчиков»?
Проблема повышения качества кода в том числе тестов, проблема раздельных знаний, когда каждый отвечает за свой участок кода, и если один человек даже временно выбывает из проекта, кому-то придётся тяжко, разбираясь с участком кода, за который отвечал выбывший специалист, проблема проведения код-ревью, проблема подтягивания более слабых членов команды или проблема втягивания в работу новых сотрудников, проблема слабых коммуникационных связей между членами команды.
Разумеется, команды стараются привносить какие-либо практики, позволяющие решать или сокращать в той или ной степени все описанные проблемы. И одной из таких практик является парное программирование. Практика парного программирования очень проста по смыслу, но может иметь очень хороший выхлоп. Итак, смысл этой практики заключается в собственно парном программировании, то есть, когда создаётся мини-команда из двух человек, которая садится за один компьютер и занимается совместным написанием кода. Это не в том смысле, что они начинают драться за клавиатуру постоянно отнимая её друг у друга. Нет. Один сидит за машиной, а другой просто участвует в обсуждениях. Пара может совместно решать любые вопросы, которые возникают ежедневно: принимают какие-то решения по дизайну кода, его непосредственной реализации и так далее.
Плюсы
Давайте обсудим плюсы такой практики:
- Парное программирование позволяет расшаривать знания о конкретных участках кода на большее количество участников команды. Это позволяет достигать совместного владения кодом, а не раздельного как это чаще всего и бывает. А значит, когда один программист уволился или просто ушёл в отпуск и вдруг возникла необходимость внести изменения в те участки кода, за которые он был ответственен, особой проблемы не возникает, потому что найдётся как минимум ещё кто-то, кто имел отношение к написанию того участка кода и ему не придётся тратить 3 дня, чтобы вникнуть в смысл участка кода, подлежащего внесению изменений.
- В процессе написания кода, пара активно взаимодействует и то, что не видит один, видит другой. В результате код становится короче, а количество багов уменьшается.
- Отдельной техникой в рамках парного программирования, которая позволяет повысить качество кода, является пинг-понг программирование. Эта когда один человек накидывает юнит-тесты, а другой пишет код программы, который должен проходить эти тесты. Чаще всего пинг-понг программирование это именно про test-driven development, когда сначала пишутся тесты, а затем код программы, который должен проходить написанные тесты. Такое разделение позволяет увеличить количество покрываемых кейсов, а значит, зачастую и повысить надёжность кода.
Если кусок кода написан двумя программистами, то код-ревью можно считать завершённым. Т.е., код-ревью происходит автоматически. Ну, конечно, ситуация когда в паре код писали два джуниора – не в счёт. Однако, я и не припоминаю, чтобы кто-то паровал джуниоров, это скорее всего будет не очень эффективно.
Парное программирование позволяет подтянуть более слабых коллег, если паровать их с более сильными. В процессе парного программирования происходит очень активный обмен знаниями, а значит рост более слабого коллеги будет практически неизбежен. Ну, кстати, речь тут может идти не обязательно о подтягивании более слабого товарища. Обмен опытом может происходить и между коллегами, у которых просто разный опыт и было бы неплохо им друг с другом этим самым опытом обменяться.
- Грамотный и ненавязчивый подход к внедрению парного программирования в команде может привести к улучшению взаимоотношений в команде. Когда двое программистов целый день программируют вместе, при условии, что они совместимы, у них вполне закономерно улучшаются взаимоотношения. Это не может не сказываться положительно на микроклимате в команде.
Минусы
Однако, у парного программирования есть недостатки и есть проблемы на пути внедрения этой практики.
Итак, какие проблемы связаны с парным программированием?
Чтобы внедрить парное программирование, придётся доносить до руководства пользу этой техники, ибо когда начальник ходит и видит, что двое целый день парно сидят перед один компом, он обязательно возмутится и подумает, что тут что-то не так. Какого чёрта они тратят время? Могли бы сделать в два раза больше! Тут придётся уповать на здравомыслие начальства и пытаться донести все плюсы данной техники.
На самом деле, найти совместимых людей, которые бы целый день, ну или хотя бы пол-дня могли провести вместе, занимаясь программированием, не так-то просто. Честно говоря, мне кажется, это самое сложное. Парным программированием могут эффективно заниматься только те программисты, которые тонко чувствуют, что у их коллег есть своё чувство прекрасного и свой стиль программирования. Это позволит во время парного программирования не давить там, где не надо, не давать совет, там где не обязательно. То есть пара программистов должна действительно изначально быть настроена положительно по отношению друг к другу и допускать разницу в мелочах, не пережимать, где это не требуется. Если один из программистов считает, что верны только его подходы и до малейшей детали будет докапываться и спорить о том, что надо делать только так как он сказал – дело зайдёт в тупик, кроме того, отношения в результате такой сессии могут только ухудшиться. Поэтому парное программирование – дело весьма тонкое. Однако, правильно подобранные пары могут показывать невероятную эффективность, которую даже сами от себя по одиночке не ожидали. А вот кто должен заниматься подбором пар – это большой и жирный вопрос на который, увы, нет однозначного ответа. По идее, этим заниматься должен лид, ну, либо должно быть просто дано разрешение на такую практику, а люди внутри команды уже сами разберутся. Но это сильно зависит от команды.
Многие программисты, говорили мне, что парное программирование хоть и эффективно, но очень сильно выматывает. Однако, это очень индивидуально и конечно, так же, зависит от совместимости пары. Не особо совместимая пара, будет выматываться гораздо раньше. Однако, даже хорошо совместимая пара может чувствовать усталость после двух-трёх часов парного программирования. Действительно, из-за высокой интенсивности работы, и перманентного общения – происходит перегруз нервной системы. В таком случае, конечно, парное программирование надо ограничивать. Отменять полностью, конечно же, необязательно.
Отдельной проблемой является шум от парного программирования, ведь пара программистов вынуждена постоянно общаться голосом, тем самым, мешая окружающим. К сожалению, текстовое общение не выход – слишком долгим и неэффективным получается процесс. Серьёзность этой проблемы не в последнюю очередь зависит от того как устроен офис, ибо если программисты сидят как селёдка в бочке, то, конечно, это станет реальной проблемой. Однако, во многих офисах с большими пространствами, это не будет проблемой вовсе, при условии что пара программистов ведёт себя адекватно и разговаривает тихо, без эмоционального накала в стиле итальянцев.
Итог
Парное программирование – техника не бесплатная. Когда нужно резко мобилизовать все силы команды и пилить новый код, увы, может быть не до парного программирования. Однако, эта практика очень полезна, когда применяется с умом, без излишнего давления, она позволяет улучшить качество кода и отношения внутри команды. Сблизить людей. А также позволяет программистам совместно владеть кодом.