大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder...

80
大きな泥のカタマリを 相手にするための アジャイルと努力と苦労 Copyright 2014 Joseph W. Yoder & The Refactory, Inc. XP Matsuri September 6 th , 2014 Joseph W. Yoder -- www.refactory.com www.teamsthatinnovate.com

description

Joe Yoderさんによる、XP祭り2014での講演資料の日本語版です。

Transcript of 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder...

Page 1: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

大きな泥のカタマリを相手にするための

アジャイルと努力と苦労

Copyright 2014 Joseph W Yoder amp The Refactory Inc

XP Matsuri ndash September 6th 2014Joseph W Yoder -- wwwrefactorycom

wwwteamsthatinnovatecom

継続可能なアーキテクチャ

Copyright 2014 Joseph W Yoder amp The Refactory Inc

Joseph W Yoder -- wwwrefactorycom

Sustaining Your Architecture

UIUC SAGから進化した(註UIUC=イリノイ大学アーバナシャンペーン校)

90年代はじめに研究したものオブジェクトフレームワークコンポーネントメタパターンリファクタリング再利用「良い」アーキテクチャ

だがこのSAGの活動で発見したのはいろいろな良いものの話をしてるにも関わらず世の中で成功しているシステムには良い内部構造なんてさっぱりないということだった

Sustaining Your Architecture

利己的なクラスブライアンと僕は『利己的なクラス』とい

う論文を書いたコードの視点からソフトウェアの再利用と進化についてだ

対照的に僕たちのBBoM(Big Ball of Mud=大きな泥のカタマリ)の論文では現実には多くのコードが再利用困難(利用も)になってしまっている点に注目している

Sustaining Your Architecture

大きな泥のカタマリ別名 Shantytown(=写真のスラム街のような都市構造) スパゲッティコード

「大きな泥のカタマリ」は構造が行き当たりばったりでとりとめのないいいかげんな

ガムテープと針金でつないだスパゲッティコードのジャングルのこと標準的ソフトウェアアーキテクチャでもあるなんでやりたいこととやってることにこんなに差があるのか

誰もが高品質なソフトを作りたいのになんで世の中BBoMだらけなのか

Sustaining Your Architecture

泥はどこから来るのか

コードを書くのは人泥を作るのは人

Sustaining Your Architecture

泥はどこから来るのか

やっつけコード

レガシー

都市のスプロール現象

焼き畑式

厳しい締め切り

単に無視する

ソフトウェアテクトニクス(註プレートテクトニクスから)

再構築bull ドラスティックな変化

bull 捨ててしまう

インクリメンタルな変化bull 進化

bull 一歩ずつ大きくなる

Sustaining Your Architecture

動かし続ける一歩ずつ大きくなる

やっつけコード

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 2: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

継続可能なアーキテクチャ

Copyright 2014 Joseph W Yoder amp The Refactory Inc

Joseph W Yoder -- wwwrefactorycom

Sustaining Your Architecture

UIUC SAGから進化した(註UIUC=イリノイ大学アーバナシャンペーン校)

90年代はじめに研究したものオブジェクトフレームワークコンポーネントメタパターンリファクタリング再利用「良い」アーキテクチャ

だがこのSAGの活動で発見したのはいろいろな良いものの話をしてるにも関わらず世の中で成功しているシステムには良い内部構造なんてさっぱりないということだった

Sustaining Your Architecture

利己的なクラスブライアンと僕は『利己的なクラス』とい

う論文を書いたコードの視点からソフトウェアの再利用と進化についてだ

対照的に僕たちのBBoM(Big Ball of Mud=大きな泥のカタマリ)の論文では現実には多くのコードが再利用困難(利用も)になってしまっている点に注目している

Sustaining Your Architecture

大きな泥のカタマリ別名 Shantytown(=写真のスラム街のような都市構造) スパゲッティコード

「大きな泥のカタマリ」は構造が行き当たりばったりでとりとめのないいいかげんな

ガムテープと針金でつないだスパゲッティコードのジャングルのこと標準的ソフトウェアアーキテクチャでもあるなんでやりたいこととやってることにこんなに差があるのか

誰もが高品質なソフトを作りたいのになんで世の中BBoMだらけなのか

Sustaining Your Architecture

