プログラミング未経験者とリモートペアプログラミングをしてみた
ペアプログラミングについて
ペアプログラミング - Wikipedia から一部抜粋します。
ペアプログラミング
ペアプログラミング（英: pair programming）は、2人のプログラマが1台のワークステーションを使って共同でソフトウェア開発を行う手法である。一方が単体テストを打ち込んでいるときに、もう一方がそのテストを通るクラスについて考えるといったように、相補的な作業をする。 実際にキーボードを操作してコードを書く人を「ドライバ」、もう1人を「ナビゲータ」と呼ぶ。30分ごとか、単体テストを1つ完成させる度に役割を交替するのがよいとされる。また、1日に一度の頻度でパートナーを変えるのがよいともされている。
批判
- 経験を積んだ開発者によっては、初心者とのペアプログラミングを退屈な指導と捉える場合もある。
- 経験を積んだ技術者は、非常に正確なコードを書く。その場合、ペアを組んだとしても、もう一人が何か寄与することは難しい。
- ペアプログラミングの目的は、正確性の向上だけでなく、知識や技術の共有という面もある。
派生
リモートペアプログラミング
テレワークなど、何らかの理由で遠隔地で作業する場合は、文字を入力する度に相手側のコンピュータに変更がリアルタイムで反映されるエディタや統合開発環境のプラグインを使用したり、画面転送のためのソフトウェアを使用したりして行われる。
今回は私が経験したリモートペアプログラミングを備忘録としてまとめます。
この記事の対象者は主に下記の人を想定しています。
- ペアプログラミングをやってみようかなと考えている方
- プログラミングを誰かに教える・教わる可能性がある方
- プログラミング初心者とのコミュニケーションが苦手な方
- プログラミングに興味はあるが、実際にはやれていない方
ドライバとナビゲータについて
ドライバ (筆者の先輩)
- プログラミング未経験
- AWS の知識は豊富
- スキルアップのためにプログラミング本を Kindle で漁る
- プログラムを見た時の口癖は「難しそう・プログラムを読み書きできる人はすごい」
ナビゲータ (筆者)
- プログラミング歴は 5 年ほど
- iOS (Objective-C) と Android (Java) がメイン、その他は流行を追う程度に調査済み
- 目的にあったプログラミング言語を選択するのであれば、どんな言語でも選り好みをしない性質
- 教わる・教えるのが好き
- GitHub が好き
私も先輩も勤務形態がリモートワークであったため、必然的にリモートペアプログラミングとなりました。
リモートペアプログラミングを実施するまで
リモートペアプログラミングを始めた事の発端を書きます。
先輩が AWS Lambda のやや複雑なコードを書くために、Python を学習していました。私は先輩に「先輩がもしプログラミングをやる機会があれば、困った時はいつでも相談に乗りますよ。」と伝えていました。先輩は私に作成したコードをチャットで送り、定期的に相談してきました。
先輩は書籍やブログを参考にコーディングをしていたようですが、写経したコードに対する理解がほとんど出来ていませんでした。私は Python の経験はありませんでしたが、コードの意図はほとんど理解することができました。
レビューをしている時は自分にも Python のスキルが身につけば一石二鳥なのでは、と考えて Python の公式リファレンスに則って指摘するようにしました。私が Python を書かないとしても今後先輩が一人で書けるようになったら、その時は私が教えてもらおうと目論んでいました。
チャットだけでもある程度は教えることが出来たのですが、色々と難航していました。そこで、私からリモートペアプログラミングを行ってみようと提案しました。
リモートペアプログラミングの第一印象
至極当然ですが、リモートペアプログラミングはチャットでレビューを行うよりも効率が良いです。先輩はペアプログラミング自体を知らなかったので、目から鱗が落ちるといった様子でした。
ただ、時間を決めてやらないとダラダラと長引くのではないかと感じました。リモートペアプログラミングの開始と終了時に、当日のゴールと次回までの目標 (宿題) を伝えるようにしました。
リモートペアプログラミングでドライバへ伝えたこと
ドライバの経験量にもよりますが、私が確認した問題と伝えたことを書きます。
所謂、プログラミング初心者あるあるネタです。
- 1行ごとにコメントを書く
- コードの命名規則に一貫性があれば流れが想像できる
- クラスが理解できない
- 基本は設計図 (クラス定義)・実体 (インスタンス)・振る舞い (メソッド) の3点
- 原則として クラス定義 → インスタンス → メソッド の順に呼び出すことを守る
- オブジェクト指向がわからない
- 一人で開発しているとわかりづらい
- 必要性に駆られるまで理解できるものではない
- フレームワークを使う頃には必ず理解できる (はず)
- 何から書けばいいのかわからない
- いきなりコードを書き始めるのはそれなりにハイリスクであることを認識する
- 先に定義だけを行い TODO をメモしておく
- 必要なライブラリや利用する公開 API は予めドキュメントを調べる
- ドキュメントにはサンプルが記載されていることが多い
- ドキュメントから利用する関数を抜き出す
- 何を参考にすればいいのかわからない
- 公式のドキュメントは最も新しく信憑性の高い情報 (であるはず)
- 何が出来るのかわからない
- まずは構文を知る
- LL 言語でも常に型を意識する
- インスタンスに対してどんな操作が行えるかはそのクラスの定義を知るということを認識する
- 出来ることよりも出来ないことの方が言語の知識が深くなるまではわからない
- 実際に動かしてみるまではわからない
- Linter を導入すればヒントが貰える
- ユニットテストで検証が可能
- 動いたコードをどのように確認するのかわからない
- 大抵のことはログが教えてくれる、ログを見なければ誰もわからない
- 完成形が見えない
- 困った時はユースケースの確認や Issue の作成から始める
- 懸念点は判明次第洗い出す、常にアップデートして放置しない
リモートペアプログラミング時にナビゲータが気をつけたこと
私は特に下記を意識しました。
- ハイコンテクストな (共通認識がない) 言葉で理解を妨げないようにする
- ドライバが考えている最中は極力遮らない
- ドライバが良くない実装をすること (アンチパターン) を止めない
- 一区切り実装が終わったら、書いたコードをドライバの言葉で説明してもらう
- ドライバは局所的なコードよりも、コード全体の流れを意識してもらう
- ナビゲータが考えた答えは必ずしもドライバの最適解ではない (理解の範疇を超えることでの生産性の低下)
先輩は初めからメンテナンスがしやすいコード・綺麗なコードが書きたいと言っていたので、私は先輩がどんなコードを書いてもあえて指摘しませんでした。それは問題に差し掛かって、初めてしっかりとした理解が出来ると考えていたからです。
※ 基礎的なシンタックスエラーは解決まで長引きそうであれば手助けをしました。
※ ドライバは後々、クラスの必要性やコードの見通しの良さ、命名規則の重要さ等を考えられるようになりました。
今後の課題とドライバに期待していること
継続したペアプログラミングでは、ある程度ドライバの理解が深まると効果は顕著ではなくなると考えています。そのため、GitHub の Issue / Pull Requests でお互いの隙間時間にレビューが行えるようになることを期待しています。
またドライバのノウハウが十分に蓄積したら、ナビゲータへ還元される可能性も大いに考えられます。その時は私が Pull Requests を出してレビューをしてもらおうかと考えています。
数回続けてみた結果と感想
リモートペアプログラミング開始以前と比較すると、飛躍的に向上した点は多々あります。
ただ、ペアプログラミングだからできたというよりは、ペアプログラミングで意識が変わったという方が正しいと感じています。最も大きな収穫は先輩が楽しんでプログラミングをできるようになったことでした。少しずつでも理解ができるようになった時はやはり楽しいようです。
私よりも教えることに長けた知り合い (本人曰くマブダチ) が、プログラムを人に教える時に気をつけていることとして、こう言っていました。
@pakorepqu やってる人が楽しそうにしてることが大事かなと思う。モチベーションが最も貴重なリソース。
— 都元ダイスケ? (@daisuke_m) 2017年5月7日
どうやら貴重なリソースが得られたようです。
私の場合は教えながらも自身に新しいスキルが身につくので、ありがたい限りです。理解することが楽しいと思えることを仕事にできるエンジニアは、確かに魅力的な職業かもしれません。
先輩が私に Python のお作法から教えてくれる日も近いことでしょう。
