イノベーションの方法 · リーンスタートアップやアジャイル開発との類似 9 リーンスタートアップ アジャイル開発 アジャイルソフトウェア開発(CSAJコラム)
大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder...
-
Upload
yasui-tsutomu -
Category
Software
-
view
1.238 -
download
2
description
Transcript of 大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder...
大きな泥のカタマリを相手にするための
アジャイルと努力と苦労
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
継続可能なアーキテクチャ
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
技術的負債
ウォードカニンガムが作った言葉
実装し続けるだけで新たな理解や学びを反映せずにいると積み上がっていく
長期的なコストや悪影響があり得る
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Sustaining Your Architecture
希望はまだあるテスティング (TDD) リファクタリング 定常的フィードバック パターン 多くの眼で見る
hellip
Good People
技術的卓越への絶えない注力
ふりかえり フェイストゥフェイスで話す
努力と苦労(Diligence and Hard Work)
意欲に満ちた人びとに環境と支援を与える
ところで泥のせいでアジャイルがあるのかもhelliphellip
It Takes a Village(註人が育つのは村全体あってこそのような諺)
Dōmo Arigatōgozaimashita
joerefactorycom
Twitter metayoda
It Takes a Village(註人が育つのは村全体あってこそのような諺)
Dōmo Arigatōgozaimashita
joerefactorycom
Twitter metayoda
Dōmo Arigatōgozaimashita
joerefactorycom
Twitter metayoda