泥はどこから来るのか

コードを書くのは人泥を作るのは人

Sustaining Your Architecture

泥はどこから来るのか

やっつけコード

レガシー

都市のスプロール現象

焼き畑式

厳しい締め切り

単に無視する

ソフトウェアテクトニクス(註プレートテクトニクスから)

再構築bull ドラスティックな変化

bull 捨ててしまう

インクリメンタルな変化bull 進化

bull 一歩ずつ大きくなる

Sustaining Your Architecture

動かし続ける一歩ずつ大きくなる

やっつけコード

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 3: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

UIUC SAGから進化した(註UIUC=イリノイ大学アーバナシャンペーン校)

90年代はじめに研究したものオブジェクトフレームワークコンポーネントメタパターンリファクタリング再利用「良い」アーキテクチャ

だがこのSAGの活動で発見したのはいろいろな良いものの話をしてるにも関わらず世の中で成功しているシステムには良い内部構造なんてさっぱりないということだった

Sustaining Your Architecture

利己的なクラスブライアンと僕は『利己的なクラス』とい

う論文を書いたコードの視点からソフトウェアの再利用と進化についてだ

対照的に僕たちのBBoM(Big Ball of Mud=大きな泥のカタマリ)の論文では現実には多くのコードが再利用困難(利用も)になってしまっている点に注目している

Sustaining Your Architecture

大きな泥のカタマリ別名 Shantytown(=写真のスラム街のような都市構造) スパゲッティコード

「大きな泥のカタマリ」は構造が行き当たりばったりでとりとめのないいいかげんな

ガムテープと針金でつないだスパゲッティコードのジャングルのこと標準的ソフトウェアアーキテクチャでもあるなんでやりたいこととやってることにこんなに差があるのか

誰もが高品質なソフトを作りたいのになんで世の中BBoMだらけなのか

Sustaining Your Architecture

泥はどこから来るのか

コードを書くのは人泥を作るのは人

Sustaining Your Architecture

泥はどこから来るのか

やっつけコード

レガシー

都市のスプロール現象

焼き畑式

厳しい締め切り

単に無視する

ソフトウェアテクトニクス(註プレートテクトニクスから)

再構築bull ドラスティックな変化

bull 捨ててしまう

インクリメンタルな変化bull 進化

bull 一歩ずつ大きくなる

Sustaining Your Architecture

動かし続ける一歩ずつ大きくなる

やっつけコード

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 4: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

利己的なクラスブライアンと僕は『利己的なクラス』とい

う論文を書いたコードの視点からソフトウェアの再利用と進化についてだ

対照的に僕たちのBBoM(Big Ball of Mud=大きな泥のカタマリ)の論文では現実には多くのコードが再利用困難(利用も)になってしまっている点に注目している

Sustaining Your Architecture

大きな泥のカタマリ別名 Shantytown(=写真のスラム街のような都市構造) スパゲッティコード

「大きな泥のカタマリ」は構造が行き当たりばったりでとりとめのないいいかげんな

ガムテープと針金でつないだスパゲッティコードのジャングルのこと標準的ソフトウェアアーキテクチャでもあるなんでやりたいこととやってることにこんなに差があるのか

誰もが高品質なソフトを作りたいのになんで世の中BBoMだらけなのか

Sustaining Your Architecture

泥はどこから来るのか

コードを書くのは人泥を作るのは人

Sustaining Your Architecture

泥はどこから来るのか

やっつけコード

レガシー

都市のスプロール現象

焼き畑式

厳しい締め切り

単に無視する

ソフトウェアテクトニクス(註プレートテクトニクスから)

再構築bull ドラスティックな変化

bull 捨ててしまう

インクリメンタルな変化bull 進化

bull 一歩ずつ大きくなる

Sustaining Your Architecture

動かし続ける一歩ずつ大きくなる

やっつけコード

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 5: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

大きな泥のカタマリ別名 Shantytown(=写真のスラム街のような都市構造) スパゲッティコード

「大きな泥のカタマリ」は構造が行き当たりばったりでとりとめのないいいかげんな

ガムテープと針金でつないだスパゲッティコードのジャングルのこと標準的ソフトウェアアーキテクチャでもあるなんでやりたいこととやってることにこんなに差があるのか

