TDD & Pull Request入門
•Download as PPTX, PDF•
27 likes•5,354 views
学生向け講座用に作成した資料。TDDとPull Requestの基本的なコツをまとめた。
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (20)
Similar to TDD & Pull Request入門
Similar to TDD & Pull Request入門 (20)
TDD & Pull Request入門
- 1. 永和システムマネジメント 家永英治 TDD & Pull Request 入門 〜 動作するきれいなコードを目指そう〜
- 2. 今日のゴール ➤TDDとは？を知る ➤Pull Request(プルリク)とは？を知る ➤TDD ＆ Pull Requestの自習・学習方法 を持ち帰る ※ハンズオン形式で学ぶ講座ではありません。座学と見学で学ぶ講座です。 ※簡単な例を実演で提示します。 2
- 3. 自己紹介 ➤家永英治 2003年 永和システムマネジメント入社 2005年頃 エクストリーム・プログラミングを使っ たチーム角谷に参画. 角谷・t-wadaに感銘を受ける 最近は、ScrumやTDDやテスト自動化の導入支援 のコーチを行っている 3
- 6. 6
- 7. TDD と Pull Requestの 共通の軸
- 8. http://www.slideshare.net/YohNakamura/a3-38731262 不確実で難しい問題は トライ・アンド・エラー で素早くフィードバック を得ながら関わることが大事 8
- 10. 10 学びの最大の障害物は “自分は解っている”の思い込み 予期せぬ驚きの発見に注意すること https://www.flickr.com/photos/photohannah/512202109/
- 15. どんなふうに問題を解く？どうやってつくる？ 15 • 問題を理解する • 解き方を考える • 問題を解いて、ふりかえる • スモール・イズ・ビューティフル • 一つのプログラムには一つのこと をうまくやらせる • できるだけ早く試作を作成する 。。。
- 16. テスト駆動開発とは？ “テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラ ムに必要な各機能について、最初にテストを書き（これをテスト ファーストと言う）、そのテストが動作する必要最低限な実装をとり あえず行った後、コードを洗練させる、という短い工程を繰り返すス タイルである。” -- Wikipediaより 16 http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
- 17. “「動作するきれいなコード」、ロン・ジェフ リーズ のこの簡潔な言葉は、TDD(テスト駆 動開発)の目 標である。動作するきれいなコー ドは、あらゆる 理由で価値がある。 ─ Kent Beck 17
- 18. @t-wada 18
- 19. [TDDの見学] ➤ ライフゲームの練習お題を途中まで 解く実演 ※ 途中の掛け声をお願いすることがありますが、 ご協力お願いします。 “実装する前に？” ー＞ “テスト！” “きりの良いレッドからグリーンに変わったら” -> （ハイタッチ！） “実行結果がグリーンの時は？” -> “リファクタリング！リファクタリング！” 19
- 20. 20
- 22. 22 TODO ----- ○誕生 生存 過疎 過密 誕生 Field? Cell -------- row col status 0行 1行 2行 2 列0 列 1列 死んでいるセルに隣接する生きたセルが ちょうど3つあれば、次の世代が誕生する。 1 n
- 23. TODO - 誕生 - 生存 23 ➤解き方のコアとなる骨組みを明らかにす るため （解き方(設計・実装)の学びが得られるTODOはどれだろうか？) ※ 途中で発見した正常系のバリエーションや異常系はTODOに積んで、あとで解く ハッピーパス(正常系)を選択する 一つ目のタスクを選ぶとき
- 24. TODO - 誕生 - 生存 先にテストを書いて失敗を確認する タスクに着手したら 24 ➤ 問題を実行可能なテストで明確にするため （何が実行できたら問題を解いたと言える？） ➤ テスト対象のメソッドの使い方例を明瞭にするため （クラスやメソッドを利用する人はどう使えると嬉しいだろうか？） ➤ テストが期待通り動作していることを確認するため ➤ 後日にまとめてテストでは、テストが記述が難しい実装に なってしまうため (testでassertが書けるように実装するにはどうすればよいだろうか？) ※問題を解く前に問題を明瞭にするのは、問題を解くときのの基本鉄則。テストで表現するのがポイント ※ただしテストファーストに慣れずに手が止まってしまうなら、TDDの制約をゆるめ、“ちょっと実装したら直ぐテストで確認 （つまり何の問題を解いてたのか？をテストで明瞭にしてみよう）”で始めるがオススメ
- 25. TODO - 誕生 - 生存 テスト失敗は基本は１つにする 問題を解いている時 25 ➤一つの問題に集中してとりくむため。 一度に複数の問題を相手して、混乱しないた め (自分が今、集中して解きたい問題は何だろうか？) ※ 誕生を解くことに集中 ※ Ignoreやコメントアウトのほか、テスティングフレーワークの機能を使って特定のメソッドを指定して実行する
- 26. TODO - 誕生 - 生存 26 ➤前提条件(Arrange)、 テスト対象への行為(Act)、 期待結果の表明(Assert)の３つで 問題を整理して理解を深めるため （期待結果はなんだろうか？、操作や前提条件は？） ※ 3Aの整理で迷ったら、まず期待結果の表明(Assert)が何かを明らかにする がオススメ（Assert First） Arrange Act Assertで テストコードを整理する
- 27. TODO - 誕生 - 生存 失敗のレポートを読んで次の一手を考える テスト失敗の時、実装が未完の時 27 ➤エラーメッセージやテストの失敗レ ポートから、次に何をすべきかを把 握できるため (コンピュータは僕に何を教えてくれている？) ※コンピュータと対話しながら問題を解く ※ IDEが使える言語なら、エラー箇所にジャンプやコンパイルエラー時にコード生成機 能を駆使する ※ エラーの意味がわからなければ、Googleや Stack Overflowなどで検索
- 28. TODO - 誕生 - 生存 テストの失敗時のレポートを読みやすくする 失敗が読んでわかりにくい場合 28 ➤自分が今何に取り組もうとしているかの 問題を明瞭にするため ➤後日のテスト失敗時に、他の人が読んで 直ぐ理解して対応できるようにするため ※ たとえばテストのメソッド名を工夫する ※ power-assertも テスト失敗時の内容がわかりやすくするための方法の１つ
- 29. TODO - 誕生 - 生存 29 ➤APIや既存ライブラリの使い方がわか れば問題がより簡単に把握できるよう になるため（巨人の肩にのる！） ※ かわりに REAP(対話シェル環境)を利用して学習するもオススメ テストを使ってライブラリの使い方を学ぶ 知らないAPIやライブラリを学びたい場合
- 30. TODO - 誕生 - 生存 小さな問題に分割して解く レッドからグリーンに遷移させるのに時間がかかり難しい場合 30 ➤分解した小さい問題をクリアできれば、 以前より大きな問題は簡単に解けるよう になるため (2時間以上グリーンを観ていない。もっと小さく問題を分割して解けないだろうか？) ※ TODOリストに追加や順序の入れ替えを忘れずに 一つのプログラムには一つのこ とをうまくやらせる
- 34. TODO - 誕生 - 生存 こまめにリファクタリングする テスト結果がグリーンの時はチャンスタイム！！ 34 ➤あとから自分や他人が読んで直ぐに理解できる ようにするため ➤あとから（予期せぬ）コード修正をできるよう にするため ➤気分すっきり！ ※ レッド時にリファクタリングは、危険な作業 ※ レッド時に発見した修正したい項目は TODOなどに積んで、あとで実施する ※ TDDの文脈では、ベタ書きから一般化もリファクタリングの一つ
- 36. TODO - 誕生 - 生存 36 ➤小さく回すのは「下手な長考休むに似たり」の 代わりに、早く実験して【学び】を得たいから （サイクルの結果、問題や解き方（実装や設計）について学んだことは何だろうか？） ➤言い換えると、問題把握ー＞解決ー＞整理整頓の繰り 返しのリズム （TDDのサイクルの目安は10分以下だが実際は何分サイクルだろうか？ ） ➤プログラミングの現状の透明性を高めるため （今は問題定義している時？解いている最中？解けた状態？リファクタして壊していない？） Red Green Refactorのリズムで ステップ・バイ・ステップに解く
- 38. TODO - 誕生 - 生存 38 ➤うまくできなかった時に、すぐにセーブ ポイントに戻って、作業を再開できるよ うにするため ※ エディタの戻るや履歴機能の代替案も ※ ブランチで作業して捨てる。あるコミット地点に戻る バージョン管理を使う キリの良い作業単位が終わった時、テストがグリーンの時
- 39. TODO - 誕生 - 生存 39 ➤「当初の計画（解き方A案）がまずかっ た」もTDDサイクルで得た学びの１つ ※ 別の解き方Bを試す ※ 問題Aを問題Bに再設定して、問題と解き方を共にシンプルにできないかも検討する 別の解き方B案に切り替える 当初の計画(解き方A案)に大きな障害物を発見した場合
- 43. オススメの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/ ➤ パターンなど一般的な設計の本を読む。ネットで調べる 43
- 45. Pull Request
- 46. Pull Request とは？ ➤“プルリクエストは、Bitbucket を使った 開発者のコラボレーションを促進する機 能の 1 つです。使いやすい Web イン ターフェイスで、提案された変更を公式 プロジェクトに統合する前に議論するこ とができます。” https://www.atlassian.com/ja/git/workflows#!pull-request 46
- 47. 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 フィードバック コメント ＆ 修正 47 Pull Request
- 48. [Pull Requestの見学] ➤重複コードを修正する簡単なシナリオ トピック・ブランチの作成 修正・コミット・プッシュ Pull Requestの作成 第三者のコメント コメントのフィードバック対応 マージ ※今日は一人で行っていますが通常は、複数人で行います ※ https://www.railstutorial.org/ を参考にお題を作成 48
- 49. 49
- 53. 53 ➤手遅れになる前に、途中段階から素早く コードの書き方や設計判断等のフィード バックもらうため ➤リポジトリにバックアップを残すため ※ ✗ 10日の作業をまとめてプルリク => ○午前中の作業までを プルリク ※ 未完のプルリクは、タイトルに “WIP” や 作業中であることがわかるラベルを 付ける ※１人で解くには問題が難しく、もっと早くフィードバックが欲しい場合は、問題 や解き方を紙に描いて他人に話してから開発する、ペアプロやモブプログラミング で対話しながらつくる代替案も 完成しなくてもプルリクを投げる 設計などで相談に乗って欲しい場合
- 54. TitleやDescriptionを書く プルリクの作成時 54 ➤周囲にどんな作業をしているか知ってもらい フィードバックをもらいやすくするため ➤他人に説明することで、 問題や解き方や要確認事項等の理解を整理するた め (ゴムのアヒルちゃん) ※フォーマットは様々だが、Titleには何をやったのか（やろうとしているか）の要約、Descriptionには リ クエストがなぜ必要とされるかの背景や理由, やったことリスト（ Todoリスト）、Issueやチケット管理等 のリンク, 相談や外部に確認したい項目などなどが記載される
- 55. UIの画像をプルリクに添付する UIありでものをつくる場合、細かなUIイメージが決まっていない場合 55 ➤何をつくるとよいか（問題の定義）の議 論をUIを使って明確にするため ※ 仕事を依頼する人、デザインする人、プログラムを作る人が、プルリクに添付された UI画像を参照しオンライン上で議論し、収束 ※ Gifで動きを見せたり、Before/Afterを見せたり工夫も ※ プルリクのオンライン上ではなく会議室で収束させる代替案も
- 57. ➤レビューアが読みやすくフィード バックしやすくするため ※ 期待通り動作することを確認してcommit, リファクタリングしてcommit したのをプルリク ※ あとで見直して、問題のあるコードをリファクタリングしてプルリク ※ 問題を解く前に、修正しやすくするためにリファクタのみをテーマにしたプルリクをなげ、そののちに問題を解く プルリクを投げる 57 リファクタリングと問題を解く実装は分ける
- 60. プルリクで略語用語を利用する 60 ➤圧縮してコミュニケーションを成立させるため WIP 作業中 LGTM OK! いいね！（私は問題ないと思うよ） Must 必ず直すべき Nits 細かい指摘 IMO 私の見解では。。。 Fix xxx バグ修正 Cosmetic、Refactor コード整形
- 65. オススメのプルリクの自習・学習 ➤ Github実践入門本を写経 （真似てタイプして著者の追体験する） ➤ 練習、練習、練習 https://github.com/octocat/Spoon-Knife https://github.com/github-book/first-pr ➤ オープンソースのプルリクを覗いてみる ➤ ライブラリの学習でついでにプルリク投げること サブ目標にする （ドキュメントの記述間違いなどは初心者もプルリクしやすい） ➤ 学生向けイベントに参加して、自分よりうまい人と出会う http://www.seplus.jp/sezemi/github/ http://www.seplus.jp/sezemi/ohw/ ➤ 同じ研究室内の学生同士でプルリクを試してみる。 ➤ オープンソースのコードを読んでみる 65
Editor's Notes
- 「読めない」 「変更箇所が分散して影響範囲が読めない。。。」 「修正して壊したらどうしよう」
- ”目標値”と”実際の値”を比較して 値が一致するまで調整する仕組み． 運転の際は、人が目の前を見て、安全に（車間距離とるや歩道に乗り上げずに） 目的地： 箱根、なんで箱根？ 家族で温泉旅行を楽しみたい！ 前日に箱根が大雨で行くのが微妙。じゃ代わりに、群馬の温泉にしようか。
- 顧客が ビジネスのハンドルを握って
- 大きな問題を小さな問題に分割してステップバイステップでとくことが大事
- 大きな問題を小さな問題に分割してステップバイステップでとくことが大事
- 大きな問題を小さな問題に分割してステップバイステップでとくことが大事
- 大きな問題を小さな問題に分割してステップバイステップでとくことが大事
- 動作する＝ ユーザにとって役立つ、使える。目的を果たせる.市場にフィットしたプロダクト きれいな＝ 未来のめんテナーにとって修正できる、障害があってもすぐに解析して直せる 動作するきれいなコードを目標に実現する方法はTDDだけではない
- テストとともにリファクタリングできれいなコードを作れる。 外側のAcceptance Testing では、テストを対話に使って何を作ればよいかを明らかにできる。 内部の実装している段階で、エッジケースのAcceptance Testのパターンも発見することがあるでしょう。
- 問題（満たすべき仕様）を理解するため
- あとからの異常系は肉付け出来る傾向がある。
- その他テストが期待通り動作していることを確認するため
- 例えば、「コーディング規約が守っているだろうか？」 例えば、「テストコードみて使われ方のAPIが本当に良いだろうか？ Command/Queryの分離の原則からができないだろうか？名前は適切だろうか？」 例えば、「本当に良いだろうか？ テスト対象とのコラボレーション要素数が多すぎないだろうか？」 例えば、「メソッドの長さはどうだろうか？」「引数の数は？」 例えば、「関数型にならい副作用のないメソッドで記述できないだろうか？」 例えば、「数値や二次元配列の基本データ型に執着していないだろうか？」 例えば、「他の人が読んで理解するまでの時間は短いといえるだろうか？」 例えば、「メソッド名やクラス名はわかりやすいだろうか？」
- （おめでとう！）
- （おめでとう！）
- （TDD自体は多数のコードや設計の良し悪しの判断と改善するタイミングは提供するが、良いコードや設計判断の良し悪しについては深く語っていない）
- 2年目の若手が、先輩のPRを読んで参考にしている。 （作業や議論のログが残るってのが、コメントで「ちょめちょめのライブラリーがあるよ。」「○◎気をつけなきゃね」ってのは読んで 「あ、ここは気をつけなきゃ」「っx書くのがスタンダードなんだ」って）
- ヒントは、TDD、Pull Requestのなかに “問題Aは解く価値のある問題？解き方Aは妥当な解き方？”