Pull Request ＆ TDD 入門
•
1 j'aime•3,225 vues
動作するきれいなコードを目指すためにすべきこと。 ・Pull Requestで、プログラミングのスキルアップを！ ・TDDで、動作するきれいなコードを！ 2015年9月15日のセミナー資料。
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Pull Request ＆ TDD 入門
Similaire à Pull Request ＆ TDD 入門 (20)
Plus de ESM SEC
Plus de ESM SEC (20)
Pull Request ＆ TDD 入門
- 1. 永和システムマネジメント TDDコーチ、アジャイルコーチ、プログラマ 家永英治 Pull Request & TDD 入門 〜 動作するきれいなコードを目指そう〜
- 2. 今日のゴール ➤Pull RequestやTDDとはなにかを知る ➤Pull RequestやTDDをはじめるコツを 学ぶ ➤Pull Request & TDD を体感して学ぶ 2
- 3. 目次 ➤導入部の説明 ➤Pull Requestの簡単な説明 ➤ハンズオン ➤ふりかえり と Q&A ➤休憩 ➤TDDの簡単な説明 ➤ハンズオン ➤ふりかえり と Q&A 3
- 4. 自己紹介 ➤家永英治 2003年 永和システムマネジメント入社 2005年頃 エクストリーム・プログラミングを使っ たチーム角谷に参画. 角谷・t-wadaに感銘を受ける 現在は、TDDコーチ、アジャイルコーチ、プログラ マを行っている 4
- 5. 私がTDDを気に入った背景 2005〜 角谷さん 和田さんに XPやTDDについて、実プロジェクトで指導を受ける 角谷さん 和田さんが抜けた後も、リーダーとしてメンテナンスを続ける メンテナンスを続ける中で、TDDやテストの自動化の嬉しさを改めて実感 私でも自信を持ってフィーチャの追加や修正ができる 障害対応も落ち着いて対処できる 2012〜 Scrumコーチとして、安井さん、西村さん、天野さんと現場の導入支援 Scrumのフレームワークのみの限界 開発の進め方自体はスクラムでは言及せず。開発チームに任されている。 が、自力のトライアンドエラーでテスト自動化やリファクタリングを使ってリーダブルコードつくれ る、設計できるようになるまでには時間がかかる TDDコーチ、テスト自動化の初期導入の依頼を受けることも 5
- 6. 私がPull Requestを気に入った背景 20xx 角谷さんが、海外の一部で注目を浴びていた Pull Request を社内に紹介 社内でも実験的に Pull Request を試すチームが現れる。広がる XPのチーム内のコードの共同所有の実現手段だけでなく、 チームを超えてのレビューが行われる。Pull Requestのコラボを通じて、 各々のコードを書く力がUPしていくのを目撃。（これは驚きだった） Pull Requestを見に行けば、開発者がなにをしているかそれとなく分 かる 私も微力ながら Pull Requestを使って、オープンソースへのコミット できることがわかった 2014 Pull Requestを使った社内開発に携わり、良さを改めて実感。 開発のコーチ時に紹介するようになった。 6
- 10. 10
- 12. Pull Request と TDDの 共通の軸
- 15. 15 学びの最大の障害物は “自分は解っている”の思い込み 予期せぬ驚きの発見に注意すること https://www.flickr.com/photos/photohannah/512202109/
- 20. Pull Request
- 21. Pull Request とは？ ➤“プルリクエストは、Bitbucket を使った 開発者のコラボレーションを促進する機 能の 1 つです。使いやすい Web イン ターフェイスで、提案された変更を公式 プロジェクトに統合する前に議論するこ とができます。” https://www.atlassian.com/ja/git/workflows#!pull-request 21
- 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
- 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
- 26. 基本ステップ（Forkを使う場合） ➤ fork ➤ clone ➤ トピックブランチの作成（テスト追加とバグ修正） ➤ 修正,動作確認 ➤ commit ➤ push ➤ Pull Request [GitHub上] ➤ フィードバックコメント [GitHub上] ➤ コメント対応, commit, push (追加修正が必要がなくなるまで） ➤ rebase or merge and push (もし、コンフリクトでMerge できない場合） ➤ Merge[GitHub上] （もし、マージしてOKなら） 26
- 27. 27
- 31. 31 ➤手遅れになる前に、途中段階から素早く コードの書き方や設計判断等のフィード バックもらうため ➤リポジトリにバックアップを残すため ※ ✗ 10日の作業をまとめてプルリク => ○午前中の作業までを プルリク ※ 未完のプルリクは、タイトルに “WIP” や 作業中であることがわかるラベルを 付ける ※１人で解くには問題が難しくもっと早くフィードバックが欲しい場合は、問題や 解き方を紙に描いて他人に話してから開発する、ペアプロやモブプログラミングで 対話しながらつくる代替案も 完成しなくてもプルリクを投げる 設計などで相談に乗って欲しい場合
- 32. TitleやDescriptionを書く プルリクの作成時 32 ➤周囲にどんな作業をしているか知ってもらい フィードバックをもらいやすくするため ➤他人に説明することで、 問題や解き方や要確認事項等の理解を整理するた め (ゴムのアヒルちゃん) ※フォーマットは様々だが、Titleには何をやったのか（やろうとしているか）の要約、Descriptionには リ クエストがなぜ必要とされるかの背景や理由, やったことリスト（ Todoリスト）、Issueやチケット管理等 のリンク, 相談や外部に確認したい項目などなどが記載される
- 33. UIの画像をプルリクに添付する UIありでものをつくる場合、細かなUIイメージが決まっていない場合 33 ➤何をつくるとよいか（問題の定義）の議 論をUIを使って明確にするため ※ 仕事を依頼する人、デザインする人、プログラムを作る人が、プルリクに添付された UI画像を参照しオンライン上で議論し、収束 ※ Gifで動きを見せたり、Before/Afterを見せたり工夫も ※ プルリクのオンライン上ではなくチケットシステムや会議室で収束させる代替案も
- 35. ➤レビューアが読みやすくフィード バックしやすくするため ※ 期待通り動作することを確認してcommit, リファクタリングしてcommit したのをプルリク ※ あとで見直して、問題のあるコードをリファクタリングしてプルリク ※ 問題を解く前に、修正しやすくするためにリファクタのみをテーマにしたプルリクをなげ、そののちに問題を解く プルリクを投げる 35 リファクタリングと問題を解く実装は分ける
- 38. プルリクで略語用語を利用する 38 ➤圧縮してコミュニケーションを成立させるため WIP 作業中 LGTM OK! いいね！（私は問題ないと思うよ） Must 必ず直すべき Nits 細かい指摘 IMO 私の見解では。。。 Fix xxx バグ修正 Cosmetic、Refactor コード整形
- 43. オススメのプルリクの自習・学習 ➤ Github実践入門本を写経 （真似てタイプして著者の追体験する） ➤ 練習、練習、練習 https://github.com/octocat/Spoon-Knife https://github.com/github-book/first-pr ➤ オープンソースのプルリクを覗いてみる ➤ ライブラリの学習でついでにプルリク投げること サブ目標にする （ドキュメントの記述間違いなどは初心者もプルリクしやすい） ➤ 同じチームで社内勉強会を開き、プルリクを試してみる 43
- 45. どんなふうに問題を解く？どうやってつくる？ 45 • 問題を理解する • 解き方を考える • 問題を解いて、ふりかえる • スモール・イズ・ビューティフル • 一つのプログラムには一つのこと をうまくやらせる • できるだけ早く試作を作成する 。。。
- 46. テスト駆動開発とは？ “テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラ ムに必要な各機能について、最初にテストを書き（これをテスト ファーストと言う）、そのテストが動作する必要最低限な実装をとり あえず行った後、コードを洗練させる、という短い工程を繰り返すス タイルである。” -- Wikipediaより 46 http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
- 47. “「動作するきれいなコード」、ロン・ジェフ リーズ のこの簡潔な言葉は、TDD(テスト駆 動開発)の目 標である。動作するきれいなコー ドは、あらゆる 理由で価値がある。 ─ Kent Beck 47
- 48. @t-wada 48
- 49. TDDとフィードバック 49
- 52. [演習2] ➤ FizzBuzz問題の続きをTDDを使っ て解いてみよう。 進め方例 ３の倍数の場合についてをRed Green Refactorリズムで解く。Commit 5の倍数の場合についてをRed Green Refactorリズムで解く。Commit 3と５の倍数の場合についてをRed Green Refactorリズムで解く。Commit 52
- 53. Red Green Refactor ➤テスト書く ➤実行して Red になることを確認 ➤最小の実装 ➤実行して Greenになること確認 ➤リファクタリング 上記を完成するまで繰り返す 53
- 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. 演習３のハードル設定は選択 ✓ ベイビーステップでユニットテストを使って動作確認しながら進める ✓ グリーン時にこまめにリファクタリングする ✓ 先にテストを書く。Red Green Refactorのリズムで解く ✓ 成功時にハイタッチ！する ✓ 小さい単位で コミットしながら進める ✓ GitHub上にリポジトリーを用意する ✓ 小さい単位で プルリクを投げながら進める 例） - テスト込みで isEmpty, size が完成するまでを１つ - push & topが完成するまでを１つ - popが完成するまでを１つ - push の例外が完成するまで１つ - top の例外が完成するまで - 一連のスタックの使い方がわかるテストを追加するまで１つ 55
- 56. 56
- 58. 58 TODO ----- ○誕生 生存 過疎 過密 誕生 Field? Cell -------- row col status 0行 1行 2行 2 列0 列 1列 死んでいるセルに隣接する生きたセルが ちょうど3つあれば、次の世代が誕生する。 1 n
- 59. TODO - 誕生 - 生存 59 ➤解き方のコアとなる骨組みを明らかにす るため （解き方(設計・実装)の学びが得られるTODOはどれだろうか？) ※ 途中で発見した正常系のバリエーションや異常系はTODOに積んで、あとで解く ハッピーパス(正常系)を選択する 一つ目のタスクを選ぶとき
- 60. TODO - 誕生 - 生存 先にテストを書いて失敗を確認する タスクに着手したら 60 ➤ 問題を実行可能なテストで明確にするため （何が実行できたら問題を解いたと言える？） ➤ テスト対象のメソッドの使い方例を明瞭にするため （クラスやメソッドを利用する人はどう使えると嬉しいだろうか？） ➤ テストが期待通り動作していることを確認するため ➤ 後日にまとめてテストでは、テストが記述が難しい実装に なってしまうため (testでassertが書けるように実装するにはどうすればよいだろうか？) ※問題を解く前に問題を明瞭にするのは、問題を解くときのの基本鉄則。テストで表現するのがポイント ※ただしテストファーストに慣れずに手が止まってしまうなら、TDDの制約をゆるめ、“ちょっと実装したら直ぐテストで確認 （つまり何の問題を解いてたのか？をテストで明瞭にしてみよう）”で始めるがオススメ
- 61. TODO - 誕生 - 生存 テスト失敗は基本は１つにする 問題を解いている時 61 ➤一つの問題に集中してとりくむため。 一度に複数の問題を相手して、混乱しないた め (自分が今、集中して解きたい問題は何だろうか？) ※ 誕生を解くことに集中 ※ Ignoreやコメントアウトのほか、テスティングフレーワークの機能を使って特定のメソッドを指定して実行する
- 62. TODO - 誕生 - 生存 62 ➤前提条件(Arrange)、 テスト対象への行為(Act)、 期待結果の表明(Assert)の３つで 問題を整理して理解を深めるため （期待結果はなんだろうか？、操作や前提条件は？） ※ 3Aの整理で迷ったら、まず期待結果の表明(Assert)が何かを明らかにする がオススメ（Assert First） Arrange Act Assertで テストコードを整理する
- 63. TODO - 誕生 - 生存 失敗のレポートを読んで次の一手を考える テスト失敗の時、実装が未完の時 63 ➤エラーメッセージやテストの失敗レ ポートから、次に何をすべきかを把 握できるため (コンピュータは僕に何を教えてくれている？) ※コンピュータと対話しながら問題を解く ※ IDEが使える言語なら、エラー箇所にジャンプやコンパイルエラー時にコード生成機 能を駆使する ※ エラーの意味がわからなければ、Googleや Stack Overflowなどで検索
- 64. TODO - 誕生 - 生存 テストの失敗時のレポートを読みやすくする 失敗が読んでわかりにくい場合 64 ➤自分が今何に取り組もうとしているかの 問題を明瞭にするため ➤後日のテスト失敗時に、他の人が読んで 直ぐ理解して対応できるようにするため ※ たとえばテストのメソッド名を工夫する ※ power-assertも テスト失敗時の内容がわかりやすくするための方法の１つ
- 65. TODO - 誕生 - 生存 65 ➤APIや既存ライブラリの使い方がわか れば問題がより簡単に把握できるよう になるため（巨人の肩にのる！） ※ かわりに REAP(対話シェル環境)を利用して学習するもオススメ テストを使ってライブラリの使い方を学ぶ 知らないAPIやライブラリを学びたい場合
- 66. TODO - 誕生 - 生存 小さな問題に分割して解く レッドからグリーンに遷移させるのに時間がかかり難しい場合 66 ➤分解した小さい問題をクリアできれば、 以前より大きな問題は簡単に解けるよう になるため (2時間以上グリーンを観ていない。もっと小さく問題を分割して解けないだろうか？) ※ TODOリストに追加や順序の入れ替えを忘れずに 一つのプログラムには一つのこ とをうまくやらせる
- 70. TODO - 誕生 - 生存 こまめにリファクタリングする テスト結果がグリーンの時はチャンスタイム！！ 70 ➤あとから自分や他人が読んで直ぐに理解できる ようにするため ➤あとから（予期せぬ）コード修正をできるよう にするため ➤気分すっきり！ ※ レッド時にリファクタリングは、危険な作業 ※ レッド時に発見した修正したい項目は TODOなどに積んで、あとで実施する ※ TDDの文脈では、ベタ書きから一般化もリファクタリングの一つ
- 72. TODO - 誕生 - 生存 72 ➤小さく回すのは「下手な長考休むに似たり」の 代わりに、早く実験して【学び】を得たいから （サイクルの結果、問題や解き方（実装や設計）について学んだことは何だろうか？） ➤言い換えると、問題把握ー＞解決ー＞整理整頓の繰り 返しのリズム （TDDのサイクルの目安は10分だが実際は何分サイクルだろうか？ ） ➤プログラミングの現状の透明性を高めるため （今は問題定義している時？解いている最中？解けた状態？リファクタして壊していない？） Red Green Refactorのリズムで ステップ・バイ・ステップに解く
- 74. TODO - 誕生 - 生存 74 ➤うまくできなかった時に、すぐにセーブ ポイントに戻って、作業を再開できるよ うにするため ※ エディタの戻るや履歴機能の代替案も ※ ブランチで作業して捨てる。あるコミット地点に戻る バージョン管理を使う キリの良い作業単位が終わった時、テストがグリーンの時
- 75. TODO - 誕生 - 生存 75 ➤「当初の計画（解き方A案）がまずかっ た」もTDDサイクルで得た学びの１つ ※ 別の解き方Bを試す ※ 問題Aを問題Bに再設定して、問題と解き方を共にシンプル(解くコストに見合う価値のある。読み やすい。後から修正しやすい…)にできないかも検討する 別の解き方B案に切り替える 当初の計画(解き方A案)に大きな障害物を発見した場合
- 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