組織にテストを書く文化を根付かせる戦略と戦術

0
-1

Published on

組織にテストを書く文化を根付かせる戦略と戦術
Feb 16, 2016 @ 日本OSS推進フォーラム

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
0
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

組織にテストを書く文化を根付かせる戦略と戦術

  1. 1. 組織にテストを書く 文化を根付かせる 戦略と戦術 和田 卓人 (@t_wada) Feb 16, 2016 @ 日本OSS推進フォーラム
  2. 2. 和田 卓人 id: t-wada @t_wada github: twada
  3. 3. gihyo.jpの連載 『[動画で解説]和田卓人の テスト駆動開発 講座』 http://gihyo.jp/dev/serial/01/tdd/ 全20回すべて動画付き解説 ニコニコ動画でも見れます WEB+DB過去記事の特設サイトと動画も
  4. 4. Do you write tests?
  5. 5. 戦略編
  6. 6. • レガシーコード改善に正解はない • テスト自動化は銀の弾丸ではない • 導入方法にも銀の弾丸はない • 導入を目的にしてはならない • 状況は現場によって全て異なる 銀の弾丸は無い
  7. 7. ストレス テスト
  8. 8. 自動テスト ストレス
  9. 9. テストを書く時間がないので はなく、テストを書かないか ら時間がなくなるのです。 James Grenning
  10. 10. • 文化の醸成は年単位の事業になる • 「テストを書く時間がない」のでは なく「テストを書かないから時間が なくなる」 • 「動くコードに触れるな」と戦う。 触れなければコードは緩やかに死ん でいく 文化を変える
  11. 11. 動くコードに触れなければ死あるのみ
  12. 12. • ToBe ではなく AsIs と NotToBe からはじめる • 隣の芝は青い。気にしないこと • 人は自分の速度でしか成長できない • プロジェクトもプロジェクトの速度でしか成長 できない • 「まわりはもうみんなやっていますよ」は劇薬 なので用法用量を守って使うこと イマココから始める
  13. 13. • 快不快で動く人、損得で動く人 • リファクタリングの快感 • 回帰テストのお得感 • メトリクスの達成感 • そしてビジネス価値 人を知る
  14. 14. • 人はそれぞれの度合いで変化に対して 身構える • 前例がない、事例がない • 「リファクタリングのジレンマ」 • リファクタリングを独立タスクにす ると、そのタスクは着手されない 変えることの難しさ
  15. 15. 事前に許可を得るより、あと で許してもらう方が楽 Grace Hopper It is easier to ask forgiveness than it is to get permission
  16. 16. • 仕様が固まることはない • 開発が終わることはない • 理解は常に深化する • スキルも常に深化する • 技術も常に進化する すべては変化する
  17. 17. 技術的負債の四象限 設計する時間がないん だからしょうがない 今すぐリリースしない といけない。あとでど うにかしよう レイヤー化? なにそ れ? もっとこうすべきだっ たなぁ 無鉄砲 慎重 意図的 不注意 http://bliki-ja.github.io/TechnicalDebtQuadrant/
  18. 18. • 品質が「わかる」ようになる • わかることこそ大事 • 体重計に乗るだけでは痩せない • テストを書くだけでは、良くはならない • 品質を上げるのは設計とプログラミング • 再設計とリファクタリングをテストで支える テストは品質を上げない
  19. 19. 戦術編
  20. 20. • 「何が一番やばいですか?」 • 最も困っているところから • お金、個人情報、…… • 新機能開発から • バグ修正のところから • 静的解析でピンポイントに どこからやるか
  21. 21. • リスク • 手動テストのコスト • 自動化コスト 塹壕からのテスト戦術
  22. 22. • 一度に多くの人を変えるのは難しい • 育てるのではなく、自ら育つように • 教えられる人を増やす • ペアプロで一人ずつ • 若手のホープか、ベテランからか だれとやるか
  23. 23. • 最初から全部やろうとしない • テスト駆動にこだわるな • テストファーストにこだわるな • 「ユニット」テストにこだわるな • テストの実行速度にこだわるな • テストの網羅性にこだわるな こだわるな
  24. 24. • 良いユニットテストの指標にも優先 度がある • 再現、繰り返し可能 (Repeatable) • 独立している (Independent) • 他はそれからでいい こだわろう
  25. 25. • 何はなくとも読むべし • 「仕様化テスト」のススメ • 「絞り込み点」を探す レガシーコード改善ガイド
  26. 26. • 割れ窓理論 • メトリクスを取ろう • カバレッジが低いうちは測定は効果大 • 小うるさいツールを乗りこなす • 分母分子を見ない。時間を追った変化 を見る。傾きを見る。 見える化
  27. 27. • 動的テストと静的テスト • 全体のメトリクスを計測して俯瞰の 視点を得る • 部分的なメトリクスを計測し続けて 傾向を見る • PMD, rubocop, Coverity,… 静的解析を使いこなす
  28. 28. • コードレビューのインフラに投資す る • github, gitlab, gitbucket • WIP pull request • コードを見る文化、見られる文化を 育てる コードレビュー
  29. 29. • テストがないのは既に設計が悪い兆候 • 設計/実装を変えるのが前提 • 実装のテストを書かないこと • テストがカバーする範囲に遊びを持た せ、カバー範囲内をリファクタリング • 状況に応じて E2E テストを使いこなす 設計の可動域を確保する
  30. 30. • サンプルとデモが大事 • 真似してもらう土台を作る • 最初はサンプルのコピペでも良い • テストのある生活を体験してもらう ことが大事 • 次にテストのメンテナンスを学ぶ 背中を見せる
  31. 31. • できるからやるのではない • やるからできるようになる • あなたが書けるようにならなければ、 誰も書けるようにはならない Social Change starts with YOU
  32. 32. テストはプロの嗜み ご清聴ありがとうございました

×