Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Pull Request & TDD 入門

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Prochain SlideShare
TDD & Pull Request入門
TDD & Pull Request入門
Chargement dans…3
×

Consultez-les par la suite

1 sur 80 Publicité

Pull Request & TDD 入門

動作するきれいなコードを目指すためにすべきこと。
・Pull Requestで、プログラミングのスキルアップを!
・TDDで、動作するきれいなコードを!

2015年9月15日のセミナー資料。

動作するきれいなコードを目指すためにすべきこと。
・Pull Requestで、プログラミングのスキルアップを!
・TDDで、動作するきれいなコードを!

2015年9月15日のセミナー資料。

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (20)

Publicité

Similaire à Pull Request & TDD 入門 (20)

Plus par ESM SEC (20)

Publicité

Plus récents (20)

Pull Request & TDD 入門

  1. 1. 永和システムマネジメント TDDコーチ、アジャイルコーチ、プログラマ 家永英治 Pull Request & TDD 入門 〜 動作するきれいなコードを目指そう〜
  2. 2. 今日のゴール ➤Pull RequestやTDDとはなにかを知る ➤Pull RequestやTDDをはじめるコツを 学ぶ ➤Pull Request & TDD を体感して学ぶ 2
  3. 3. 目次 ➤導入部の説明 ➤Pull Requestの簡単な説明 ➤ハンズオン ➤ふりかえり と Q&A ➤休憩 ➤TDDの簡単な説明 ➤ハンズオン ➤ふりかえり と Q&A 3
  4. 4. 自己紹介 ➤家永英治  2003年 永和システムマネジメント入社  2005年頃 エクストリーム・プログラミングを使っ たチーム角谷に参画. 角谷・t-wadaに感銘を受ける  現在は、TDDコーチ、アジャイルコーチ、プログラ マを行っている 4
  5. 5. 私がTDDを気に入った背景 2005〜 角谷さん 和田さんに XPやTDDについて、実プロジェクトで指導を受ける 角谷さん 和田さんが抜けた後も、リーダーとしてメンテナンスを続ける メンテナンスを続ける中で、TDDやテストの自動化の嬉しさを改めて実感 私でも自信を持ってフィーチャの追加や修正ができる 障害対応も落ち着いて対処できる 2012〜 Scrumコーチとして、安井さん、西村さん、天野さんと現場の導入支援 Scrumのフレームワークのみの限界 開発の進め方自体はスクラムでは言及せず。開発チームに任されている。 が、自力のトライアンドエラーでテスト自動化やリファクタリングを使ってリーダブルコードつくれ る、設計できるようになるまでには時間がかかる TDDコーチ、テスト自動化の初期導入の依頼を受けることも 5
  6. 6. 私がPull Requestを気に入った背景 20xx 角谷さんが、海外の一部で注目を浴びていた Pull Request を社内に紹介 社内でも実験的に Pull Request を試すチームが現れる。広がる XPのチーム内のコードの共同所有の実現手段だけでなく、 チームを超えてのレビューが行われる。Pull Requestのコラボを通じて、 各々のコードを書く力がUPしていくのを目撃。(これは驚きだった) Pull Requestを見に行けば、開発者がなにをしているかそれとなく分 かる 私も微力ながら Pull Requestを使って、オープンソースへのコミット できることがわかった 2014 Pull Requestを使った社内開発に携わり、良さを改めて実感。 開発のコーチ時に紹介するようになった。 6
  7. 7. 参加者の調査 ➤好きな言語、得意な言語 ➤Pull Request試したことあるよ ➤TDD試したことあるよ ➤今日の講座の参加の動機 7
  8. 8. 開発のよくある悪循環 8 慌ててつくる レガシーコード スパゲティコード 時間がない
  9. 9. 9 コピペで重複が多数できる
  10. 10. 10
  11. 11. 技術的負債と変更コスト 11 t 技術的負債の増加を抑制 ・設計/コードをシンプルに保つ ・テストの自動化が促進 イテレーションを重ねても 機能の追加修正のコストを一定に保つ 変 更 コ ス ト 技術的負債が貯まる ・設計/コードが複雑化 ・手動テストの数 ・etc とりあえず 動けばOK 時間経過とともにコピペで重複 分岐が複雑化 クラスやメソッドの分割やネーミングが不適切 直し易さを維持する
  12. 12. Pull Request と TDDの 共通の軸
  13. 13. http://www.slideshare.net/YohNakamura/a3-38731262 不確実で難しい問題は トライ・アンド・エラー で素早くフィードバック を得ながら関わることが大事 13
  14. 14. 14 XPの多重のフィードバックループとコード Code ターゲットの領域
  15. 15. 15 学びの最大の障害物は “自分は解っている”の思い込み 予期せぬ驚きの発見に注意すること https://www.flickr.com/photos/photohannah/512202109/
  16. 16. 当初の計画【解き方A】では、 大きな障害物に出会うこともある しかし、早期にフィードバックを得ていれば慌てる時間ではないはず 素早く計画を変更し 【解き方B】に切り替えことが重要 (必要であれば【問題A】を【問題B】に置き換えること) 16 http://blog.goo.ne.jp/junsky/e/7fe1362e7295d0249591931a03dfbb61
  17. 17. 問題が難しいなら分解し ステップ・バイ・ステップで 解くことが大事 17
  18. 18. 18 https://www.flickr.com/photos/ryanh/43936630/ 早めに、こまめに リファクタリングすること を忘れずに
  19. 19. 19 ソフトウェアは人と人がつくっている コードを使って効果的なコミュニケーション ができることが大切 https://www.flickr.com/photos/menlopics/3928252097/
  20. 20. Pull Request
  21. 21. Pull Request とは? ➤“プルリクエストは、Bitbucket を使った 開発者のコラボレーションを促進する機 能の 1 つです。使いやすい Web イン ターフェイスで、提案された変更を公式 プロジェクトに統合する前に議論するこ とができます。” https://www.atlassian.com/ja/git/workflows#!pull-request 21
  22. 22. Github Flow https://guides.github.com/introduction/flow/index.html https://gist.github.com/Gab-km/3705015 http://scottchacon.com/2011/08/31/github-flow.html フィードバック コメント & 修正 22 Pull Request
  23. 23. Pull Request の嬉しさって? ➤オープンに/頻繁なコードレビュー バグの早期発見 仕様(問題の設定)の齟齬の早期発見 良い設計案の選択 技術的負債の防止 ➤メール代替の効果的なコラボ エンジニア同士でコードを中心にしたコミュニケーション 外部のオープンソースのコミュニティへの参画のしやすさ ビジネス側と開発側のコラボレーション ➤オンライン上で共に学習と成長 普段、誰が何をやっているのかよくわかり、真似て学ぶことができる コードベースに文法やイディオムやライブラリの理解やドメイン知識の共有、スキルアップ 23
  24. 24. 環境の確認 ➤Git のインストール ➤GitHub Accountの作成 ➤SSH setting https://help.github.com/articles/generating-ssh-keys/ ➤fork ➤clone git@github.com:<your id>/tdd-pullrequest-rspec- exercise1.git git@github.com:<your id>/tdd-pullrequest-java- exercise1.git ➤README.mdを参考に Testが実行できるか確認 24
  25. 25. 演習1 ➤途中まで作成したFizzBuzzにテスト を追記(数字を返すケース)と修正を 行ないプルリクを投げよう 25
  26. 26. 基本ステップ(Forkを使う場合) ➤ fork ➤ clone ➤ トピックブランチの作成(テスト追加とバグ修正) ➤ 修正,動作確認 ➤ commit ➤ push ➤ Pull Request [GitHub上] ➤ フィードバックコメント [GitHub上] ➤ コメント対応, commit, push (追加修正が必要がなくなるまで) ➤ rebase or merge and push (もし、コンフリクトでMerge できない場合) ➤ Merge[GitHub上] (もし、マージしてOKなら) 26
  27. 27. 27
  28. 28. 28 ➤「真似て学ぶ」は学習の基本 ➤他人のプルリクへのコメントを読めば コードの書き方の注意点も学ぶことができる ➤知らないライブラリやコードのイディオムを 見つけて、より良いコードの書き方を 学ぶことができる 他人のプルリクを読む
  29. 29. 29 ➤大きすぎる1つのプルリクで問題を解決 しようとすると、 レビューがむずかしい、 設計議論が収束しない、 マージが難しいなどが発生してしまうた め ※ 手頃なサイズに明確な基準はないけれど、人によっては例えば、 変更が200行程度の量、4日以内で終わる量、ある作業を2つの意味のあ る作業単位で分割してプルリクを目安に プルリクは手頃なサイズにする
  30. 30. ユーザス トーリー XP(Scrum)-プルリクの連動 2週間タイムボックス プ ラ ン ニ ン グ レ ビ ュ ー ( デ モ ) プ ラ ン ニ ン グ レ ビ ュ ー ( デ モ ) プ ラ ン ニ ン グ レ ビ ュ ー ( デ モ ) プ ラ ン ニ ン グ レ ビ ュ ー ( デ モ ) 市 場 に フ ィ ッ ト す る プ ロ ダ ク ト ( 動 作 す る コ ー ド ) を つ く る 目 標 に 向 か っ ス テ ッ プ バ イ ス テ ッ プ で 開 発 ユーザス トーリー ユーザス トーリー タスクタスクタスク フィードバック 30 予期せぬ修正に対応できるようにメンテナンスできるコード (きれいなコード)を書く
  31. 31. 31 ➤手遅れになる前に、途中段階から素早く コードの書き方や設計判断等のフィード バックもらうため ➤リポジトリにバックアップを残すため ※ ✗ 10日の作業をまとめてプルリク => ○午前中の作業までを プルリク ※ 未完のプルリクは、タイトルに “WIP” や 作業中であることがわかるラベルを 付ける ※1人で解くには問題が難しくもっと早くフィードバックが欲しい場合は、問題や 解き方を紙に描いて他人に話してから開発する、ペアプロやモブプログラミングで 対話しながらつくる代替案も 完成しなくてもプルリクを投げる 設計などで相談に乗って欲しい場合
  32. 32. TitleやDescriptionを書く プルリクの作成時 32 ➤周囲にどんな作業をしているか知ってもらい フィードバックをもらいやすくするため ➤他人に説明することで、 問題や解き方や要確認事項等の理解を整理するた め (ゴムのアヒルちゃん) ※フォーマットは様々だが、Titleには何をやったのか(やろうとしているか)の要約、Descriptionには リ クエストがなぜ必要とされるかの背景や理由, やったことリスト( Todoリスト)、Issueやチケット管理等 のリンク, 相談や外部に確認したい項目などなどが記載される
  33. 33. UIの画像をプルリクに添付する UIありでものをつくる場合、細かなUIイメージが決まっていない場合 33 ➤何をつくるとよいか(問題の定義)の議 論をUIを使って明確にするため ※ 仕事を依頼する人、デザインする人、プログラムを作る人が、プルリクに添付された UI画像を参照しオンライン上で議論し、収束 ※ Gifで動きを見せたり、Before/Afterを見せたり工夫も ※ プルリクのオンライン上ではなくチケットシステムや会議室で収束させる代替案も
  34. 34. 34 ➤テストは読み手にとって、何の問題を解こう として実装しているを理解する手がかりとな り、フィードバックしやすくなるため ➤第三者によるテストの抜け漏れも、フィード バックできるから プルリクに自動テストのコードを含める
  35. 35. ➤レビューアが読みやすくフィード バックしやすくするため ※ 期待通り動作することを確認してcommit, リファクタリングしてcommit したのをプルリク ※ あとで見直して、問題のあるコードをリファクタリングしてプルリク ※ 問題を解く前に、修正しやすくするためにリファクタのみをテーマにしたプルリクをなげ、そののちに問題を解く プルリクを投げる 35 リファクタリングと問題を解く実装は分ける
  36. 36. ➤迷った設計判断などを記述しておけ ば、周囲からフィードバックが得や すいため ※ プルリクに自分でコメントかコード中にコメントを書く 36 相談に乗って欲しい箇所は明示的にコメントを書く
  37. 37. ➤助け合いの関係を醸成するため ➤楽しく作業するため ※ オンライン上のコミュニケーションは殺伐とした関係になりがちなので注 意が必要。「いいね!」や「感謝の気持ち」などを絵文字で表現すると文字だ けで伝えづらいことも伝えられる ※ コメントをもらう人とまだ信頼関係が醸成されていない場合は、 直接対話でフィードバックもらってコメントに記録する代替案も 37 会話に絵文字を利用する
  38. 38. プルリクで略語用語を利用する 38 ➤圧縮してコミュニケーションを成立させるため WIP 作業中 LGTM OK! いいね!(私は問題ないと思うよ) Must 必ず直すべき Nits 細かい指摘 IMO 私の見解では。。。 Fix xxx バグ修正 Cosmetic、Refactor コード整形
  39. 39. 39 ➤チームメンバーに素早く通知し、素早く フィードバックもらうため ➤フィードバックをもらった後に直ぐに対 応できるようにするため ※ SlackやHipChatなどが有名。永和だと idobata GitHubとChatツールを連携する
  40. 40. GitHubとチャットツール連携 push Pull Request コメント Merge(Acceptedなら) checkout –b commit 通知 通知 40
  41. 41. プルリクと外部ツールを連携させる 41 たとえば、 ➤プルリクをトリガーにCIを実行する ビルドエラーを早期に発見し対応するため ➤プルリクをトリガーにデプロイする 本番に近い環境に即デプロイし動作確認しフィードバックを得て対応するため
  42. 42. Gitを使ったワークフローを明らかにする 42 https://guides.github.com/introduction/flow/index.html https://gist.github.com/Gab-km/3705015 http://scottchacon.com/2011/08/31/github-flow.html http://postd.cc/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/ http://nvie.com/posts/a-successful-git-branching-model/ Github Flow,GitLab Flow,Git Flow
  43. 43. オススメのプルリクの自習・学習 ➤ Github実践入門本を写経 (真似てタイプして著者の追体験する) ➤ 練習、練習、練習 https://github.com/octocat/Spoon-Knife https://github.com/github-book/first-pr ➤ オープンソースのプルリクを覗いてみる ➤ ライブラリの学習でついでにプルリク投げること サブ目標にする (ドキュメントの記述間違いなどは初心者もプルリクしやすい) ➤ 同じチームで社内勉強会を開き、プルリクを試してみる 43
  44. 44. 継続的インテグレーション(CI)テスト駆動開発(TDD)
  45. 45. どんなふうに問題を解く?どうやってつくる? 45 • 問題を理解する • 解き方を考える • 問題を解いて、ふりかえる • スモール・イズ・ビューティフル • 一つのプログラムには一つのこと をうまくやらせる • できるだけ早く試作を作成する 。。。
  46. 46. テスト駆動開発とは? “テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラ ムに必要な各機能について、最初にテストを書き(これをテスト ファーストと言う)、そのテストが動作する必要最低限な実装をとり あえず行った後、コードを洗練させる、という短い工程を繰り返すス タイルである。” -- Wikipediaより 46 http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
  47. 47. “「動作するきれいなコード」、ロン・ジェフ リーズ のこの簡潔な言葉は、TDD(テスト駆 動開発)の目 標である。動作するきれいなコー ドは、あらゆる 理由で価値がある。 ─ Kent Beck 47
  48. 48. @t-wada 48
  49. 49. TDDとフィードバック 49
  50. 50. フィードバックで学ぶこと 50 Why (機能が必要とさる背景理由は?) What (何ができたら機能が完成した と言える?) How (どう実現したらリーダブルで 変更しやすい?)
  51. 51. TDDの嬉しさって? ➤高速の試行錯誤で問題や解き方を学びな がら進めることができる 単位時間あたりの学びの量と質を上げる ➤頻繁にコードや設計の見直しの機会があ り、安心してリファクタリングできる テストがあるおかげ ➤新たな要望(追加問題)にも自信をもって 修正できるコードを手に入れられる シンプルなコードと自動化されたリグレッションテスト 51
  52. 52. [演習2] ➤ FizzBuzz問題の続きをTDDを使っ て解いてみよう。 進め方例 3の倍数の場合についてをRed Green Refactorリズムで解く。Commit 5の倍数の場合についてをRed Green Refactorリズムで解く。Commit 3と5の倍数の場合についてをRed Green Refactorリズムで解く。Commit 52
  53. 53. Red Green Refactor ➤テスト書く ➤実行して Red になることを確認 ➤最小の実装 ➤実行して Greenになること確認 ➤リファクタリング 上記を完成するまで繰り返す 53
  54. 54. [演習3] ➤ スタックをTDDを使って作ってみよう 54 メソッド名 説明 boolean isEmpty() ・スタックが空の場合はtrue、それ以外はfalseを返す int size() ・スタックに積まれている値の数を取得する void push(int value) ・引数の値をスタックの一番上に積む ・スタックに積まれている値の数が1つ増える ・スタックには値を10個まで積めること、11個以上積んだ時の 挙動は不定とする(※1) void pop() ・スタックの一番上の値を取り除く ・スタックに積まれている値の数が1つ減る ・スタックが空のときはEmptyException例外が発生する(※2) int top() ・スタックの一番上の値を取得する ・スタックに積まれている値の数は変化しない ・スタックが空のときはEmptyException例外が発生する(※2) 演習メモ ※1:内部のデータの持ち方は、配列でもコレクションクラスでもよい。 ※2:例外クラスは、独自に定義する。
  55. 55. 演習3のハードル設定は選択 ✓ ベイビーステップでユニットテストを使って動作確認しながら進める ✓ グリーン時にこまめにリファクタリングする ✓ 先にテストを書く。Red Green Refactorのリズムで解く ✓ 成功時にハイタッチ!する ✓ 小さい単位で コミットしながら進める ✓ GitHub上にリポジトリーを用意する ✓ 小さい単位で プルリクを投げながら進める 例) - テスト込みで isEmpty, size が完成するまでを1つ - push & topが完成するまでを1つ - popが完成するまでを1つ - push の例外が完成するまで1つ - top の例外が完成するまで - 一連のスタックの使い方がわかるテストを追加するまで1つ 55
  56. 56. 56
  57. 57. TODO - 誕生 - 生存 図を描いたり、TODOリストを用意する TDDサイクルを回す前に 57 ➤問題を理解するため ➤解く道筋(当初の計画、解き方A案)を明らか にするため ※はじめにすべて書き出す必要はない ※あとからTODOを発見して追加してもOK ※あとで、解き方A案に大きな障害物を発見して、捨てることもある
  58. 58. 58 TODO ----- ○誕生 生存 過疎 過密 誕生 Field? Cell -------- row col status 0行 1行 2行 2 列0 列 1列 死んでいるセルに隣接する生きたセルが ちょうど3つあれば、次の世代が誕生する。 1 n
  59. 59. TODO - 誕生 - 生存 59 ➤解き方のコアとなる骨組みを明らかにす るため (解き方(設計・実装)の学びが得られるTODOはどれだろうか?) ※ 途中で発見した正常系のバリエーションや異常系はTODOに積んで、あとで解く ハッピーパス(正常系)を選択する 一つ目のタスクを選ぶとき
  60. 60. TODO - 誕生 - 生存 先にテストを書いて失敗を確認する タスクに着手したら 60 ➤ 問題を実行可能なテストで明確にするため (何が実行できたら問題を解いたと言える?) ➤ テスト対象のメソッドの使い方例を明瞭にするため (クラスやメソッドを利用する人はどう使えると嬉しいだろうか?) ➤ テストが期待通り動作していることを確認するため ➤ 後日にまとめてテストでは、テストが記述が難しい実装に なってしまうため (testでassertが書けるように実装するにはどうすればよいだろうか?) ※問題を解く前に問題を明瞭にするのは、問題を解くときのの基本鉄則。テストで表現するのがポイント ※ただしテストファーストに慣れずに手が止まってしまうなら、TDDの制約をゆるめ、“ちょっと実装したら直ぐテストで確認 (つまり何の問題を解いてたのか?をテストで明瞭にしてみよう)”で始めるがオススメ
  61. 61. TODO - 誕生 - 生存 テスト失敗は基本は1つにする 問題を解いている時 61 ➤一つの問題に集中してとりくむため。 一度に複数の問題を相手して、混乱しないた め (自分が今、集中して解きたい問題は何だろうか?) ※ 誕生を解くことに集中 ※ Ignoreやコメントアウトのほか、テスティングフレーワークの機能を使って特定のメソッドを指定して実行する
  62. 62. TODO - 誕生 - 生存 62 ➤前提条件(Arrange)、 テスト対象への行為(Act)、 期待結果の表明(Assert)の3つで 問題を整理して理解を深めるため (期待結果はなんだろうか?、操作や前提条件は?) ※ 3Aの整理で迷ったら、まず期待結果の表明(Assert)が何かを明らかにする がオススメ(Assert First) Arrange Act Assertで テストコードを整理する
  63. 63. TODO - 誕生 - 生存 失敗のレポートを読んで次の一手を考える テスト失敗の時、実装が未完の時 63 ➤エラーメッセージやテストの失敗レ ポートから、次に何をすべきかを把 握できるため (コンピュータは僕に何を教えてくれている?) ※コンピュータと対話しながら問題を解く ※ IDEが使える言語なら、エラー箇所にジャンプやコンパイルエラー時にコード生成機 能を駆使する ※ エラーの意味がわからなければ、Googleや Stack Overflowなどで検索
  64. 64. TODO - 誕生 - 生存 テストの失敗時のレポートを読みやすくする 失敗が読んでわかりにくい場合 64 ➤自分が今何に取り組もうとしているかの 問題を明瞭にするため ➤後日のテスト失敗時に、他の人が読んで 直ぐ理解して対応できるようにするため ※ たとえばテストのメソッド名を工夫する ※ power-assertも テスト失敗時の内容がわかりやすくするための方法の1つ
  65. 65. TODO - 誕生 - 生存 65 ➤APIや既存ライブラリの使い方がわか れば問題がより簡単に把握できるよう になるため(巨人の肩にのる!) ※ かわりに REAP(対話シェル環境)を利用して学習するもオススメ テストを使ってライブラリの使い方を学ぶ 知らないAPIやライブラリを学びたい場合
  66. 66. TODO - 誕生 - 生存 小さな問題に分割して解く レッドからグリーンに遷移させるのに時間がかかり難しい場合 66 ➤分解した小さい問題をクリアできれば、 以前より大きな問題は簡単に解けるよう になるため (2時間以上グリーンを観ていない。もっと小さく問題を分割して解けないだろうか?) ※ TODOリストに追加や順序の入れ替えを忘れずに 一つのプログラムには一つのこ とをうまくやらせる
  67. 67. TODOの見直し 67 TODO ----- ○誕生 ○ ArrayのAPIの学習(寄り道) 周囲の生きているセルの数 仮実装を置き換え メソッドの移動 … 生存 過疎 過密
  68. 68. TODO - 誕生 - 生存 68 ➤難しい問題も簡単なベタ書きなら停滞せずに先 に進め、以前よりも解き方の理解が捗るため (あれ?長時間レッドだな。落ち着こう。ベタ書きにするとどうなるだろうか?) (問題が難しそう?一旦ベタ書きからはじめてみよう) ➤テストが期待通り動作(グリーン)することを 確認するため ベタ書きから一般化で問題を解く レッドの時に次の一手がむずかしい場合
  69. 69. TODO - 誕生 - 生存 69 ベタ書きを一般化 不吉な臭い オブジェクト指向 SOLID原則 パターン 関数型プログラミング イディオム コーディング規約 … 現状のコードや設計の良し悪しを判断する テスト結果がグリーンの時に KISS 名前重要 DRY原則 スモールイズビュー ティフル …
  70. 70. TODO - 誕生 - 生存 こまめにリファクタリングする テスト結果がグリーンの時はチャンスタイム!! 70 ➤あとから自分や他人が読んで直ぐに理解できる ようにするため ➤あとから(予期せぬ)コード修正をできるよう にするため ➤気分すっきり! ※ レッド時にリファクタリングは、危険な作業 ※ レッド時に発見した修正したい項目は TODOなどに積んで、あとで実施する ※ TDDの文脈では、ベタ書きから一般化もリファクタリングの一つ
  71. 71. 71 グリーンの時は リファクタリング チャンスタイム!
  72. 72. TODO - 誕生 - 生存 72 ➤小さく回すのは「下手な長考休むに似たり」の 代わりに、早く実験して【学び】を得たいから (サイクルの結果、問題や解き方(実装や設計)について学んだことは何だろうか?) ➤言い換えると、問題把握ー>解決ー>整理整頓の繰り 返しのリズム (TDDのサイクルの目安は10分だが実際は何分サイクルだろうか? ) ➤プログラミングの現状の透明性を高めるため (今は問題定義している時?解いている最中?解けた状態?リファクタして壊していない?) Red Green Refactorのリズムで ステップ・バイ・ステップに解く
  73. 73. TODO - 誕生 - 生存 73 ➤期待通りテストが機能しているかを再確 認するため コードの一部をコメントアウトする テストが本当に機能しているか不安を感じたとき
  74. 74. TODO - 誕生 - 生存 74 ➤うまくできなかった時に、すぐにセーブ ポイントに戻って、作業を再開できるよ うにするため ※ エディタの戻るや履歴機能の代替案も ※ ブランチで作業して捨てる。あるコミット地点に戻る バージョン管理を使う キリの良い作業単位が終わった時、テストがグリーンの時
  75. 75. TODO - 誕生 - 生存 75 ➤「当初の計画(解き方A案)がまずかっ た」もTDDサイクルで得た学びの1つ ※ 別の解き方Bを試す ※ 問題Aを問題Bに再設定して、問題と解き方を共にシンプル(解くコストに見合う価値のある。読み やすい。後から修正しやすい…)にできないかも検討する 別の解き方B案に切り替える 当初の計画(解き方A案)に大きな障害物を発見した場合
  76. 76. TODO - 誕生 - 生存 76 ➤テストの抜け漏れを発見するため (境界値・同値分割の観点からは?異常系は?) ➤他の人が読みやすくするため (テストもリファクタリング対象) ➤不要なテストを削除してメンテナンスし やすくするため (試行錯誤の過程で必要だったテストも完成すれば、不要になることもある) テストを見直し整理整頓する
  77. 77. テストの書き方のポイント 抜粋 77 ➤テストコードも失敗レポートも人が読んで理解で きるように書く あとで読んで直ぐに理解し、修正しやすくするため ➤テスト間は独立して実行できるように書く 失敗時に問題箇所を特定しやすくするため ➤ALLテストが繰り返し グリーンになるように書く メンテナンスしやすくするため。例えば時間に依存したテストは注意 ➤テストの実行時間が長いスローテストに注意する 実行に時間がかかりすぎると問題発見が遅れるやテスト実行しなくなるため ➤ちょっとした修正で予期せずテストが大量に失敗してし まう脆いテストに注意する 脆いなら自動テストの費用対効果は低い。設計・実装・テストに何か不味いことがある兆候
  78. 78. オススメのTDDの自習・学習 ➤TDD本、Rails Tutorialを写経 (真似てタイプして著者の追体験する) ➤練習お題を繰り返し解く プログラミングの学習法として、Code Kata 、「写経」、「練習、 練習、練習」などが知られているが TDDも練習が必要 - http://d.hatena.ne.jp/absj31/20120721/1342880403 - http://devtesting.jp/tddbc/?TDDBC%E4%BB%99%E5%8F%B003%2F%E8%AA%B2 %E9%A1%8C ➤仲間同士で集まってチャレンジして、意見交換する ➤TDDBCや Coderetreat などのプログラミングを学 ぶイベントに参加。自分よりうまい人から教わる http://devtesting.jp/tddbc/ ➤パターンなど一般的な設計の本を読む。ネットで調べ る 78
  79. 79. 継続的インテグレーション(CI)Q&A
  80. 80. 80 コアとなる問いかけ “問題Aに取り組む理由は?” “期待する振る舞いや結果は何だろうか?” “期待と実際とのギャップを埋めるにはどうしたら良いのだろうか?” “解き方Aは妥当と判断する理由は?” “トライ・アンド・エラーのサイクルの結果、私はいったい、 何を発見し学んだだろうか?” “どうすれば単位時間あたりのトライ・アンド・エラーの数(学びの数) を圧倒的に伸ばすことができるだろうか?” http://c2.com/cgi/wiki?TestDrivenDevelopment

×