誰もが高品質なソフトを作りたいのになんで世の中BBoMだらけなのか

Sustaining Your Architecture

泥はどこから来るのか

コードを書くのは人泥を作るのは人

Sustaining Your Architecture

泥はどこから来るのか

やっつけコード

レガシー

都市のスプロール現象

焼き畑式

厳しい締め切り

単に無視する

ソフトウェアテクトニクス(註プレートテクトニクスから)

再構築bull ドラスティックな変化

bull 捨ててしまう

インクリメンタルな変化bull 進化

bull 一歩ずつ大きくなる

Sustaining Your Architecture

動かし続ける一歩ずつ大きくなる

やっつけコード

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 6: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

泥はどこから来るのか

コードを書くのは人泥を作るのは人

Sustaining Your Architecture

泥はどこから来るのか

やっつけコード

レガシー

都市のスプロール現象

焼き畑式

厳しい締め切り

単に無視する

ソフトウェアテクトニクス(註プレートテクトニクスから)

再構築bull ドラスティックな変化

bull 捨ててしまう

インクリメンタルな変化bull 進化

bull 一歩ずつ大きくなる

Sustaining Your Architecture

動かし続ける一歩ずつ大きくなる

やっつけコード

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 7: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

泥はどこから来るのか

やっつけコード

レガシー

都市のスプロール現象

焼き畑式

厳しい締め切り

単に無視する

ソフトウェアテクトニクス(註プレートテクトニクスから)

再構築bull ドラスティックな変化

bull 捨ててしまう

インクリメンタルな変化bull 進化

bull 一歩ずつ大きくなる

Sustaining Your Architecture

動かし続ける一歩ずつ大きくなる

やっつけコード

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 8: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

動かし続ける一歩ずつ大きくなる

やっつけコード

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 9: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

Copy lsquonrsquo Paste

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 10: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

サンプリング(寄せ集め)

の時代

糊(Glue)の大きなバケツamp

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 11: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

その名前は

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 12: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アジャイルが助けに来た プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおくhellip『アジャイルソフトウェア開発宣言』より

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 13: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アジャイルで助かるのスクラム TDD リファクタリング 定常的フィードバック テスティング 多くの眼で見る

人が大事

技術的卓越への絶えない注力

ふりかえり

フェイストゥフェイスで話す

意欲に満ちた人びとに環境と支援を与える

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 14: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アジャイルな設計における価値

コアの価値

デザインのシンプルさ

コミュニケーション

継続的な改善

信頼とチームワーク

ステークホルダのニーズを満たす

学び続ける

定常的フィードバック

テスティングと確認(validation)をたっぷり

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 15: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アジャイルの神話 どんなときでもシンプルに

要求の変化にも簡単に対応できる(新しい要求でも)

スクラムTDDを使えば良い設計アーキテクチャになる

良いアーキテクチャは「正しい」プラクティスで開発するだけで勝手に発生するそれだけじゃダメなときも

最後の最後に重大なアーキテクチャ変更をする

ldquowwwagilemythscomrdquo

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 16: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アジャイルの原則が悪い設計の一因か事前の設計をしない

終盤でシステムの要求を変える

常にアーキテクチャを進化させる

一歩ずつ育てる

アーキテクチャよりプロセスを大事にする

動くコードが成功の尺度だ

他にもあるはず

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 17: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

Craftsmanship

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 18: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

The Quality Goes In

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 19: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

品質 (Quality)品質の定義特別で本質的な特徴や特性生得

の特徴や属性優秀者の度合いや格付け際だった特質や個性

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 20: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

品質 (誰の視点で見るか)

科学者芸術家

エンジニアデザイナー

重要 つまらない 真 偽

クール クールじゃない

良い 悪い

Rich Gold The Plenitude Creativity Innovation amp Making Stuff

(Simplicity Design Technology Business Life)ldquo

Triggers and Practices ndash Richard Gabriel httpwwwdreamsongscom

アーキテクトが持つ視点は芸術家とデザイナーとエンジニア

ldquoThe Four Winds of

MakingrdquohellipGabriel

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 21: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

ldquo~性rdquo 要求アクセシビリティ

互換性

効率性

有効性

拡張性

保守性

パフォーマンス

信頼性

安全性

スケーラビリティ

