はじめに
様々なプロジェクトでコードを書いていると可読性が高くメンテナンスもしやすいコードも
あればたまに見た瞬間にふざけんないけていない、いわゆるスパゲティコードもありますよね。
そんなふざけたスパゲティコードのせいでバグの調査や動作確認に時間がかかってしまうことも
あるのが嫌なのでリファクタリングをすることに決めました。
決めましたけど自分はプロジェクト上PGでないし、あまり1人でやるのもチームとして
健全でないため、実験育成も含めてペアプロをしてみました。
※スパゲティコードがわからない人はググってみよう。
環境
- 開発言語：Go言語
- IDE：VSCode
- 共有ツール：LiveShare
- コミュニケーションツール：GoogleMeet
そもそもペアプロとは
ドライバーとナビゲータの2人で一つの成果を作り上げていく開発手法。
- ドライバー
- 手を動かす人
- 成果物の責任を持つ人
- ナビゲータ
- ドライバーに作業指示をする人
- 成果物の大局を決める人
- 成果物の責任を持つ人
細かくは以下の参考元を見てください。
参考元
- ペアプロについて話されているpodcast
- ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
- ペアプログラミングして気がついた新人プログラマの成長を加速する３つの習慣
- ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話
やりたかったこと
- バグがよく発生する関数があるけど一つの関数で意味を持ちすぎなので適切に関数を分割したい。
- それをプルリクベースでやり取りすると時間がかかるし、検討意図とかも共有していきたい。（途中経過の共有）
- プロジェクトの暗黙知の共有
- 自分が普段考えていることの共有（知見共有）
裏でやりたかったこと
- ペアプロの良さの普及
- 強いチームを作るためのチームビルディングの一環
- 属人化の防止
- 色々な知見の吸収
- 弱点の補完
- 得意分野の強化
やってみた結果
ドライバーの人が初めてペアプロしたということもあり、ペアプロの良さやメリットを
伝えることができたので良かったです。
- よかった点
- 意思疎通しながらできるのでよかった
- ベテランの考えを聞きながらできるのはよかった
- レビューされながらコードを書くので時間短縮には繋がる
- 悪い点
- 環境の準備がしっかりできていなかった
- リファクタじゃなくて作り込みとか単純なコードは向かなさそう
最後に
今回はプロジェクトの合間を見つけての１回目の変化でしたが、
ペアプロでやりたかったことは少しはできました。
ただ、１回だけでなく継続的にやっていってこそ裏でやりたかった強いチームビルドに
繋がっていきます。
「属人化の防止」、「弱点の補完・得意分野の強化」はパートナーを組み換えて
ペアプロを実践することで効果を発揮し、チーム全体の底上げになりますので
やらず嫌いではなくやってみて損はないです。
正直最初失敗することもあるでしょうけど、失敗したら失敗したでしっかりと振り返りをしたら
得られるものは多いので気楽に挑戦って大事です。