テストとリファクタリングに関する深い方法論 #wewlc_jp
Upcoming SlideShare
Loading in...5
×
 

テストとリファクタリングに関する深い方法論 #wewlc_jp

on

  • 514 views

レガシーコード改善勉強会 in Yahoo Japan 2014.09.27 ...

レガシーコード改善勉強会 in Yahoo Japan 2014.09.27

プロジェクトに対する方法論構築と、タスクマネジメントについての紹介

後半はMikado Methodの簡易紹介です。

Statistics

Views

Total Views
514
Views on SlideShare
463
Embed Views
51

Actions

Likes
4
Downloads
1
Comments
0

2 Embeds 51

https://twitter.com 38
http://d.hatena.ne.jp 25

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

テストとリファクタリングに関する深い方法論 #wewlc_jp テストとリファクタリングに関する深い方法論 #wewlc_jp Presentation Transcript

  • Dive in Test, Refactoring kyon_mm #wewlc_jp 2014.09.27
  • Self Introduction きょん kyon_mm テストアーキテクト 2年目 TDD/BDD, SCM, Agile, Softwaretest, SoftwareEngineering なごや 基礎勉強会, SCMBC, Nagoya.Testing, Cafe.Testing
  • Attention 今日お話することは、エンジニアであるとい う立場でお話しします。 やらなければいけないことに目がくらんでい るときは、私は今までレールに乗っていただ けだったのだと気づいたときでした。（経験
  • Important things
  • Important things リグレッションしてはいけない 変更にバグはない 保守しやすいことが望ましい ! ただし、バグは変更した部分が原因である事 がほとんどである！！！（←重要
  • Safety 開発チームが出来るのは基本的には次のどち らか Test Formal Method どちらを選んでも限定的でしかないんだけ ど:-p
  • Brownfield Development
  • Wrestle with System
  • Today’s Topic Testing, Analyzing Task Management
  • Process プロジェクトを明確にする部分を扱いやすく する単位,粒度を決める それぞれの粒に適した方法で明確にする プロジェクトを変化させる
  • Example 次の単位でまとめる TestLevel/UserLevel/MaintenanceTerm ViewPoint, Perspective 単位の中で適した方法で明確にする 状態遷移図 マトリックス、テーブル グラフ DSL（ユースケースやシナリオなども含む） 機能配置図 絵
  • Analyzing, Testing
  • Analyzing, Testing 要求、コード、ドキュメントを分析し、明確 することが求められます。 それがユーザからみてバグであるかどうかも 含めて明確にすることが重要です。 コンコリックテスティングなどを用いてテス トケース生成をすることは可能ですが、これ は現状を表現するだけであって、何があるべ き姿であるかは不明のままです。
  • Unit
  • TestLevel/User テストレベル 動作するシステムの粒度で区切る方法 Unit,Component,Integration,System ユーザー 誰が使うかで区切る方法 Developer,Operator,PO,Tester,ActiveUser ,DisinterestUser,Payer,etc,,,
  • MaintenanceTerm 保守する期間 どれくらい保守する必要があるのかで分別 する。いつ不要になったり、変更されるの か。 1日、1週間、1ヶ月、3ヶ月、6ヶ月、未定
  • ViewPoint, Perspective ViewPoint（着眼点） 機能、情報、並行、開発、配置、運用、etc Perspective（横断的関心事） セキュリティ、パフォーマンス、発展性、 etc
  • Quality Model ISO25000シリーズ（品質モデルをかなり抽象 化して標準化したもの） とりあえずこれでシステムが満たすべきも のをグルーピングするといいと思われる。 FQM（NATOが古に開発した品質モデル）
  • Clear
  • FSM… 状態遷移図などを用いてイベントの流れを表 現する。 まぁ、2 bleis 月くらいのプロジェクトだと、 僕はA3用紙40枚くらいの状態遷移図を書いて いたりします。（ミドルウェアの障害まで含 めてシステム全体の状態遷移図を書く）
  • Matrix,Table 組み合わせを表現する ベースはDSLでもいいのだけど、レビューに効 果的なので積極的に採用しています。 デシジョンテーブルとか 直近の1 kyon_mm 月だとだいたい表の行数は20 万行前後くらいあって、そこからいくつかを 選択するようになっている。
  • Unit Meets Clear
  • プロジェクトに最適な表現手段を構築する Developer PO Tester ActiveUser 有効性シナリオシナリオシナリオ テーブル 動画 コンテンツ 快適性レビュー システム 機能完全性DSL テーブル 障害許容性状態遷移図シナリオ 置換性 グラフ DSL 機能配置図機能配置図 グラフ 上記の中身は無作為に近いです（イメージ図です）
  • Do it 表現方法が決まれば、あとは試行錯誤してやっ ていく感じ。 明確にした部分をテストやドキュメントとし て表現する。
  • Testing 仕様に基づくようなテストケース生成方法 デシジョンテーブル グラフ網羅 ドメイン分析 Pair-wise まぁこの辺は自動生成のツールを書けば済む 話なので。
  • Testing テストの実施方法 計画的 探索的
  • Reference システムアーキテクチャ構築の原理 BABOK ISO25000シリーズ REBOK SWEBOK IA100 ソフトウェアテスト技法 第二版 実践的プログラムテスト 基本から学ぶソフトウェアテスト Specification By Example BDD in Action
  • Task Management
  • Task Management WBS Backlog Epic, User Story Todo list Impact Mapping Mikado graph
  • Mikado Graph Mikado Methodという方法論で書くもの とてもシンプルな図です
  • 全体 High WBS, Impact Mapping Midlle Backlog, Epic, UserStory Low Todo List, Mikado Method
  • Mikado Method 他はみなさん知っていると思うので、あまり 知られていないと期待しているMikado-Method について話します。
  • Mikado Graph 達成したい事
  • Mikado Graph 達成したい事 新しい課題 新しい課題
  • Mikado Graph 更に新しい課題 達成したい事 新しい課題 新しい課題 更に新しい課題
  • Mikado Graph 更に新しい課題 達成したい事 新しい課題 新しい課題 更に新しい課題 更に更に…
  • Flow of Mikado Method Mikado Method本を見てみよう！
  • Flow ゴールを書く ナイーブアプローチをとって、見つかった課 題をリーフにする リーフをあげたらコードを捨てる！ リーフを達成するナイーブアプローチをとっ て、、、 成長していったツリーを上から達成していけ ばゴールにたどり着く！！
  • Mikado Graph 達成したい事
  • Mikado Graph 簡単に達成出来そうなコードを書く 達成したい事
  • Mikado Graph 見つかった課題を追加する 達成したい事 新しい課題 新しい課題
  • Mikado Graph 変更したコードを捨てる！ 新しい課題2 git reset —hard hg revert 達成したい事 新しい課題1
  • Mikado Graph 新しい課題1を達成出来そうな簡単な 新しい課題2 コードを書く 達成したい事 新しい課題1
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 見つかった課題を追加する
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 変更したコードを捨てる！ git reset —hard hg revert
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 繰り返して。。。
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 更に新しい課題2 課題が見つからなくなる！
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 更に新しい課題2 最後に着手しているところから、 奇麗にしつつ依存しているものを順に 解決していく
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 更に新しい課題2 更に新しい課題2からやっていくと
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 更に新しい課題2 更に新しい課題1, 2 、新しい課題2を達成した！
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ 達成したものはチェックする！
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ 繰り返す。。。
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ ✔️
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ ✔️ ✔️
  • Mikado Graph 新しい課題2 更に新しい課題1 達成したい事 新しい課題1 ✔️ ✔️更に新しい課題2 ✔️ ✔️ ✔️ 改善達成！！！
  • Features ナイーブアプローチ シンプル 安全 わかりやすい
  • Naive Approach ナイーブアプローチと割り切って最初のコー ドは捨てる！ 探索的に変更したコードは捨てれば安全！ 知るために書いたコードと設計されたコー ドは別！
  • Simple Mikado Graphはシンプルな記法にすること で、開発を妨げない！ Unbeatable Modeling Languageではないん だ！と言っている
  • Safety システムが動作している状態でしかコードへ チェックインされない。 なんとなく動かすためのコードではなく、ボ トムアップで積み上げるため、VCSのリビジョ ンツリーも見やすくなる
  • Communication ビジュアライズされているので、共有しやす い
  • Mikado Method with… レガシーコード改善ガイド Mikado Methodは「試行リファクタリング」 を発展、プロセス化したものです。 リファクタリング
  • Conclusion
  • Conclusion レガシーコード改善には、次が必要になる コードを変更する技術 テスト設計の技術 タスク管理する技術 幅広くやることが、良い結果を生むと私は信 じています。