機密性(セキュリティ)

安定性

サポート性

使用性

「制約」「品質属性」「サービス要求の品質」などに対応

品質は「~性」で表現され非機能要求とも呼ばれるhelliphellip

いっぽう機能要求がどれだけ正しく実現されたかも品質である(こちらはどう計測するのか)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 22: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

十分であるということ 十分であるという品質

最低限の要求を満たしているか

品質には多くの対立し合うフォースがあるhelliphellipオンライン受注システムとスペース

シャトル制御システムとでは品質は異なり適用すべきパターンとソリューションも異なる

完璧は必要十分の敵

数値化できない品質も敵かも

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 23: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

コードの品質に意味はある上質(quality)なコードを書くためのパターン意図を上手く伝え理解しやすく読むのが快いコードを書くためのパターン

本書は「上質」なコードのパターンである

しかしながらhellipケントベック曰く「hellip本書はある仮定を置いているがそれは脆弱なものだすなわちコードの品質は有意義であるという前提だ私はこれまで醜いコードが大金を産み出している様をたくさん見てきたおかげでビジネスの成功やソフトの普及のためによいコードが必要だとはなかなか信じられなくなっているそれでも私はコードの品質に意味はあると信じている」パターンはバグがより少ないコードを書く助けになるし修正と拡張の役にも立つ

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 24: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

技術的負債

ウォードカニンガムが作った言葉

実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく

長期的なコストや悪影響があり得る

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 25: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

家を掃除する

ジェントリフィケーションリハビリ模様替えをすれば泥をきれいにする役に立つ

リファクタリングパターンフレームワークコンポーネントアジャイルオブジェクト指向は泥掃除の役に立つ

泥防止は可能かそれでアーキテクチャをきれいに保てるか

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 26: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

コードの完全な模様替え

リファクタリングで泥を除去できる

汚れを敷物の下に隠してるだけでは

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 27: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

コードの完全な模様替え

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 28: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

すでにBBoMがある

どう手をつけたらいい

汚い部分を局所化するには

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 29: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

Stuart Brandの「層の分割」(Shearing Layers)建物は多くのコンポーネントでできているがそれぞれは異なる時間軸で変遷する

層 立地構造表面サービス空間設計中身それぞれの層は異なる価値を持ち異なる速度で変化する

建物が適応できるのは速い層(サービス)が遅い層(構造)に邪魔されないため

mdashStuart Brand How Buildings Learn

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 30: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

YoderとFooteによるソフトウェアの層の分割「システムを要素分解し同じスピードで変化するものをまとめるようにする」mdashFoote amp Yoder Ball of

Mud PLoPD4

bull プラットフォーム The platform

bull インフラ Infrastructure

bull データスキーマ Data schema

bull 標準フレームワークコンポーネントサービスStandard frameworks components services

bull 抽象クラスインターフェース Abstract classes and

interfaces

bull クラス Classes

bull コード Code

bull データ Data

層ゆっくり

速い

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 31: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

コードの模様替えリファクタリングで泥を元に戻せる部分もあるトレードオフもあるコスト時間もしかしたらテクノロジーも

リファクタリングから良いデザイン (パターン)へhellip

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 32: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

リファクタリング振る舞いを保持したままプログラムを変更する

bull インスタンス変数の名前変更

bull メソッドをスーパークラスへ引き上げ

bull メソッドをコンポーネントへ

必ず理由に基づいて実施する

リファクタリングはほとんどのアジャイル手法において鍵となる欠かせない要素

TDD

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 33: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

シンプルなリファクタリングの例

Object

Concrete1 Concrete2

Object

Concrete1 Concrete2

NewAbstract

空クラスを作る

Borrwed from Don Roberts The Refactory Inc

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 34: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

複雑なリファクタリングの例

困難なリファクタリングもあるが小さなステップを多数積み重ねれば泥退治に大きな効果を得られる

Borrowed from Don Roberts The Refactory Inc

Array

Matrix

Matrix

MatrixRep

ArrayRep

rep

SparseRep IdentityRep

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 35: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

リファクタリングは

小さなステップの積み重ねで

不吉な臭いを除去し

望ましい設計に到達する

1ステップごとにテストを実行し

すべて動いていることを確認する

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 36: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

