アジャイル設計とは？

設計とは何か？

• ソフトウェアシステム設計の主要なドキュメントはソースコード自身である
• ソースコードの構造を表現するダイアグラムは設計の補助に過ぎず、設計そのものではない

設計がしっかりしていないと何が問題？

• 明確なシステムのイメージを持ってプロジェクトを開始すれば最初はうまくいく
• 運が良ければそのままリリースまで行ける
• ところが時間が経過するにつれ、どんどん保守しづらくなっていく
• そのうち些細な変更でも多大な労力を費やさなければならなくなる
• さらに酷くなると再設計を余儀なくされる
• しかし、こういった再設計はたいてい上手く行かない
• システムは常に変化し続けており、新しい設計もそれに追従しなければならず、至難の業

設計の悪臭 腐敗するソフトウェアの兆候

• 硬さ
  • 変更しにくいシステム。一箇所変更するだけであるにも関わらず、膨大な影響範囲が存在するソフトウェア
• 脆さ
  • 一つの変更によって概念的に関係のない箇所まで影響が及び、その部分を改修しなければ不具合が発生するソフトウェア
• 移植性のなさ
  • 他のシステムでも再利用できる部分をモジュールとして切り離すことが困難なソフトウェア
• 扱いにくさ
  • 本来すべきことよりも逸脱したことを実施するほうが安易なソフトウェア
• 不必要な複雑さ
  • 本質的な意味を持たない構造を内包しているソフトウェア
• 不必要な繰り返し
  • 同じような構造を繰り返し含み、纏められる部分が纏まっていない(DRY原則に則していない)ソフトウェア
• 不透明さ
  • 意図が伝わってこない、何を実施しているのかよくわからないソフトウェア

ソフトウェア腐敗の主な要因

• 最初の設計時点では予想もしなかった仕様変更による劣化
• 最初の設計思想を知らない別の開発者による対応
  • こうした変更が少しずつ重なっていき違反が蓄積され、腐敗してくる

※ソフトウェア開発者ならば・・・

• 設計の劣化を仕様変更のせいにしてはならない
• 仕様は変更されるものであるということは最初からわかっていなければならない
• 最も不確実な要素は仕様だということを認識すべき
• 頻繁に発生する仕様変更が原因で設計は劣化していくのであれば自分たちの設計に問題がある
• 変更に耐えれるようにする設計を見つけ、プロジェクトが腐敗しないようにする

優れたアジャイルチームはソフトウェアの腐敗を許容しない

• 優れたアジャイルチームは変化を喜んで受け入れる
• プロジェクトの初期には殆ど時間を割かない
• 歳月とともに劣化するような初期の設計に時間をかけても無駄
• 代わりにシステム設計を可能な限りクリーン且つシンプルに保つようにする
• できるだけ頻繁にユニットテストや受け入れテストを行うように心がける
• そのようにすることで設計を柔軟且つ変更しやすく保つ
• 優れたアジャイルチームはそういった柔軟性を利用して継続的に設計を改善する

可能な限り美しく設計を保つ

• アジャイル開発者は可能な限り適切且つクリーンに設計を保つことに身を捧げている
• アジャイル開発者の行う「クリーンアップ」は毎日、毎時、場合によっては毎分ソフトウェアを可能な限りクリーン、シンプル且つわかりやすく保つ努力を怠らない
• あとで直すというようなことをせず、腐敗が起こることを許容しない
• ソースコードは設計の最重要な表現形式であるのでクリーンに保たなければならない
• アジャイル開発者としてのプロ精神はコードが腐敗することを決して許さない

まとめ

• アジャイルな設計とは「プロセス(流れ)」や「イベント(事象)」ではなく、ソフトウェアの構造や可読性を向上させるために、原則、パターン、そしてプラクティスを継続的に適用する行為である
  • またそれはシステムの設計を可能な限り、シンプル、クリーン且つわかりやすく保つための献身的な行為である

DRY原則とは？

• Ruby on Railsで採用されているソフトウェアの開発原則
  • Don't Repeat Yourselfの略で「繰り返しを避ける」という意味