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