テスト必須不吉な臭いがするコードを見つけたらリファクタリングしてきれいにする

テストは安全なリファクタリングの鍵

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 37: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

小さなステップで設計を変化させる

メソッドの抽出

メソッドの移動

ポリモーフィズムによる条件記述の置き換えテスト

テスト

テスト

名前変更

テスト

あるいは

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 38: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

コードの臭い(Code Smell)

コードの臭いはコードのどこかでなにかマズいことが起きている兆候臭いを追跡して問題を発見するケントベック

コードの不吉な臭いはケントベックとマーチンファウラーの書いたエッセイで「リファクタリング既存のコードを安全に改善する」の3章に収録 ---- Wardrsquos Wiki

Have you ever

looked at a piece of

code that doesnt

smell very nice

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 39: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

臭いのキツいワースト101) いい加減なレイアウト

2) デッドコード(実行されないコード)

3) 投げやりな名前

4) コードのコメント

5) コードの重複

6) 特性(feature)の横恋慕

7) 不適切な関係

8) 長すぎるメソッド巨大なクラス

9) 基本データ型への執着長すぎるパラメータリスト

10)スイッチ文条件による複雑化

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 40: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

ダメなフォーマットvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b) bar(x c z)

void bar(int i[] int j int k)

return i[j] = int [k]

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 41: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

デッドコードvoid foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

return

x[c] = d

x[b] = a

y = 5 set y equal to 5

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

used to use bar

might need it again

bar(x c z)

void bar(int i[] int j int k)

bar method returning nothing

if (j gt k)

return k

i[k] = i[j]

if (j == k)

return i[j] = int [k]

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 42: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

レイアウトを直し不要な部分を除去しようコードのフォーマットは一貫性を持って

標準フォーマットに合意する

一貫性を保つためツールを決める

コードベース全体にツールを使う

到達しないコードを除去

無用のコメントは削除

コメントアウトしたコードは削除

到達しないコードは削除

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 43: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

なげやりな名前void foo(int x[] int y int z)

if (z gt y + 1)

int a = x[y] b = y + 1 c = z

while (b lt c)

if (x[b] lt= a) b++ else

int d = x[b] x[b] = x[--c]

x[c] = d

int e = x[--b] x[b] = x[y]

x[y] = e foo(x y b)

foo(x c z)

void quicksort(int array[] int begin int end)

if (end gt begin + 1)

int pivot = array[begin]

l = begin + 1 r = end

while (l lt r)

if (array[l] lt= pivot)

l++

else

swap(amparray[l] amparray[--r])

swap(amparray[--l] amparray[beg])

sort(array begin l)

sort(array r end)

httpdreamsongscomFilesBetterScienceThroughArtpdf

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 44: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

名前を直す名前は意味がないといけない

標準はコミュニケーションの役に立つ― 学んで従おう

標準プロトコル

object ToString() Equals()

ArrayList Contains() Add() AddRange()

Remove() Count RemoveAt()

HashTable Keys ContainsKey()

ContainsValue()

標準の名前付け規則(conventions)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 45: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

重複したコード どんなことでも1回だけにする

コードの重複はシステムの理解もメンテナンスも困難にする

変更も重複する

直す人は全コピーを変えないといけない

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 46: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

コードの重複を直す

どんなことでも1回だけ

コードの重複を直す

同じメソッドをスーパークラスへ引き上げ

同じメソッドを共通のコンポーネントへ移動

長すぎるメソッドを分割

再利用重複するな

DRY 原則

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 47: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

不適切な関係クラスがお互いの実装の詳細に依存するとhelliphellip

密結合なクラス ndash 片方を変更するともう片方も変更しないといけない

クラスの境界の定義が曖昧

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 48: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

特性の横恋慕あるクラスが別のクラスの特性(機能)をたくさん使うとhelliphellip

特性(の一部)が間違ったクラスにいることを意味するhellip メソッドの移動を使う

クラスが密結合になってしまう

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 49: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

スイッチ文あちこちのメソッドに多数のスイッチ文やネストした条件分岐がある

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 50: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

double getSpeed()

switch (_type)

case EUROPEAN

return getBaseSpeed()

case AFRICAN

return getBaseSpeed() -

getLoadFactor()

_numberOfCoconuts

