TDD+モブプログラミングでワイワイする会に参加してきました！
お久しぶりの晃一です！
最近はブロックチェーン周りのお勉強だったり、Scalaのお勉強だったり新しいことに挑戦していて、なかなか刺激的な毎日を送っています！
さて、本日は、たまたま時間が空いたので、久々にプログラムのワークショップに参加してきました！
参加したのはこちらのワークショップです。
オーガナイザーの方いわく、とりあえずやってみた会！ダメだったら次回から無し！ということですが、
体感としてはかなり好評でした。
自己紹介〜チーム分け〜お題決め
まずは自己紹介して、チーム分け。
今回はメンバーとして8人が参加しました。
みなさん、プログラミング言語やキーボードの種類がバラバラだったりで、なかなかここを決めるのが難しかったですね笑
最終的にグッパーで決めて、4：4の2チームで決定しました。
私が参加したチームは、PythonでFizzBuzz。
チーム内に誰もPython実務経験者がいないということで、解が明快なFizzBuzzにしようという流れ。
もう一方のチームは、Javaで100Doorという問題でした。
こちらは後述します。
開発環境
開発環境としてcyber-dojoというものを使いました。
いわゆるWebIDE的な感じなのですが、様々な開発言語が選べて、テストフレームワークもついでに選べるという優れもの。
さらに課題がいくつも設定されており、初心者向けにアルゴリズムの教育ツールとして使うととても良さそうだなと感じました。
実装開始！
TDDで開発を行うため、まずはFizzBuzzの問題をテスト単位に分解。
ちょっと暗くてわかりにくいかもですが、いわゆるFizzBuzzの3の倍数、5の倍数、15の倍数の確認のテストと、
1〜100までの数字を出力する、というお題だったため、その問題を分解しています。
出力に関しては、進めていく中で決めていったのですが、printCountやcalcCountなどの変数を定義して、
何回呼ばれたか、という尺度でテストを行う方針にしました。
出力って今までテストしたことなかったので、こんな感じでテストできるんだなと感心してました。
こういったアイデアが出てくるのがバグプログラムのいいところかもしれませんね。
ここからテストと実装を書いていきます。
TDDでのお約束として、次の流れで開発を進めていきます。
- 失敗するテストを書く
- テストが通る実装を書く
- リファクタする
なお、テスト内にはforやifなどの制御構文が出てこないようにし、なるべくAPI一つを呼ぶ形で実装していきます。
これはAPI単位でテストを行うことにより、APIが結果を保証することを確実に証明するためです。
今回はモブプログラミングなので、このTDDの流れを複数人で行いことになります。
今回は、ピンポン形式ということで、1人が上記の開発の流れの1.を書いた段階で交代することにしました。
こうすることで、テスト実装者と実態の実装者が別々になるため、テストと機能の妥当性が上がるということらしいです。
もう一方のチームでは、10分単位で実装者が交代していました。
実装結果！
みんなでワイワイガヤガヤやりながら、Pythonの文法を調べながら、FizzBuzzを完成させたのがこちらになります。
見えないですね！笑
こちらはテストの画面になっていて、雰囲気を感じてもらえればいいのですが、凄くシンプルにまとまっています。
確かにこうやってTDDで開発を行うと、実装に無駄な処理も入るが、テストがしっかりと実行結果を保証してくれるので、漏れなく実装が行われるのはなかなかいいなと思いました。
別チームのプログラミングを見てみる
モブプログラミングの大きな特徴として、人が複数モブを行ったり来たりしながら実装が行われるということです。
実装者は1人なのですが、外野でワイワイ言う人が行ったり来たりしながら、必要なアドバイスを行うことができるということですね。
こんな感じで後ろから観戦しながらワイワイガヤガヤしながら実装を進めてました。
次のお題！
次のお題は100Door問題。
こちらは閉じた状態の100個のドアがあり、一度ドアを訪れると開き、もう一度訪れると閉じるという仕様。
そして、2の倍数のドアを訪れ、次に3の倍数のドアを訪れ、4の倍数のドアを訪れ・・・100の倍数のドアを訪れる、としていったときに、100個のドアは最終的にどんな状態になっている？という問題です。
これが方針決めるときに決めたことです。
今回は最後までできなかったのですが、配列アクセスが[0-99]なのに、ドアは[1-100]というところなど、なかなか面白い問題だったなと思いました。
まとめ
今回、初めてまともにTDDを書いたのですが、これを実務でやるのは骨が折れるなぁと感じました。
今回FizzBuzzの実装にかかった時間も2時間30分程度かかっており、これを実務でやると、実装期間がかなり伸びそうだなと感じました。
ただ、実務レベルに落とすときはもっとテストを大きくしても問題ないということで、適切な粒度にテストを落とし込むことも大事なようです。
また、モブプログラミングに関してですが、これは本当に面白い試みだと思いました。
プログラミングスキルに関しては当然なのですが、開発スタイルや仕様、組織としての風通しの良さの作り方など、いろいろなところにいい影響が出てくるのではないかなと思いました。
今回聞いた話で、面接に来た人をモブプログラミングして、採用を決めると言う話があり、なるほど！と思いました。
何かしらのお題を決めてモブプログラミングを行うことで、採用担当者は相手の技術レベルを知ることができるし、逆に面接者も現場での開発スタイルや様式について知ることができるため、これはお互いにとっていい結果になることが多いのではないかと思いました。
久々に参加したワークショップでしたが、初体験のことが多く、今後も開催されることがあれば又参加したいなと思った次第です。
最近はマクロな内容を取り扱うことが多かったので、TDDについてももう少し勉強してみようと思います。
その前にScalaをマスターしなければですが笑