こんにちは！アニメとゲームが大好きな@mayoxtunaです。
2018年3月26日に入社しました。
まだ2週間ほどしか経っていませんが非常に密度が高い時間を過ごしています。
CrowdWorksのエンジニア達は積極的に社内勉強会を開催しています。
社内勉強会では主に
- 社外で得た知見などをまとめ、自ら社内勉強会を開催しそれを共有
- 気になっている技術や最新の技術などの共有
- 読書会
などを行っております。
今回は社内の@yosuさんがTDD+モブプログラミングでワイワイする会 その5 - connpassに参加し 非常に内容が良かったという事で社内へ展開してくれました。
そもそもTDDとは？
テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。
エンジニアにとって理想のコード
エンジニア目指すコードはキレイなコードで動作するに尽きると思います。
上記のコードに到達するためには２種類のルートがあると考えられます。
- しっかりプランニングをしてから、実装を開始する
- 汚くてもいいから実装から入り、コードを洗練していく
この２種類のルートについてデメリットを深掘りしてみましょう
「しっかりプランニングをしてから、実装を開始する」で考えられること
- コードを書き始めてから、設計のミスに気づく可能性がある
- 設計からやり直し->スケジュールどうするの？
- 設計に力を入れすぎたあまり、開発が疎かになってしまう
- 設計はキレイだとしても、動かないという結果になる可能性が出てくる
「汚くてもいいから実装から入り、コードを洗練していく」で考えられること
- 動くけど汚いコードができる
- 可読性が悪すぎる
- 絡み合って改修が容易じゃない
- 保守性が悪くなる
- プログラムが大きい場合、作った本人以外理解できない
- 理解までのコストがかかる
TDDの開発サイクル
TDDでは以下のような開発サイクルになります
- 現時点で分かっている範囲で、テストする必要がある項目を列挙
- リストから1つ選択
- 実装できそうでかつ重要なものを選ぶ
- 選択した項目について、テストを作成
- このテストは、現在の実装を用いると失敗するように記述
- コンパイルに必要な最小限のコードを追加した後、実際にテストを実行し失敗することを確認する
- できる限り早く、テストに通るようにコード本体を記述
- テストが通ることを確保しつつ、コードそれ自体やコードとテストの間にある明示的・暗黙的な重複を取り除く
TDDのメリット
TDDの開発サイクルを回すことによるメリットは以下のとおりです
- コードがテストに通ることにより、手戻りが発生しないことを確認できる
- 考え込むよりコードを書くことで具体化していきながら、開発を進めることができる
- 欠陥やバグは非常に少ないことが期待される
そもそもモブプログラミングとは？
モブプログラミングは、チーム全体が同じ場所で、同時に、同じ場所で、同じコンピュータで動作するソフトウェア開発アプローチです。
準備
- モニターorプロジェクタ
- PC1台
- 3~6人のチーム
- ホワイトボード(ノートでも可)
進め方
- 作るものを決めます
- 時間を決めます
- 最初のドライバーを決め実装していきます
- 定期的にドライバーを交代させます
- 完成したら(or 時間が来たら)振り返りをします
社内でTDD+モブプログラミングをやってみた
今回はフォーマンセルでFizzBuzzPlusをテーマに実装していきました
モブプログラミングのルールはそのまま使っています。
使用したwebサイト
こちらには様々な言語の実行環境と課題が用意されています。
メリットとしてテスト環境を用意することなく、ブラウザ上でテストコードを実装して挙動を確認できるのでオススメです！
今回はこちらを使いTDD+モブプロでFizzBuzzPlusを実装していきました
進め方
まず、1つのテストコードを書き、テストが失敗する状態を作ります。
以降、次の開発サイクルを回し続けて完成を目指します。
- テストが成功するように本体を改修する
- テストを成功させる
- テストが失敗しないようにリファクタリングする
- 新たに1つテストコードを書いてテストを失敗させる
- ドライバーを交代する
感じたこと
最初の時点から動くことは保証されているので 始まりは確実に動く汚いコードから 洗練された動くキレイなコードになっていく一連の流れが分かります。
ドライバー以外のモブ達は意見などを言ったりできるので レビューの工程が必要なくなります。
また、みんなで意見を言い合わせながら実装をしていくので、コードに統一性を持たせることができ非常に良いと感じました。
今回はチームが２つに分かれていたのですが、
- FizzBuzzをまず完成させてからFizzBuzzPlusにするチーム
- FizzBuzzPlusを最初から考えて実装を進めるチーム
と行動パターンも異なり、非常に面白い結果になったと感じました。
まとめると...
- TDDの開発サイクルを回すことで動くコードを担保することができる
- 小さく作っていきその中でリファクタするのでコードが洗練されていく様子が分かる
- レビュー時間の削減ができる
- コードに統一性をもたせることができる
- とりあえずワイワイしながらコーディングするの楽しい!!
テストクリアする度にみんなで「やったー！」と言いながら開発できるのって楽しいですね。
今回のキッカケになった勉強会が4/14と4/22に開催予定なので、ぜひご参加ください！
クラウドソーシングのクラウドワークスでは、TDDやモブプロなどに興味があり成長し続けたいエンジニアを募集しています！
