インクリメンタル設計
インクリメンタルな設計 => インクリメンタル => 一定の値、単位や数値を「一ずつ増やしていく」ことの形容
インクリメンタルな設計の場合
最低限必要な機能から「すこしずつ」開発を進め、その過程で設計自体も「すこしずつ」進化させていく
適合するケース => アジャイルな開発
・つくりたいものが決まっていない、わからない
・開発チームが開発対象を十分理解していない
・開発対象が複雑で正しい設計を誰もしらない
#TDDの設計思想/流れ
設計思想
テスト駆動開発 Test Driven Development/TDD
価値
・インクリメンタルな設計を促す
・チームに良いリズムを生む
・開発に自信と信頼をもたらす
原則
・実装する前にテストを書く
・問題を放置せずに少しずつ前進する
・大事なのは完璧さよりも自信を持てること
開発の流れ
TDDの場合、RED(失敗)とGREEN(成功)を繰り返し、Refactor(改造)の工程をへて、再度RED(失敗)に移ります。
1 失敗するテストを書く "CASE Red"
・機能の追加
・条件の追加
・バグの再現
2 テストが成功する最小限のコードを書く "CASE Green"
3 動作を保ったまま設計を洗練させる "CASE Refactor"
プログラミング設計の二つの設計要素
・責任の設計 => 静的な設計
インターフェース
問題を最も単純化できるクラスやメソッドの構成は？
名前
責任の内容を端的に表現するには？
・仕事の正しさの設計 => 動的な設計
振舞い
どんな手順でクラスやメソッドを使って処理をしていくか
事前条件と事後条件
ある事前条件で求められる結果 => 事後条件は何か？？
TDDは初学者こそ学ぶべき、でも、TDD is Dead??
David Heinemeier Hansson said
The test-first part was a wondeful set of training wheels that taught
me how to think about testing at a deeper lebel, but also some I quickly left behind.
テストファーストは自動車の補助輪のようなもので、テスティングをより深いレベルで考えるやり方を教わる
役にはたったが、私はすぐに補助輪を外してしまった。
YAGNI => You ain't gonna need it => 機能は実際に必要になるまでは追加しない方が良い
・きっと後に必要になるだろう => 90%無駄になる
・予測できない事態に伴う変更に対しては、設計を単純にする事で対処できる
・コードを素早く実装するため、バグを減らすための最適な方法 => あまりコードを書かない事である。
・YAGNIとインクリメンタル設計は親和性が高い
静的設計
BowlingGameクラスの責務の決定
・投球ごとの倒したピンの数を記録する
・スコアを計算する
責務を表現するメソッドの命名
・record_shot(pins)とsocre
動的設計
最も簡単なシナリオを考える
・全投球がガターの時にはスコアが0点になる
実際の手順を考える
・全投球がガター: 20回のrecord_shot(0)
・スコアが0点: socreの戻り値をassert_equalで確認
リファクタリング => 機能 = 振る舞いを変えずに設計を改善する事
How to do?? => ExtractMethod = メソッドの抽出/基本のリファクタ手法
リファクタリング/TDD
コードの「不吉な匂い」をきっかけにおこなう
重複したコード
長すぎるメソッド
多すぎる引数
振る舞いを変えずにコードを修正する
設計の向上、劣化の防止
理解しやすくなる
テストコードも対象となる
参考URL