こんにちは、とのの（@tonono2587）です。
前回に引き続きCEDEC2019の配信視聴レポです！
今回のテーマ：組織にテストを書く文化を根付かせる戦略と戦術
なんとあの t_wadaさんのお話ー！
タグはこちら #CEDEC2019test
メモ
戦略編
テストがないコードはレガシーコードだ！
■そのような現場での2つの”ならわし”
- テストを書く時間がない
- 動くコードに触れるな
1：テストを書く時間がない について
ここにはよくないループがある
「ストレス」⇔「テスト」
ストレスが増えるとテストも増える、テストが増えるとそのストレスも増える。。。の悪循環
これを、
→「自動テスト」⇔「ストレス」 へ置き換える
そうすると状況の把握ができ、ストレスも減る
技術的負債をへらしていくことができる
★超重要：テストを書く時間がないのではなく、テストを書かないから時間がなくなるのです
2：動くコードに触れるな について
- Edit&Prayには死が待っている
- 動かさないからといっても結局動かなくなる
- 「何もしてないのに壊れた」が問題になる時代から、「何もしてないから壊れる」時代へ。
- 安全に動くコードに触れ続けないと勝てない
- Cover & Modify
文化の醸成について
- 文化の醸成は年単位の事業になる→2年から5年くらいかかる
- 「テストを書く時間がない」のではなく「テストを書かないから時間がなくなる」ことを忘れない
「動くコードに触れるな」と戦う。触れなければ競争力が弱まり、事業は緩やかに死んでいく
レガシーコード改善に正解はない
- テスト自動化は銀の弾丸ではない
- 導入方法にも銀の弾丸はない
- 導入を目的にしてはならない
- 状況は現場によってすべて異なる
■どうしたらよいか？
- ToBeではなく AsIsあずいず とNotToBeからはじめる →一年後にはこれはやっていたくない、をはじめに出す
- 隣の芝は青い。だから気にしないこと
- 人は自分の速度でしか成長できない
- プロジェクトもプロジェクトの速度でしか成長できない
- 「まわりはもうみんなやっていますよ」（日本人にとても効く言葉）は劇薬なので用法用量を守って使うこと
■別の方法：理論武装する
- 不具合の発見が遅れれば遅れるほどコストがかかる（ISTQB？のレポートに結果が出ている）
- リリース後に不具合がみつかると150倍のコストがかかってしまうと言われている
- 不具合の発見をどれだけ前倒しにできるかがカギ
□TDD導入効果（MSとIBMのレポート）
- TDD導入により、不具合が4割くらい減っているという結果
- 一方で、15%から最大35%くらい実装時間は増えている
□エリクソンでの結果
- 不具合18%削減、実装時間は16%増加
- テストカバレッジが大きくなった
□これら被験者のアンケートによると、
- デバッグの工数をへらすと感じた（96%の被験者が）
- 要求が洗練されると感じた（88%）
- コードの品質を上げると感じた（92%：コードが動かなくなる瞬間がわかる、ことを実感）
- 開発工数を減らすと感じた（50%）
→？？？？？
□実装時間が増えているのになんで「全体の開発工数は減る」と感じたのか？
- →デバッグの時間が圧倒的に減ると感じられたから
- TDDによって「自分たちの考えたとおりに動いたコード」になっている
- それどうしをあわせるので、わからないコード同士を合体するよりも圧倒的に予想どおりにもっていくことができる
- 技術的負債（だんだん新機能の開発がかさむし、ダメージが蓄積していくもの）を減らしていく
□では内部の質への「損益分岐点」はどこか？
レポートによると、内部の質への投資は1ヶ月以内に現れる
「テストは品質をあげない」→テストは品質をわかるようにしてくれる、体重計のようなもの
- 「わかる」ことこそ大事
テストを書くだけではよくはならない （体重計にのるだけでは痩せない）
→品質を上げるのは設計とプログラミング！★テストでは品質は上がらないですよ。テストはあくまでも品質を上げるきっかけ。品質を上げるのはプログラミングだけですよ。これは昔から。
戦術編
□テストをあとから書くのは難しいつくりになっている
レガシーコードのジレンマ。。
ここで諦めてしまいがち
→強引にテストを大外からいくか、
→テストがかけるようになるまで内部に手を入れて穴を開けていくか
□参考書籍
『レガシーソフトウェア改善ガイド』
『レガシーコード改善ガイド』
これらの本で言われていること
- リファクタリング （小）
- リアーキテクティング （中）
- ビッグ・リライト（全部かきなおし、変更大）
これらのどこにテストをかいていくか？
□何が一番やばいのか？
→最も困っているところから：お金（決済系とか）、個人情報、・・・
- 新機能開発から
- バグ修正のところから
- 静的解析でピンポイントなところから
□傷んだ箇所と「手が届く果実」
- 難易度
- リスク
- 価値
の3つを軸にして、どこにするかをはかれる
□テストのトリアージ
『リーン開発の現場』という本
| テストケース | リスク | 手動テストのコスト | 自動化コスト |
|---|---|---|---|
| デザイン変更 | 大/小 | 高/低 | 高/低 |
| 新規ユーザー登録 | 大/小 | 高/低 | 高/低 |
| などなど | … | … | … |
それぞれのテストケースに対して、2段階くらいでざっくり仕分け、
そのあとソートすると重要度や優先すべき箇所が見えてくる、判断しやすくなる
□どうテストをかいていくか（自動テストにおけるテスタビリティとは）
- 実行円滑性
- 観測容易性
- 制御容易性
- 分解可能性
Howの部分は『レガシーコード改善ガイド』にかいている！
「こだわらない」ことも重要
- 最初から全部やろうとしない
- テスト駆動にこだわらない
- テストファーストにこだわらない
- 「ユニット」テストにこだわるな
- テストの実行速度にこだわるな
- テストの網羅性にこだわるな
つまり、「自分たちのやり方」でテストの実効性をみていく
★ただしここだけはこだわろう
- 再現、繰り返し可能であること：テストは何回でも、いつでもどこでも動いてほしい
- テストが独立していること：テストは互いに依存関係はつくらない
（A→B→CはだめでB→A→Cの順でしか動かないテストがあっても結局見つからない）
- 設計の可動域を確保するのもポイント
- テストがないということは設計に難があることが多い
- なので実装のテスト（実装にべったりのテスト）を書かないこと
- テストがカバーする範囲に遊びをもたせ、カバー範囲をリファクタリング する
状況に応じてE2Eテストをつかう
自分たちのテストの「サイズ」とその中身を決める＝認識を一致させる
→いちばん小さいテストはここからここまで、大きいテストは…（"ユニットテスト"などの単語に引きずられると認識が各人違って困るから）- 認識をあわせたあと、ミディアムサイズくらいのところから手をつける
まとめ
文化醸成のためにも、、、
- サンプルとデモが大事
- 真似してもらう土台をつくる
- 最初はサンプルのコピペでもよい
- テストのある生活を体験してもらうことが大事
- 次にテストのメンテナンスを学ぶ
たとえば、Cygamesさんの社内ワークショップでのこと →実際のコードを改善してデモをすることで、実感と現実味が！
- できるからやるのではない
- やるからできるようになる
- 自分がかけるようにならなければ、誰もかけるようにならない！！！
まとめと感想
自ら手を動かしてサンプルを体験してもらうこと、
理論武装すること、戦術として早速実践したいと思いました。
この記事も理論武装第一歩であると思いたい…
数分前までは与えられた時間に対してテストし終わるところを目標にしてしまっていました。
測れるかもしれないけれど(それも"時間がなくて"間に合ってないし)、そのあとのことが頭にありませんでした。
これでは品質はあがりません。。設計とプログラミングのためにきっかけを投じつづけるような動き方をしていかないといけないんだ。。！
そう思うと、
- そもそも終わってないところが多すぎて測れてもない →測れるくらい小さい単位を意識して切ってみる
- 同時に、フィードバックが足りてない気がする →見える化して伝えるようにする
このあたりはわたしのできる範囲で手を動かせるのではないかなと思ったりしました。（もうちょっと具体的にしてみよう）
わたしはコードを書かないけれど、戦略も戦術も品質をあげるための考え方としてはとても参考になる刺激的なセッションでした。
お疲れさまでした。
