プログラムが腐る原因
- 硬さ
- ちょっとした変更でも難しいと思ってしまうような設計
- 最近とあるUI変更で硬さを感じることがあった。そのUIはある型が持っているテキストデータを表示するUIだった。そのUIは変更前の型に依存した実装になっており、そのUIに別の型のデータを入れるという変更が行われ少し苦労した。
- ちょっとした変更でも難しいと思ってしまうような設計
- もろさ
- 変更により別の箇所に問題が生じてしまう。
- 昔数千行のif文によって制御されたスパーモノリシックなjsを管理していた時がこれだった。(そのjsはアプリケーションの全てのページで使用されていた...)
- 変更により別の箇所に問題が生じてしまう。
- 移植性のなさ
- 他のシステムでも使えるが、オリジナルのシステムから切り離すのが困難
- あまり経験がないが、他のアプリでも使用する前提で作成されたUtilityコードがモジュール化されておらず、結局そのアプリでしか使用されていないという場面は見たことがある。
- 他のシステムでも使えるが、オリジナルのシステムから切り離すのが困難
- 扱いにくさ
- ソフトウェアの厚かにくさと開発環境の扱いにくさ。設計構造を保持したまま変更が難しいもの
- ちょっとよくわからなかった。ソフトウェアや開発環境が快適でないことに起因する不都合さ全般のこと?
- ソフトウェアの厚かにくさと開発環境の扱いにくさ。設計構造を保持したまま変更が難しいもの
- 不必要な複雑さ
- 仕様変更を先取りし、不必要な機能を取り入れてしまうようなこと
- これは結構ある。XXXならどうする?XXXは?とコードレビューで指摘されついつい現状の仕様以上の機能を入れてしまうことがある。(正しいこともあるが)
- 仕様変更を先取りし、不必要な機能を取り入れてしまうようなこと
- 不必要な繰り返し
- そのまま
- 不透明さ
- 書き上げた時は理解してても、その後すぐにわからなくなってしまうようなコード
- ほぼこれ
- 書き上げた時は理解してても、その後すぐにわからなくなってしまうようなコード
対策
で、アジャイルチームはこれに対してどう対応するのか
設計をクリーンにシンプルにして、頻繁にテストし変更ができる体制を作り上げておく。 初期の設計は腐ってしまうのはしょうがない!各イテレーションでその時その時最適な設計に作り変えていく。
感想
とにかく最初から大仰な設計をするのではなく、必要に応じて必要な設計を施すのだ!ということが書かれていた。 それはそうなんだけど、なかなか難しいよね...。一度作ったモジュールはなかなか変更許可が降りなかったり、リファクタリング工数が取れなかったりして