187 Views
March 22, 25
スライド概要
テスト駆動開発 (TDD) とモブプログラミングを体験するハンズオンセミナーの資料です
TDD&モブプログラミング ハンズオン やっとむ こと 安井力 合同会社やっとむ屋 Copyright © 2022 やっとむ、合同会社やっとむ屋 1
今日の内容 プログラミングの技術である テスト駆動開発 (Test-Driven Development) チーム作業の手法である モブプログラミング 講義と実践を通じて、持ち帰る プラス、参加者同士で教え合い学び合う 学ぶ姿勢を学ぶ 2
[email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ より詳しくはこちら https://gist.github.com/yattom/b8b0cf059eac389822949d0e5be5c2a8 3
タイムテーブル • • • • • • • • • • • 11:00- 内容説明 12:00 (お昼休み) 12:45- 説明 つづき 13:05- TDD&モブプロ体験 14:15- 中間ふりかえり 14:30- TDD&モブプロつづき 15:30 (休憩10分) 15:40- ふりかえり&共有 16:10- TDDとモブプロのおさらい 16:35- 質疑応答 17:00 終了 4
テスト駆動開発 Test-Driven Development (TDD) 5
TDDという開発手法 • テスト駆動開発=「開発」手法 • • テストを書きながらコードを書く • • • テスト手法ではない テスト=テストコード (自動化したテスト) コード=プロダクトコード テストとコードを一緒に、同時に、並行して • 「テストが先」ではない 6
TDDのワークフロー 1. 網羅したいテストシナリオのリスト(テストリスト)を書く 2. テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可 能なテストコードに翻訳し、テストが失敗することを確認する (RED) 3. プロダクトコードを変更し、いま書いたテスト(と、それまでに書いたすべ てのテスト)を成功させる(その過程で気づいたことはテストリストに追加 する) (GREEN) 4. 必要に応じてリファクタリングを行い、実装の設計を改善する (REFACTOR) 5. テストリストが空になるまでステップ2に戻って繰り返す https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck
TDDのゴール 動作するきれいなコード Clean code that works https://www.amazon.co.jp/dp/4274217884/ 動作するコード = 人の役に立つ = ユーザー価値がある きれいなコード = 読みやすく直しやすい = 仕事が早く安全
例題: FizzBuzz問題 1から100までの数をプリントするプログラムを書け。ただし3の倍数の 場合は数の代わりにFizzを、5の倍数の場合は数の代わりにBuzzを、 3と5の倍数の場合はFizzBuzzをプリントせよ。 9
やってみよう 1. 2. 3. 4. 5. 網羅したいテストシナリオのリスト(テストリスト)を書く テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可 能なテストコードに翻訳し、テストが失敗することを確認する プロダクトコードを変更し、いま書いたテスト(と、それまでに書いたすべ てのテスト)を成功させる(その過程で気づいたことはテストリストに追加 する) 必要に応じてリファクタリングを行い、実装の設計を改善する テストリストが空になるまでステップ2に戻って繰り返す 10
頭に何が浮かびましたか? • • • • 1から100までループ 3で割って余りゼロならFizz 5で割って余りゼロならBuzz …… • • • • • • 1, 2, Fizz, 4, Buzz, Fizz, 7, … 3,6,9,27,30,99はFizz あ、30はFizzBuzzか 5,10,20,25,35はBuzz 最後は98,Fizz,Buzzで終わり …… ロジック 実例 ↓ ↓ プロダクトコード テストコード 11
やってみよう 1. 2. 3. 4. 5. 網羅したいテストシナリオのリスト(テストリスト)を書く テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可 能なテストコードに翻訳し、テストが失敗することを確認する プロダクトコードを変更し、いま書いたテスト(と、それまでに書いたすべ てのテスト)を成功させる(その過程で気づいたことはテストリストに追加 する) 必要に応じてリファクタリングを行い、実装の設計を改善する テストリストが空になるまでステップ2に戻って繰り返す 12
テストを書くのは設計 (の一部) 実例 + インターフェース設計、 クラス設計 可読性 再利用性 安全性 = テストコード 利用側コードで 確認 13
やってみよう 1. 2. 3. 4. 5. 網羅したいテストシナリオのリスト(テストリスト)を書く テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可 能なテストコードに翻訳し、テストが失敗することを確認する プロダクトコードを変更し、いま書いたテスト(と、それまでに書いたすべ てのテスト)を成功させる(その過程で気づいたことはテストリストに追加 する) 必要に応じてリファクタリングを行い、実装の設計を改善する テストリストが空になるまでステップ2に戻って繰り返す 14
すべてを短いサイクルで進める 実例 = + テストコード 設計 + + ロジック プロダクトコード 15
やってみよう 1. 2. 3. 4. 5. 網羅したいテストシナリオのリスト(テストリスト)を書く テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可 能なテストコードに翻訳し、テストが失敗することを確認する プロダクトコードを変更し、いま書いたテスト(と、それまでに書いたすべ てのテスト)を成功させる(その過程で気づいたことはテストリストに追加 する) 必要に応じてリファクタリングを行い、実装の設計を改善する テストリストが空になるまでステップ2に戻って繰り返す 16
クリーン リファクタリングで常時きれいを保つ リファクタリングで きれい テストコード 設計 プロダクトコード 17
やってみよう 1. 2. 3. 4. 5. 網羅したいテストシナリオのリスト(テストリスト)を書く テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可 能なテストコードに翻訳し、テストが失敗することを確認する プロダクトコードを変更し、いま書いたテスト(と、それまでに書いたすべ てのテスト)を成功させる(その過程で気づいたことはテストリストに追加 する) 必要に応じてリファクタリングを行い、実装の設計を改善する テストリストが空になるまでステップ2に戻って繰り返す 18
小さく繰り返す ゴール テ ス テストコード ト テストコード リ テストコード ス テストコード ト テストコード テストコード リファクタリングで きれい リファクタリングで きれい リファクタリングで きれい リファクタリングで きれい リファクタリングで リファクタリングで きれい きれい 設計 設計 設計 設計 設計 設計 プロダクトコード プロダクトコード プロダクトコード プロダクトコード プロダクトコード プロダクトコード 19
変更を担保するためのテスト 命綱、安全ネット 「コードを変えて祈る」から「テストで保護し安心して変える」へ 不安 安心 20
TDDのポイント • • • テストリストを作る レッド、グリーン、リファクタリング 歩幅を調節する • • 仮実装、三角測量、本実装、明白な実装 最初から完璧にしない、書けた範囲は完璧にする • • 常にリファクタリング テストもリファクタリング 21
モブプログラミング Software Teaming 22
リーダー&マネージャーのための チームの生産性をあげる モブプログラミング入門 やっとむ 23
モブプログラミングって? みんなの英知を集めて取り組むこと 同じものに対して… 同じ時間… 同じ場所で… 同じコンピュータで… Just like real mob. https://www.slideshare.net/andrefaria/mob-programming 最初に広めたおじさん 24
え、つまりどういうこと? • みんなで一緒にひとつのことをする 25
え、つまりどういうこと? ● ● ● ● ● ● 開発手法、あるいは仕事のスタイル みんなで一緒に、ひとつのことをする 全員が手を動かす 全員が意見やアイデアを出す プログラミングだけでなく仕事全体を進める 一日中、毎日続ける(こともできる) 26
実際に見てみましょう (3分15秒) https://youtu.be/p_pvslS4gEI 27
モブプロの様子 ● ● ● ● ● ● ● ● ● ● ● 全員が1台のコンピュータで仕事する ドライバーは1人、残りは全員ナビゲーター ドライバーは頻繁に交代(15分ごと) ミーティングしなくても全員認識がそろっている プロダクトオーナーも参加する 必要な知識、スキルがすべて集まっている 必要な人を呼んでくる 出入りは自由、一時的に離れてもかまわない 手分けして検索したりもする 集中できる 楽しい 28
モブプロの正しいやり方 “私が任じられた権限によって、 世界中のすべての人をMPE(モブプロ グラミングイネーブルド)と 認定します。 ルールはありません、というのが唯一 のルールです。私はうちで使っている ガイドラインを共有しますが、あなた はあなた自身の ガイドラインを見つける方が うまくいきます。” https://twitter.com/woodyzuill/status/1117493450734276611 29
ドライバーとナビゲーター ドライバー • 入力する人 (キーボードを持っている) ナビゲーター • それ以外の全員 ナビゲーターは相談して、やることをドライバーへお願い ドライバーはやることを理解して入力、実装、実現 ※ドライバーは賢い人間の仲間なので、伝わるようにお願いする 30
モブプロのやり方 例 ● ● 4人チーム 専用のスペースを作って、基本ずっとそこでモブ ○ ● ● ● ● 個人作業したくなったら、遠慮せずそうする ビジネスの人も呼んできて一緒にモブ 仕様も、デザインも、実装も、テストも、デプロイも 客先の打ち合わせは全員で行く 気が進まない作業もモブ(個人評価記入とか) 31
モブプロのやり方 例 その2 ● ● ● ● ● 8人チーム、普段は分散して開発 Zoom、Googleお絵かき、Slack 普段はだいたいリモートペアプロ 毎月1回合宿で、オンサイトで集まる 大きな機能の方針や基本設計を、ディスカッションと モブプロで固める ○ オンラインでモブをすることも 32
モブプロのやり方 例 その3 ● ● ● ● ● ● ● 15人開発者でフルリモート(COVID-19) 4つのチームを編成して、チーム内でモブ作業 ZoomやGoogle Meet、Slack、Googleお絵かき、VSCode+Live Share、開発サーバー(Linux)にssh+tmux 4チーム合同で朝と夜にSync(同期)ミーティング、 週1回プランニング、その他必要に応じてミーティング モブが大半だが、仕事の内容によってソロでやるときも コードレビューはチーム横断で リリースはチームでモブ作業、担当チームはローテーション 33
モブプロのメリット ● ● ● ● ● チーム全体の力を出し切れる ミーティングがいらなくなる 常に学びと成長がある 集中できる 楽しい 34
モブプロは全力を出せる ● 必要な知識、スキルがすべて集まっている ● 最高レベルの結果が出る ● 常に議論し、相談でき、助け合える 35
モブプロは強い 実 装 仕様 実装 実装 品質 実 装 仕 様 仕様 仕 様 品 質 品 質 36
モブプロはミーティングを減らす ● 情報共有は常にできてる ● 作業分担は不要、レビューやマージも不要 ● 仕様、設計、コードを全員が把握している 37
モブプロには常に学びと成長がある ● お互いから学ぶ ● 新しいことに全員一緒に取り組む ● 実験と失敗を生かせる 38
モブプロは集中できる ● 割り込みが来ない ● すぐその場で相談できる ● 疲れて休むときは抜けて休む 39
モブプロのメリット ● ● ● ● ● か る あ が ト ッ メリ が ム ー チ る す 断 判 チーム全体の力を出し切れる ミーティングがいらなくなる 常に学びと成長がある 集中できる 楽しい 40
モブプロは楽しい! やってみよう! 41
ドライバーとナビゲーター ドライバー • 入力する人 (キーボードを持っている) ナビゲーター • それ以外の全員 ナビゲーターは相談して、やることをドライバーへお願い ドライバーはやることを理解して入力、実装、実現 ※ドライバーは賢い人間の仲間なので、伝わるようにお願いする 42
やってみよう! 43
チームごとにTDD&モブプロ • • • • • • 今日の学びのゴールをひとつ決める ドライバーの交代方法を決める お題 (後で紹介) を読んでTODOリストを作る 開発環境を用意する (後で紹介) TDDでお題を実装する モブプロで問題を解く 講師陣が様子を見つつサポートします 質問や相談などお気軽に! 44
お題: 整数閉区間 https://gist.github.com/twada/75fb219c8cc180e9de166d8a58e877b0 45
お題: 整数閉区間 整数閉区間を示すクラス(あるいは構造体)をつくりたい。整数閉区間 オブジェクトは下端点と上端点を持つ。ただし、上端点より下端点が大 きい閉区間を作ることはできない。整数の閉区間は文字列表記を返 せる(例: 下端点 3, 上端点 8 の整数閉区間の文字列表記は "[3,8]")。また、整数の閉区間は指定した整数を含むかどうか、別の 閉区間と等価かどうか、完全に含むかどうかを判定できる。 46
別のお題 自信があるチームや、制御系のTDDに取り組みたいチームはこちら のお題も用意しました。難易度は整数閉区間より高いです。 自動販売機 (2023年とは違うバージョン) https://gist.github.com/yattom/1a0ae8b04c1273d0a7bd76af1333da06 エレベーター https://gist.github.com/yattom/3c1b4082b60c71ed925e2c89413068b0 47
別のお題: 自動販売機 自動販売機のプログラムをTDDで書いてみよう! 飲み物の自動販売機の動きを、プログラムで表現してください。 お題1. ボタンを押すとコーラが出る ボタンを押すとコーラが出ます。 テスト駆動開発のアプローチを有効活用して、進化的に設計をどんどん変えていきましょう。 お題2. お金を払う 100円コインを投入してからボタンを押すとコーラが出ます。 100円コイン以外は投入できません。 書いてある内容だけだと、仕様としては不十分で抜け漏れだらけです。 必要と思われる仕様を考え、テス トとして表現するよう意識してください。 命名のヒント 自動販売機のプログラムを書こうとするとき、いろいろな英語表現を知っていると便利です。まずは英語 版のWikipediaを見てみると、 いろいろな言葉を拾えます。 お題3. ウーロン茶追加 押したボタンに応じてコーラかウーロン茶が出ます。 他の飲み物も追加してみましょう。 以下にいくつかの例を挙げます。 お題4. レッドブル 200円入れるとレッドブルも買えます。 https://en.wikipedia.org/wiki/Vending_machine いろいろな値段をつけてみましょう。 自動販売機 = Vending Machine 受け取り口 = cup, open compartment 商品 = item, product 飲み物 = beverage (コインを)投入する = insert (商品を)排出する = dispense 支払い = payment お釣り = change お題5. ボタンが光る 入れたお金に応じて、買えるもののボタンが光ります。 お題6. 使えるコイン 100円コインの他に、10円、50円、500円コインも使えます。 お題7. お釣り ボタンを押して飲み物を買うと、お釣りが出ます。 お題8. 返却ボタン 飲み物を買わなくても、返却ボタンを押すと投入したお金が戻ってきます。 お題9. キャッシュレス決済 スマホ決済に対応します。 48
別のお題: 自動販売機 お題 エレベーターの制御をおこなうプログラムを書いてください。利用者の操作でカゴが移動し、ドアが開閉します。完全 である必要はありませんが、安全面への配慮もしてください。 実現してほしい機能 • ホールの呼ぶボタンを押すとエレベーターが来る • 同じ階にいればすぐドアが開く • 別の階からエレベーターが移動してくる • 着くとドアが開く • エレーベーター内で階のボタンを押すとその階に着く • その階まで移動する • 着くとドアが開く • エレベーターが移動中にホールから呼ぶと、エレベーターが来る • 通過する階だったら、移動中に寄ってくれる • そうでなければ、移動が終わってからあらためて移動する 49
中間ふりかえり 10分間 • • ここまでの1時間で、ゴールは達成できた? できそう? ここまでの1時間で、うまくいったことを付箋に書き出す • • これからの1時間で、挑戦したいことを話し合う • • • TDDとモブプロ、それぞれ 1つだけ決める ゴールの再達成でもOK、関係ないことでもOK 各グループから挑戦することを発表 (1グループ12秒) 50
ふりかえり 51
逸品をお持ち帰り 1. ハンズオンから見つけた「最高の逸品」を選ぶ • • • 2. 「最高の逸品」の説明をする • • 3. 上手くいったこと、役に立ったこと、楽しかったこと 具体的に。細かいこと、小さいことでOK TDDについて1点、モブについて1点 なにがどう最高なのか 使用上の注意や、必要な前提、事例など 各グループの逸品から自分が持ち帰りたいものを選び、 そのグループに移動して話す • • どうやって持って帰るか どの仕事で、どんな仕事で使うか 52
余談 (補足の講義) 53
今日の経験を一段深く理解する • TDDもモブプロも経験が重要 • • • 話だけ聞いても理解不十分だし、役立てられない 仕事の中で適切に、効果的に利用したい 「上手にやるとどうなるか」のイメージ 54
TDDのポイント • • • テストリストを作る レッド、グリーン、リファクタリング 歩幅を調節する • • 仮実装、三角測量、本実装、明白な実装 最初から完璧にしない、書けた範囲は完璧にする • • 常にリファクタリング テストもリファクタリング 55
テスト駆動開発は開発手法 • • • テスト手法ではない 実装を進める開発手法 プログラマーの不安を解消して品質に寄与するアプローチ TDD はテスト技法ではない(Cunningham の公案)。TDD は 分析技法であり、設計技法であり、実際には開発のすべてのア クティビティを構造化する技法なのだ。 『テスト駆動開発』ケント・ベック、p.278 56
テスト駆動開発は開発手法 != テスト手法 • • 開発者が開発を進めるためのテスト 品質保証とは別 • • • • 品質確保のためのテストは別途設計 結果的にカバーできる部分も 自動化に向かないテストもある テスト自動化につなげやすい • • • 自動テストが部分的でもある テストを増やせる テストしやすい設計 57
テスト駆動開発は導入が簡単 • • • 1人で始められる 小さく始められる 今やっている作業で始められる 58
計画・分析・設計・テスト・実装・品質 ゴール 分析と 計画 テ ス テストコード ト テストコード リ テストコード ス テストコード ト テストコード テストコード リファクタリングで きれい リファクタリングで きれい リファクタリングで きれい リファクタリングで きれい リファクタリングで リファクタリングで きれい きれい 設計 設計 設計 設計 設計 設計 プロダクトコード プロダクトコード プロダクトコード プロダクトコード プロダクトコード プロダクトコード 59
60 http://www.flickr.com/photos/nicohogg/75040212/
61 http://www.flickr.com/photos/risager/8388040402
62 https://www.flickr.com/photos/emotakespictures/33245514280/
63 https://www.flickr.com/photos/menschmaschine/19898877294/
64
モブプログラミングはチームそのもの • • • • プログラミングを進める 同時に設計ができ、レビューができ、動作確認やテストができる 全員の方向をそろえ、議論し、認識を合わせる 人から教わる学びも、新たな発見からの学びもあり、全員がいっ しょに学ぶ 65
モブプロのメリット ● ● ● ● ● チーム全体の力を出し切れる ミーティングがいらなくなる 常に学びと成長がある 集中できる 楽しい 66
モブプロするデメリットと モブプロしないデメリット • • • • • • 1人で集中できる / 1人で行き詰まる 分担できて効率が良い / 分担の準備やタスク分割が必要 手ばなれが良い / コードレビューやマージ作業が発生 1人で考えて決める / 知識が集中して引き継ぎが大変 自分のスタイルでできる / 一貫性や統一性が失われる 今すぐ片付けないと / 先々を考えないと 67
狭義のモブプロと広義のモブプロ 68
狭義のモブプロと広義のモブプロ ソロ ペア モブプロ モブプロ 69
狭義のモブプロと広義のモブプロ ソロ ペア モブプロ モブプロ モブプロ 70
モブプロのメリット ● ● ● ● ● か る あ が ト ッ メリ が ム ー チ る す 断 判 チーム全体の力を出し切れる ミーティングがいらなくなる 常に学びと成長がある 集中できる 楽しい 71
アジャイルソフトウェア開発宣言 Agile Manifesto 72
モブプログラミングはチームそのもの • • • • プログラミングを進める 同時に設計ができ、レビューができ、動作確認やテストができる 全員の方向をそろえ、議論し、認識を合わせる 人から教わる学びも、新たな発見からの学びもあり、全員がいっ しょに学ぶ チームにベストのやりかたをチームが選ぶ モブワークスタイルも選択肢の一つ 73
チームを (モブを) 支える精神的土台 • • • 親切 Kindness 熟慮 Consideration 尊重 Respect 「数ヶ月やってみてお互いのこ とが目障りになり始め…私たち はそのように扱われたいのだと わかった。…これらをガイドライ ンとしたところ、状況はすぐ好 転した」 (“Software Teaming” Woody Zuill, 和 74 訳はやっとむ)
75
76
77
78
79
まとめ • • • • • モブプロのメリット → メリットが出るようにモブプロする モブプロというスタイルを適切に選べるチームになる 時間をかけて上達する モブの上達に合わせ、仕事の組み立ても変えていく モブプロを通じた信頼 80
Q&A 81