TDDとモブプロしてきた

概要

  • モブプログラミング(以下、モブプロ)とTDDの2つを勉強会にてやってみたので、その所感などを記載します。

モブプログラミングって?

  • ドライバーとナビゲータで役割を分け、一つの画面で一緒にプログラミングを行うこと。
    • ドライバー:コーディングを行う人
    • ナビゲータ: 実装を手助けする人

TDDって?

  • テスト駆動開発(Test Driven Development)の略
  • 実装の前にテストコードを書き、テストに適するかたちで実装を行うことを指す。

勉強会で両方やってみた

どんな勉強会?

  • モブプロでTDDしようという勉強会でした。

  • TDDは、レッド(テストで失敗させる)
    → グリーン(テストを成功させる)
    →リファクタリング(コードをきれいにする)
    の流れで開発のサイクルをまわします。

上図のように、

  1. まず失敗するテストをコーディングする
  2. とにもかくにもテストを通す(成功させる)
  3. 実装をきれいにする

のサイクルをまわして要件を一つずつ実装していきます。

  • その際にサイクルの一つでも成功するたびにしっかりと褒めあって称え合って雰囲気を盛り上げながらTDDをしていきました。

  • サイクルの一つを完了するたびにドライバーとナビゲータを交代して、全員がどちらの役割も経験しました。

  • 言語はRUSTで参加者の全員が1ミリも触れたことのない言語でTDDを行いました。だからこそ型の定義の違いなどについてみんなで調べて最適解をはやく見つけようとしていきました。

やってみた感想

モブプロの感想

  • モブプロは盛り上げるの超大事。個々人の積極的な意見を出すためにも、場の雰囲気を良くすることが必要。

  • モブプロは変数名一つについてもナビゲータたちと議論をして最適解を導き出すので、開発後の保守や運用においても対応が遅れるなどの問題が発生しにくいのではと思った。
    例)仕様を一人のエンジニアしか理解しておらず、機能を追加する際に考慮漏れが発生するなど。

  • 人によってコーディングの方針(どの関数を選ぶかなど)が異なるため、議論を重ねることで独りよがりのコーディングになりにくくなる。

TDDの感想

  • コーディングする前に、なにを実装するのかについてTODOをリストアップすることが非常に大事。それが要件定義になる。

    • 今回はFizzBuzzでTDDを行いましたが、「①1の入れたとき、数字の1を返す。②3を入れたとき、Fizzを返す。」のように、自分たちが何を実装するのかをまず日本語で並べることで先の実装を含めイメージをすることができた。
  • RustでTDDを行ったが、自分の知らない言語を知る際の障壁が下がる。(TDDの良いところですね)

    • 知らない言語について勉強をする際にはTDDでとりあえず書いてみるというのはありだと思いました。
  • 今後追加で実装するにあたって、テストを通すだけで既存の実装に影響が出ていないかをチェックできるのは強い。

参考資料

テスト駆動開発