「Tech Night @Shiodome #6 テスト駆動開発」に参加してきたメモ
- https://techsio.connpass.com/event/72585/
- ソフトバンク社内の勉強会に社外の人も呼んでいるイベントとのこと
組織にテストを書く文化を根付かせる戦略と戦術 - 和田卓人氏
(和田卓人氏(@t_wada)を初めて生で見ました！)
-
色々な本の監修、監訳、翻訳
-
今日はビジネスレベルの話、組織を動かしてくための話
- まわりに影響を及ぼしていくための作戦
スタンド名:ワイルドサバンナ
-
仕事は「流しのペアプロ業」
- いろんな会社でペアプロ
- webdbpress12月号にペアプロ記事を書いた
power-assertの作者
戦略編
- 疲弊しきった現場
- 椅子で寝るスキル
- 荒みきったコード
- 機能拡張を繰り返して、コードの整理をせず、システムの複雑度が増していく
- 爆弾処理のようなリリース 「たぶん動く」という気持ちでリリースする
テスト(テストコード)がないコードはレガシーコード by レガシーコード改善ガイド
- これから書くコードであってもどんな言語でも、テストがなければレガシーコード
- 色々な事情でテストが書かれなかった
2つのならわし
1.テストを書く時間はない
テストを書いた方がいいのはわかっているが書く時間がない とよく言われる
→ ストレスとテストの間の因果関係
→ テストが減るとストレスが増える...ストレスが増えるとテストが減る...
→ テストを先に書くことでストレスが増大させないようにする → 逆のループにする
テストを書く時間がないのではなく、テストを書かないから時間がなくなるのです。 by James Grenning
↑ 一種の心理を付いているパワーワード`
2. 動くコードに触れるな
- 動作確認済なので触れない
- 手を入れる必要がある場合はコピペして別で作成する
- 重複したコードが増えていく...
→「テストすることで、動くコードに手を加えていく。然るべきテストでカバーする」にしたい
文化を変えていく
- 文化の情勢は年単位の事業
- テストを書く時間が無いのは、テストを書かないから
- 動くコードに触れるな、と戦う
- 触れなければうゆるやかにしんでいく
- ビジネス価値を出すコードが書けない
- 皆が納得してテストコードを書くようになるには2年から5年かかる
銀の弾丸はない
イマココから始める
- 人もプロジェクトも組織も自分の速度でしか成長できない
- 日本人を動かすために刺さるキーワード「まわりはもうみんなやっていますよ」
- 用法容量を守って使いましょう
人を知る
- 快不快で動く人、損得で動く人
- きれいなテストコードを書くことができて気持ちがいい
- もうテストを書かなくていいように
理論武装する
テスト駆動開発を導入することについて上層部の説得が難しい(発生しそうだったバグが発生しなくなる → それは保険であって、起こらなかったことへの説明が難しい)
↓ を使う
- 不具合の発見が遅れれば遅れるほどコストがかかる。不具合に気づくのは早いほどコストを制限できる。by ISTQB
- MSやIBMなどのTDD導入効果
- TDDを経験した人にアンケート(Ericsson、他)
- コーディングは16％増えるが、デバッグの時間が減った。
- 96パーセントの被験者がデバッグの工数を減らすと感じた、等
変えることの難しさ
- 人は変化に対して身構える
- 下から改革していくにはどうすればいいか
- 「事前に許可を得るより、あとで許してもらう方が楽」 by grace hopper
テストは品質を上げない
- テストは品質そのものを上げない、品質が「わかる」ようになる
- 体重計に乗るだけでは痩せない
- 品質を上げるのは設計とプログラミング
- 再設計とリファクタリングをテストで支える
- テストは品質を変えるきっかけ。品質をあげるのはプログラミング
戦術編
ここからは現場において実装に近い話
2つの道しるべの本
レガシーコード改善ガイド
- レガシーコードのジレンマ
- コードを変更するためにはテストを整備する必要がある
- 多くの場合、テストを整備するためにはコードを変更する必要がある
- レガシーコードに触る為の語彙と技法を整理した本
- stackoverflowからの被言及数第一位
- 現場で使える
レガシーソフトウェア改善ガイド
売れている本のタイトルに寄せてきた
- レガシーコード改善ガイドよりも抽象度がたかい
- ソフトウェアのリエンジニアリングの３つの選択肢
- リファクタリング
- リアーキテクティング
- ビッグ・リライト
どこからやるか
- もっとも困っているところから
- お金、個人情報...
- 新機能開発から
- バグ修正のところから
- 静的解析でピンポイントで
傷んだ箇所と手が届く果実
- テストケースを一覧にまとめる
- リスクを見積もる どれを自動化するか
- 手動テストのコストを見積もる→自動化テストを見積もる
↑ここは参考になりました。ちょうど、テストの自動化を導入しようと、テストケースの頭から愚直にテスト実装しようとしてしまっていました...
レガシーコード改善の技法
こだわるな
- 最初から全部やろうとしない
- テスト駆動にこだわるな
- テストファーストにこだわるな
- ユニットテストにこだわるな
- 実行速度にこだわるな
- モックを書きすぎてモックをなぞくテストに
- テストの網羅性にこだわるな
- 正常系だけでも意味がある
こだわろう
- 再現、繰り返し可能(prepeatable)
- 独立している(independent)
他はそれからでいい
設計の可動域を確保する
- テストが無いのはすでに設計が悪い兆候
- 設計、実装は変えることが前提
- 実装のテストを書かないこと
- 実装の変光範囲を広くとってテスト E2Eとか。改善可能な領域を広く取っておく
テスト自動化ピラミッドとアンチパターン
最初はゼロベースでつくっていくのでアンチパターンになる(手でのテストの割合が多い)
- test sizes at google
- テストの粒度を大中小でわける
- 大、中、小に分けることで「インテグレーションテストとは...」とかそういう定義に困らない
だれとやるか
- 近く、かつ小さいところから
- ペアプロ
見える化
- 割れ窓理論
- メトリクスをとる
- カバレッジが低いうちは測定は効果大
- 小うるさいツールを使いこなす
分母分子を見ない
カバレッジを筆記試験のように扱うのはやめよう
100%が100点ではない
書かれていないことをカバレッジで計れない
書かれてないコードから不具合が出る
カバレッジは計器の1つ
静的解析を使いこなす
動的テストと静的テスト
全体のメトリクスを計測して俯瞰の視点を見る
PMD rubocop coverity
→うごかさなくてもできるので投資対効果が高い
コードレビュー
- コードレビューという仕組みがあるだけで、コードの質は上がる
- 人に見られる、という意識が生まれるため
- コードを見る文化、見られる文化を育てる
背中を見せる
- サンプル、デモ
social change starts with YOU
- できるからやるのではなく、やるからできるようになる
- あなたが書けるようにならなければ、誰も書けるようにならない
ヤフオク！アプリの実践XP - ヤフー株式会社 山下真一郎氏
- iOS版ヤフオク!開発リーダーの方
- 以前デブサミで似た話をされていた?
1. 課題
- ビルド時間が増加、開発効率が低下
- mac book proの性能良いので20分かかったり
- 不十分な単体テスト → リードタイム増加
2. pivortal labs
- リーンスタートアップとXPの組み合わせた「LEAN XP」の研修を提供している会社
- LEAN なにをつくるか
- XP どうやってつくるか
今日はXPの話
XPとは...
- ソーシャルチェンジ
- 個人の行動を少しずつ変えて、組織を変えていく
- エクストリームプログラミングから引用
価値
- コミュニケーション
- シンプル
- フィードバック
- 勇気
- 尊重
プラクティスをただのプラクティスにしないためのもの
主要プラクティス
3つ抜粋
- ストーリー
- フロントエンドとバックエンドの摺り合わせ、並行開発
- ペアプログラミング
- 一人で複数案件を持たない
- ペアローテーションをすることで属人化を排除
- 技術力の底上げ
- コーディング規約も必要なくなる
- テスト駆動開発
- 失敗するテストを書く → テストを通す → リファクタリングする
導入効果
中規模以下は外注でテストをしているらしい
導入前
- 受入テスト失敗率
- 10%くらい失敗 ※リリース二週間前に結果が出る
- 致命的なバグを残してリリースして、あとから直す
LEAN XP導入プロジェクトはどうか
- テストケース8,000ケースの内失敗11ケース
- 残業時間も減った
- ペアプロは定時までやるとものすごく疲れる
- リーダは定時後にリーダ業務をやる
- エンジニアがプロダクトに自信が持てる
- 心身ともに健康な状態が保たれる
- 自立学習が促進された
- ペアプロは3名から始めて、現在は58名に増えた