case NORWEGIAN_BLUE

return (_isNailed)

0

getBaseSpeed(_voltage)

throw new RuntimeException

(unreachable)

ポリモーフィズムによる条件記述の置き換えスイッチ文や分岐の代わりにメソッド名で場合分けする(ダブルディスパッチ)

フックメソッドにポリモーフィズムやオーバーライドを使う(新しい場合にも既存コードを変更せず対応できる)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 51: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

リファクタリング いつ使うのか

常にリファクタリングしていればいつやっても安全だし比較的簡単ちゃんとしたテストがあればなおさら

バグを直すとき

新しい機能を追加するとき

リリースの直後

テストのリファクタリングも必要かも

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 52: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

リファクタリングの戦略

拡張 ndashリファクタリング

リファクタリング ndash拡張

デバッグ ndashリファクタリング

リファクタリング ndashデバッグ

理解するためにリファクタリング

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 53: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

リファクタリングが鍵となるレバレッジポイント

リファクタリングは技法としてブルックスの「有望な攻略」(『銀の弾などない』より)の役に立つ (註 銀

の弾の代わりに武器として戦えそうなもの)

作らず買ってくる インターフェースを再構築して商用ソフトウェアが使えるようにする

ソフトウェアを育成せよ構築するな ソフトウェアの育成では再構成が起きる

要求の洗練とラピッドプロトタイピング リファクタリングは設計の探索を支援し変化する顧客ニーズに対応する役にも立つ

偉大な設計者を支援 設計者の道具箱のツールのひとつ

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 54: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

2種類のリファクタリング

デンタルフロスリファクタリング

頻繁小さな変化他のプログラミング作業(日々の健康管理)と一緒

根管治療リファクタリング

稀長引くその間プログラマは他のことをできない(大規模修理)

Emerson Murphy-Hill and Andrew Black in

ldquoRefactoring Tools Fitness for Purposerdquo

httpwebcecspdxedu~blackpublicationsIEEESoftwareRefactpdf

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 55: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

共有の知恵

「ほとんどの場合私はリファクタリングの時間を別に取るのに反対だ私の考えではリファクタリングは時間を取ってやるようなものではないリファクタリングはいつでもやるものだ小さなまとりで (in little

bursts)」mdash Martin Fowler

リファクタリングを日々の業務に組み込む

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 56: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アーキテクチャを持続させる

アーキテクチャを長期に渡って維持するために何ができるだろうか

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 57: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

敷物の下に隠す

隠せば他の場所をきれいにできる(ファサードや他のラッパーパターン)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 58: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

表玄関に敷物を重要なコンポーネントを守る

システムの他の場所をきれいに保つ

グルーコード(Mediator)が役立つこともシステムの他の部分はきれいに保てる(腐敗防止レイヤ ndashエリックエヴァンス)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 59: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

玄関で足を拭いて上がる

別名 隠蔽して無視せよ内部をきれいに保て

Patterns for

Sustaining Architecture

PLoP 2012 Paper

外部システムは信頼しない標準外のインターフェース

アプリケーション結合サービスとアダプター間のやりとりは信頼できるよう設計

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 60: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

玄関で足を拭いて上がる

フィルタリングとクレンジング(洗浄)のシーケンスPlaceOrderインターフェースをきれいに保つ

Protected Components

S1

S2

S3

Sn

AdapterProxyFaccedilade

FrontdoorWrapper

FilteringCleansingSecurity Checks

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 61: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

馬車が通う道を舗装する

別名 繰り返しのタスクを簡単にする繰り返しのコーディングタスクを合理化

単純なサンプルテンプレートスクリプトを作る

コード生成のツールを作る

既存のツールやフレームワークを見つけて導入

フレームワークやランタイム環境を作る

ドメイン固有言語を作る

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 62: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

馬車が通う道を舗装する

Patterns for Sustaining Architecture

PLoP 2012 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 63: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 64: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

継続的インスペクションAsian PLoP 2014 Paper

コードの臭い検出

メトリクス(テストカバレジ循環的複雑度技術的負債大きさhelliphellip)

アプリケーションセキュリティチェック

アーキテクチャへの適合性

できるだけ自動化する

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 65: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アーキテクチャを維持する

アーキテクチャ負債を最小限に 必要な変更を受け入れられるようにする

