Парное программирование

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

Я слышал, что ревью кода работает примерно так же, но если честно, я в этом не уверен. 

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

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

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

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

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

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

Но даже если представить, что программист одиночка работает 50% рабочего дня, работая в паре у такого специалиста эффективность будет выше. Как говорится: «Одна голова хорошо, а две лучше». Код так же получается лучше и багов меньше. 

Когда я работал над проектами Sony, то у нас было правило – все изменения напрямую на серверах должны происходить в паре. Это не совсем парное программирование, ведь весь день мы работали по одному и только в те моменты, когда нужно было изменять что-то на серверах это делалось в паре. 

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

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

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

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

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

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

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

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

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

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

---

Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание