レガシーコードとの付き合い方とテストでの話

レガシーコードとの付き合い方

と

テストでの話9/27  レガシーコード改善勉強会  #wewlc_jp

井芹洋輝　@goyoki

1

自己紹介

• 井芹　洋輝（@goyoki）– 医療機器や自動車の組み込み開発・テスト• 開発屋7割、テスト屋3割

– 最近はコンサルや技術支援に従事– 社外で各種講演や執筆活動に従事

•  「Androidアプリテスト技法」「テスト自動化標準ガイド（翻訳中）」「テスト駆動開発／振る舞い駆動開発を始めるための基礎知識」等

•  テスト自動化研究会コミッタ、Concolic  Testing研究会など

2

レガシーコードとの付き合い

• プログラマとして苦しんだ要因No.1•  「レガシーコード改善ガイド」との因縁– 初めてのIT勉強会が原著（WEwLC）読書会• そこでt_wadaさん達がいて、テストやTDDに染めあげられ、今のような姿に

– 翻訳レビューに協力しました

3

今日の話

• 以下についてのドメインに依存しないお話をさせて頂ければと考えています

– 割と汎用的・概念的な考え方– テストでの具体例

4

今日のお話：目的

•  レガシーコード対応で– どのような問題があるか、– 問題に対しどのような目標・方針で対処していくのか

　　について役立てればと考えています

5

アウトライン

•  レガシーコード対応における人

• 問題/目標/方針  

環境

• 問題/目標/方針  

開発のアプローチ

• 問題/目標/方針  

6

レガシーコード対応における

「人」レガシーコードに立ち向かうため

のコミュニケーション

7

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」をとりまく問題

• 正しいものは正しく、間違っているものは間違っている、

と道義を通せる環境は大事

•  しかし・・

8

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」をとりまく問題

9

このコードを書いた●●は本当にクソだ

●●の書いたコードは本当にクソだ

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」をとりまく問題

10

このコードを書いた●●は本当にクソだ

●●の書いたコードは本当にクソだ

●●のせいで本当に大変だ  自分の責任じゃない

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」をとりまく問題

11

このコードを書いた●●は本当にクソだ

●●の書いたコードは本当にクソだ

本当に大変だ  自分の責任じゃない

•  保身に走る  •  協力しなくなる  

•  言い訳と見なされる  •  適切なサポートを得られない

•  地雷原ではリスキーな状態•  道義を通すにも工夫が必要

レガシーコード

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」について注力が必要な目標

• プロジェクト成功のために必要な人的サポートを確保する

– 役立つ人を敵にせず、役立ってもらう– 状況を理解してもらい、適切なフィードバックを得る

12

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」についての方針

1. コミュニケーションの基礎を作る– 要因をよく把握する– 理解を得るための証拠で武装する– 属人性を排除して問題を共有する

2. 協力を得ながらレガシーコードに立ち向かう

13

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」についての方針：基礎を作る要因をよく知る

•  レガシーコード誕生の要因は一般的に複合的– テストでの要因：テストベースの問題、進め方やプロセスの問題、

テスト対象の問題、計画・管理の制約

•  コミュニケーションの材料確保のため、要因はよく分析し理解しておく

14

Whyツリー SaPIDの問題構造図 人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」についての方針：基礎を作る理解を得るための証拠で武装する

•  「問題や改善の必要性」「改善の効果」の根拠を、蓄積・共有し、状況を理解してもらう

– 一般的なメトリクスの確保•  眉唾物になりがちだが、レガシーコードでは露骨な異常値がでる•  Ex)構造、生産性、不具合の傾向

– 有用な定性的意見の指標化•  Ex)アンケート集計、キーマンからの意見収集

– 実証•  Ex)類似プロジェクト・理想状態との比較検証、フィージビリティ・スタディ

15

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」についての方針：基礎を作る属人性を排除して問題を共有する

16

•  このコードを書いた●●は本当にクソだ  •  ●●の書いたコードは本当にクソだ

直接の攻撃

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」についての方針：基礎を作る属人性を排除して問題を共有する

17

•  このコードを書いた●●は本当にクソだ  •  ●●の書いたコードは本当にクソだ

•  そのコードを書かざるを得なかった状況や環境は本当に糞だ

•  そのコードを書いてしまった自分たちのチームは糞だ。改善しなければ

直接の攻撃

制約のせいにする

自分も含めたみんなのせいにする

☓

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「人」についての方針協力を得ながらレガシーコードに立ち向かう

•  相談や嘆願でなく改善の提案・担当を–  Ex)テスタビリティ改善では、具体的な改善の提案や、直接の改善を行う

•  Give&Take– 開発者に対するデバッグ支援、バグ混入防止活動支援等、直接的に協力する

– 開発者に横展開できる改善成果を生み出す

•  チームとして改善– チームとして問題共有・改善成果共有を行う

18

属人性の排除

証拠の  武装・展開

要因の理解

基礎

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

レガシーコード対応における

「環境」レガシーコード対応を支える

環境作り

19

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「環境」をとりまく問題

•  レガシーコード対応では、環境改善による作業効率化が強力に求められる

– 工数は新規開発より大きく削減される– 試行錯誤と立て直しが要求される– そもそも環境に致命的な問題を持つことが珍しくない

20

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

「環境」について注力すべき目標

• 環境による生産性向上のサポートは必須– レガシーコード対応を支えるツールやプラクティスはすでに様々なものが普及している

– 活かさないのは、今や罪

21

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

環境についての方針

• 現代的な開発の前提である三種の神器はレガシーコード対応の大前提

22

バージョン管理 当たり前。説明割愛  自動テスト 当たり前。説明割愛  自動化 当たり前。説明割愛

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

環境についての方針

• テストでも同様

23

テストのバージョン管理 ・当たり前  テストの検証自動化 ・テストのCIをしよう  

・テストの品質を評価しよう  各種カバレッジの計測・性能評価  

・テストの妥当性を評価しよう  ミューテーションテストや、モデル駆動・ドメイン駆動で妥当性を評価しよう  

各種テスト作業の  自動化

・テスト設計や実行、保守等、全領域で自動化しよう

環境についての方針テストの自動生成

24

•  レガシーコード対応で有効なアプローチ– テストオラクル問題が深刻にならず、仕組みを作ってしまえば応用が容易

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

構造ベース ・制御パス・カバレッジベース、規約ベース、型ベース等  Concolic  Tes4ng、構造モデルベーステスト、静的解析との連携、動的解析

仕様ベース ・仕様モデルベース、DSLベース、データ・キーワード駆動等  仕様モデルベーステスト、データ駆動テスト、キーワード駆動テスト

経験ベース ・外部モデルや標準ベース、実使用ベース等  ファジング、キャプチャ＆リプレイ  

レガシーコード対応における

「開発のアプローチ」

レガシーコードに

惑わされないための考え方

25

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

開発のアプローチをとりまく問題

• 行き当たりばったりだとよりカオスに•  カオスの解消も難しい・コスパ確保が困難– なしのつぶて– 全て捨てて作りなおすのも無理

26

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 方針 目標

開発のアプローチで実現すべき目標

•  “備えてから進む”– 品質リスクに備えてからコードに手を付ける• ミスの流出の防止

–  Cover  &  Modify– レガシーコード本で常識なので割愛

• アプローチの妥当性を確保– 探索的・実証的（Mikado  Method）、フロントローディング的（XDDP等）

• ピンポイントの保守性の確保– Ex)変更ミスを防ぐ変更性の作り込み、リグレッションテストを作れるようにするテスタビリティ

27

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

開発のアプローチ：保守性の確保の方針２つの方向性

•  トップダウン– 保守性の要求を体系的に分析し、計画的に保守性を確保する

•  リスクやロードマップの分析

•  ボトムアップ– 作業上必要な保守性を適用的に確保

•  プログラマ主体のCover&Modify•  ボーイスカウトルールの実施

– 当たり前なので割愛

28

長期的・大規模・組織的

短期的・適用的・個人  人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

トップダウンの保守性改善リスクベースのアプローチ

• 品質リスクで保守性対策を優先付けする

29

事象 ダメージ 重大度 発生確率 リスク  レベル

プロセッサのディスコン

Q:タイミング設計起因の  不具合発生

3 しばしば II

プロセッサのディスコン

C:ハードウェア依存部の変更 2 しばしば II

・リスクレベルに応じて保守性対策を検討する  ・リスクを俯瞰して対策を検討する

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

トップダウンの保守性改善リスクベースのアプローチ

• 品質リスクで保守性対策を優先付けする

30

事象 ダメージ 重大度 発生確率 リスク  レベル

プロセッサのディスコン

Q:タイミング設計起因の  不具合発生

3 しばしば II

プロセッサのディスコン

C:ハードウェア依存部の変更 2 しばしば II

リスク分析の観点  ・構造（コンポーネント、IF）  ・制約（スケジュール、メンバー）  ・要求（顧客要求、ビジネス状況）  

・リスクレベルに応じて保守性対策を検討する  ・リスクを俯瞰して対策を検討する

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

トップダウンの保守性改善リスクベースのアプローチ

• 品質リスクで保守性対策を優先付けする

31

事象 ダメージ リスク  レベル

リスクの軽減策 軽減した  リスク  レベル

プロセッサのディスコン

Q:タイミング設計起因の不具合発生

II ・動的解析ツールAを導入。ツールに合わせてIF追加  

II

プロセッサのディスコン

C:ハードウェア依存部の変更

II 変更部分をラッピングし、旧ハードウェア依存部を一コンポーネントに集中させる

II

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

開発のアプローチ：保守性の確保の方針保守性改善手段はいろいろな観点で

32

観点 テストでの保守性改善手段

要求 •  テストの要求、テスト設計の根拠を明確化  •  内部品質含めテストの品質要求を識別・定義

設計 •  テスト要求からテスト実装まで合理的で  一貫したアプローチを取る  •  Ex)ゆもつよメソッド、HAYST法等  

•  保守性に優れた構造をテスト設計・実装で  実現  

実装 •  保守性を支えるプログラミングテクニックの適用

人

問題 目標 方針

環境

問題 目標 方針

アプローチ

問題 目標 方針

ご清聴ありがとうございました

•  レガシーコード対応における人

• 問題/目標/方針  

環境

• 問題/目標/方針  

開発のアプローチ

• 問題/目標/方針  

33