Download as PDF, PPTX
レガシーコードとの付き合い方とテストでの話
- 1.
- 2. 自己紹介 • 井芹 洋輝（@goyoki） – 医療機器や自動車の組み込み開発・テスト • 開発屋7割、テスト屋3割 – 最近はコンサルや技術支援に従事 – 社外で各種講演や執筆活動に従事 • 「Androidアプリテスト技法」「テスト自動化標準ガイド（翻訳中）」 「テスト駆動開発／振る舞い駆動開発を始めるための基礎知識」等 • テスト自動化研究会コミッタ、Concolic Testing研究会など 2
- 3. レガシーコードとの付き合い • プログラマとして苦しんだ要因No.1 • 「レガシーコード改善ガイド」との因縁 – 初めてのIT勉強会が原著（WEwLC）読書会 • そこでt_wadaさん達がいて、テストやTDDに染めあげられ、 今のような姿に – 翻訳レビューに協力しました 3
- 4.
- 5.
- 6. アウトライン • レガシーコード対応における 人 • 問題/目標/方針 環境 • 問題/目標/方針 開発のアプローチ • 問題/目標/方針 6
- 7. レガシーコード対応における 「人」 レガシーコードに立ち向かうため のコミュニケーション 7 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 8. 「人」をとりまく問題 • 正しいものは正しく、 間違っているものは間違っている、 と道義を通せる環境は大事 • しかし・・ 8 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 9. 「人」をとりまく問題 9 このコードを書いた●●は本当にクソだ ●●の書いたコードは本当にクソだ 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 10. 「人」をとりまく問題 10 このコードを書いた●●は本当にクソだ ●●の書いたコードは本当にクソだ ●●のせいで本当に大変だ 自分の責任じゃない 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 11. 「人」をとりまく問題 11 このコードを書いた●●は本当にクソだ ●●の書いたコードは本当にクソだ 本当に大変だ 自分の責任じゃない • 保身に走る • 協力しなくなる • 言い訳と見なされる • 適切なサポートを得られない • 地雷原ではリスキーな状態 • 道義を通すにも工夫が必要 レガシーコード 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 12. 「人」について注力が必要な目標 • プロジェクト成功のために必要な 人的サポートを確保する – 役立つ人を敵にせず、役立ってもらう – 状況を理解してもらい、適切なフィードバックを得る 12 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 13. 「人」についての方針 1. コミュニケーションの基礎を作る – 要因をよく把握する – 理解を得るための証拠で武装する – 属人性を排除して問題を共有する 2. 協力を得ながらレガシーコードに 立ち向かう 13 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 14. 「人」についての方針：基礎を作る 要因をよく知る • レガシーコード誕生の要因は一般的に複合的 – テストでの要因： テストベースの問題、進め方やプロセスの問題、 テスト対象の問題、計画・管理の制約 • コミュニケーションの材料確保のため、要因はよく分析し 理解しておく 14 Whyツリー SaPIDの問題構造図 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 15. 「人」についての方針：基礎を作る 理解を得るための証拠で武装する • 「問題や改善の必要性」「改善の効果」の根拠を、 蓄積・共有し、状況を理解してもらう – 一般的なメトリクスの確保 • 眉唾物になりがちだが、レガシーコードでは露骨な異常値がでる • Ex)構造、生産性、不具合の傾向 – 有用な定性的意見の指標化 • Ex)アンケート集計、キーマンからの意見収集 – 実証 • Ex)類似プロジェクト・理想状態との比較検証、フィージビリティ・スタディ 15 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 16. 「人」についての方針：基礎を作る 属人性を排除して問題を共有する 16 • このコードを書いた●●は本当にクソだ • ●●の書いたコードは本当にクソだ 直接の攻撃 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 17. 「人」についての方針：基礎を作る 属人性を排除して問題を共有する 17 • このコードを書いた●●は本当にクソだ • ●●の書いたコードは本当にクソだ • そのコードを書かざるを得なかった状 況や環境は本当に糞だ • そのコードを書いてしまった自分たち のチームは糞だ。改善しなければ 直接の攻撃 制約のせいにする 自分も含めたみんなのせいにする ☓ 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 18. 「人」についての方針 協力を得ながらレガシーコードに立ち向かう • 相談や嘆願でなく改善の提案・担当を – Ex)テスタビリティ改善では、具体的な改善の提 案や、直接の改善を行う • Give&Take – 開発者に対するデバッグ支援、バグ混入防止 活動支援等、直接的に協力する – 開発者に横展開できる改善成果を生み出す • チームとして改善 – チームとして問題共有・改善成果共有を行う 18 属人性の排除 証拠の 武装・展開 要因の理解 基礎 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 19. レガシーコード対応における 「環境」 レガシーコード対応を支える 環境作り 19 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 20.
- 21. 「環境」について注力すべき目標 • 環境による生産性向上のサポートは必須 – レガシーコード対応を支えるツールやプラクティスは すでに様々なものが普及している – 活かさないのは、今や罪 21 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 22. 環境についての方針 • 現代的な開発の前提である三種の神器は レガシーコード対応の大前提 22 バージョン管理 当たり前。説明割愛 自動テスト 当たり前。説明割愛 自動化 当たり前。説明割愛 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 23. 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針 環境についての方針 • テストでも同様 23 テストのバージョン管理 ・当たり前 テストの検証自動化 ・テストのCIをしよう ・テストの品質を評価しよう 各種カバレッジの計測・性能評価 ・テストの妥当性を評価しよう ミューテーションテストや、モデル駆動・ドメイン駆 動で妥当性を評価しよう 各種テスト作業の 自動化 ・テスト設計や実行、保守等、全領域で自動 化しよう
- 24. 環境についての方針 テストの自動生成 24 • レガシーコード対応で有効なアプローチ – テストオラクル問題が深刻にならず、仕組みを作ってしまえば 応用が容易 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針 構造ベース ・制御パス・カバレッジベース、規約ベース、型ベース等 Concolic Tes4ng、構造モデルベーステスト、静的解析との連携、動的解析 仕様ベース ・仕様モデルベース、DSLベース、データ・キーワード駆動等 仕様モデルベーステスト、データ駆動テスト、キーワード駆動テスト 経験ベース ・外部モデルや標準ベース、実使用ベース等 ファジング、キャプチャ＆リプレイ
- 25. レガシーコード対応における 「開発のアプローチ」 レガシーコードに 惑わされないための考え方 25 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 26. 開発のアプローチをとりまく問題 • 行き当たりばったりだとよりカオスに • カオスの解消も難しい・コスパ確保が困難 – なしのつぶて – 全て捨てて作りなおすのも無理 26 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 方針 目標
- 27. 開発のアプローチで実現すべき目標 • “備えてから進む” – 品質リスクに備えてからコードに手を付ける • ミスの流出の防止 – Cover & Modify – レガシーコード本で常識なので割愛 • アプローチの妥当性を確保 – 探索的・実証的（Mikado Method）、フロントローディング的（XDDP等） • ピンポイントの保守性の確保 – Ex)変更ミスを防ぐ変更性の作り込み、リグレッションテストを 作れるようにするテスタビリティ 27 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 28. 開発のアプローチ：保守性の確保の方針 ２つの方向性 • トップダウン – 保守性の要求を体系的に分析し、 計画的に保守性を確保する • リスクやロードマップの分析 • ボトムアップ – 作業上必要な保守性を適用的に確保 • プログラマ主体のCover&Modify • ボーイスカウトルールの実施 – 当たり前なので割愛 28 長期的・大規模・組織的 短期的・適用的・個人 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 29. トップダウンの保守性改善 リスクベースのアプローチ • 品質リスクで保守性対策を優先付けする 29 事象 ダメージ 重大度 発生確率 リスク レベル プロセッサの ディスコン Q:タイミング設計起因の 不具合発生 3 しばしば II プロセッサの ディスコン C:ハードウェア依存部の変更 2 しばしば II ・リスクレベルに応じて保守性対策 を検討する ・リスクを俯瞰して対策を検討する 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 30. トップダウンの保守性改善 リスクベースのアプローチ • 品質リスクで保守性対策を優先付けする 30 事象 ダメージ 重大度 発生確率 リスク レベル プロセッサの ディスコン Q:タイミング設計起因の 不具合発生 3 しばしば II プロセッサの ディスコン C:ハードウェア依存部の変更 2 しばしば II リスク分析の観点 ・構造（コンポーネント、IF） ・制約（スケジュール、メンバー） ・要求（顧客要求、ビジネス状況） ・リスクレベルに応じて保守性対策 を検討する ・リスクを俯瞰して対策を検討する 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 31. トップダウンの保守性改善 リスクベースのアプローチ • 品質リスクで保守性対策を優先付けする 31 事象 ダメージ リスク レベル リスクの軽減策 軽減した リスク レベル プロセッサ のディスコン Q:タイミング設計起 因の不具合発生 II ・動的解析ツールAを 導入。ツールに合わ せてIF追加 II プロセッサ のディスコン C:ハードウェア依存 部の変更 II 変更部分をラッピング し、旧ハードウェア依 存部を一コンポーネ ントに集中させる II 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 32. 開発のアプローチ：保守性の確保の方針 保守性改善手段はいろいろな観点で 32 観点 テストでの保守性改善手段 要求 • テストの要求、テスト設計の根拠を明確化 • 内部品質含めテストの品質要求を識別・定義 設計 • テスト要求からテスト実装まで合理的で 一貫したアプローチを取る • Ex)ゆもつよメソッド、HAYST法等 • 保守性に優れた構造をテスト設計・実装で 実現 実装 • 保守性を支えるプログラミングテクニックの適用 人 問題 目標 方針 環境 問題 目標 方針 アプローチ 問題 目標 方針
- 33. ご清聴ありがとうございました • レガシーコード対応における 人 • 問題/目標/方針 環境 • 問題/目標/方針 開発のアプローチ • 問題/目標/方針 33