はじめに
この記事でお話しする変則型ペアプログラミングは自分のPJでペアプログラミングと呼称していましたが本来のペアプログラミングとは異なる点に
ご注意ください。
プログラミング一年目の新人のお話ですので、生暖かい目でご覧ください。
経緯
-
リバースエンジニアリングで作成したRAGのコードの知識が十分じゃない、フレームワークを用いて、将来性のあるシステムにしたい！というところからリファクタリングが開始
-
二人で開発を行うことになったもののフレームワークへの知識は
ゼロベースなため、最初の段階でのタスク分割が難しい
本来のペアプロと実際に行ったものの比較
| 本来のペアプロ | 変則型ペアプロ | |
|---|---|---|
| 役割 | ドライバとナビゲータ | ソロプロ×ソロプロ |
| 目的 | 生産性を向上させる | RAGの知識を増やしつつ開発 |
| 方法 | 1つの画面に二人でとり組む | 各画面で取り組むのがベース |
| 作業時間 | タスクが終わるまで通話、画面共有 | 作業時間を決めてそこで一緒に問題対処 |
このペアプログラミングは、スポット的なペアプログラミングを
さらに自分たちがやりやすいようにした形のものです。
このペアプログラミングのやり方の要素は2点です。
- 1つのタスクに対し、それぞれが考えたロジックで実装をしていくこと
- 共同に作業をする時間を設定し、進捗報告と問題対処を行うこと
メリット
- 本来のペアプロと同様に相互チェックができる
- コーディングはソロで,、一緒に作業をするタイミングで
問題対処に取り組むので窮屈な感じがない - 同じ機能を異なるアプローチで作成しているためどちらかが上手くいかなかったときのリスクヘッジになる
- アプローチ方法の違いがおもしろい
- やっていることが分かるようにコメントを残そうとするのでロジックの整理ができる
- 認識の違いに早く気づくことができる
デメリット
- それぞれ同時に問題が生じたときに、1つ1つ解決するため
作業の時間がまるまるエラー対処に使われることがある - 出来上がったもの2つに対し、プロジェクトで使われる成果物は良いほうまたは組み合わせた1つになる
- 生産性(速度)の向上には効果が薄い
- 今回経験豊富なトレーナーがサポートに入ってくれたが、第三者に助けを求めた場合、二つのコードを見る必要があるためサポートする人などの負担が増加する
所感
- この変則型ペアプロは新しいものを学びながら作成するゼロベースの開発では理解を深めやすく良いものだと思う
- 一方で成果物を早くあげなくちゃいけない場合や、新人同士の場合は、
そもそものコードのエラーへの慣れが不足していることが多く、
サポートに入れる人がいない場合は難しいと感じる - ある程度経験を積んだ人の場合だと、モチベーションの低下は防ぎたいけど
ペアプロ導入してみたい、コードレビューが長くなるから減らしたい
といった場合にはこのような形で部分的に導入してみるのもいいのかもしれない - 教育や研修をする際に、この変則型ペアプロをさせてみてどんな成果が上がるか見てみたら楽しそう
まとめ
今回の変則型ペアプロは
本来のペアプロの良さである、相互の確認で認識の相違の防止やコードのミスに対処を早急に対処できる点、キャッチアップのロスが少なくなる点はそのままに、
モチベーションの低下を防いだり、広い知識を得たり、上手くいかなかった場合に作り直しをせずに済むというメリットがある方法だったように感じます。
皆様も自分たちがやりやすいように手法をカスタマイズしてより良いプログラミングライフをお過ごしください。