難しすぎたり時間がかかりすぎたり面倒だったりすることを簡単に

最も反応できるタイミングで判断せよ反応可能な最も遅いタイミングではなく

学んで進化せよ

65システムをユーザーと開発者にとって「住める」ように保つ

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 66: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

維持できるアーキテクチャ

Stewardship(註steward=世話役管財人執事など)

徹底的に付き合う

注意を常に払う

小さなことでもシステムを成長変化適応させるのに悪影響があれば見逃さない

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 67: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アーキテクチャプラクティス技術的負債を減らす

新たな学びをコードに反映する リファクタリング 再設計 やり直す コードをきれいにする

ユニットテスト(機能性)

アーキテクチャ的品質のテスト (パフォーマンス信頼性など)

67

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 68: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アジャイルの価値がアーキテクチャプラクティスを駆動

する 行動するアーキテクチャについて長々と議論しない

新たな知識が獲得できるようなことをする

アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような現実的なシナリオのプロトタイプを作る

アーキテクチャをインクリメンタルに改善する

遅らせてもいいアーキテクチャ上の判断は遅らせる

行動せよ証明して改善せよ

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 69: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

アーキテクチャに十分注意していればこうなる

欠陥は局所化するインターフェースが安定している

一貫性開発者が新機能を追加するのが簡単

新機能が既存のアーキテクチャを「破壊」しない

厄介で触ると大変なので触りたくないと開発者が思うような箇所がほとんどない

新しい機能をインクリメンタルに取り込める

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 70: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Agile Mindset

Be Agile

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 71: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

速い思考 vs 遅い思考(『ファストスロー』)

速く考える 直感に基づく判断バイアス習慣化したパターン感情

遅い思考 推論 論理的思考 熟慮

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 72: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

両方に時間を使おう

遅い思考

ペア作業で選択肢を議論するなぜこのやり方で実装するのがいいのか

スケッチ落書き設計スパイク

速い思考

直感に従う走りながら考える

コーディングテスト手直しを高速に回す(レッドグリーン)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 73: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

品質に関するシナリオとテストをアジャイルプロセスに当てはめる

プロダクトビジョンロードマップ

ステークホルダに提供

機能の受入テスト

バックログを管理し実現する

スプリント計画 スプリント実行

毎日のレビュー

フィードバックを取り込む

重要な品質シナリオを定める

品質シナリオも含む

関連する品質タスクを含める

品質のテスト

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 74: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

要求のEnvisioning

(日週単位)

アーキテクチャのEnvisioning

(日週単位hellip)

イテレーション0 Envisioning

イテレーションモデリング (時間単位)

モデルストーミング (分単位)

高速TDD(時間単位)

イテレーションN開発

すこしモデリングしてたくさんコーディングするどの品質を「スプリント」に

含めるか考える

概念モデリング

どんな品質が重要か

テスト駆動開発は品質を含むべき

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 75: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

品質を向上する他の手法Steve McConnell

httpkevinburkecomkevinthe-best-ways-to-find-bugs-in-your-code

1つの手法では平均40

手法を組み合わせれば90以上の品質が

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 76: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

泥沼を干上がらせるスパゲティコードのジャングルから

脱出することは可能だ

むしろ土地を改造することも可能だ

魔法があるわけではない大切なのは長期的にアーキテクチャにコミットしあなたの領域において品質のよいものを育て改善していくのだ(Refactoring)

ベストプラクティスのパターンが役に立つよ

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 77: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

銀の弾丸銀の弾などない

hellipフレッドブルックス

銀の散弾ならあるかもhellip有望な攻略

よい設計フレームワークパターンアーキテクチャプロセス 組織ツールとサポートリファクタリングGood People

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 78: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Sustaining Your Architecture

希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る

hellip

Good People

技術的卓越への絶えない注力

ふりかえり フェイストゥフェイスで話す

努力と苦労(Diligence and Hard Work)

意欲に満ちた人びとに環境と支援を与える

ところで泥のせいでアジャイルがあるのかもhelliphellip

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 79: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

It Takes a Village(註人が育つのは村全体あってこそのような諺)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda

Page 80: 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)

Dōmo Arigatōgozaimashita

joerefactorycom

Twitter metayoda