ソフトウエアクライシス対応 5 I/F重視

システムデザイン、アーキテクチャを確立する時、I/Fを重視した設計を進める。コンポーネントに分けることで、並行開発ができる。場合によってはアウトソーシングもできる。
疎結合であれば、依存度も低く、問題の切り分けがしやすい。

この発想がないと、web2.0的な外部システムのサービスを取り入れたシステムデザインは難しい。一応つながってはいるけどね、キレイじゃないよね。って、システムデザインになる。あとで誰かが苦労する。

オブジェクト指向は、現在のソフトウエアクライシスに対応する中心的な要素になり得る。が、オブジェクト指向でやれば、すべてうまくいくというような、魔法の薬ではない。
この問題を考えていくと、ソフト会社って何？ソフトウエア開発って何？　さらには、ソフトウエアエンジニアリングそのものの議論になっていく。
そのあたりは、きっとアジャイルのメンバーのお歴々が、やっていかれると思うので、お任せしておきたい。

オブジェクト指向の背景として、現代のソフトウエアクライシスに、文字を費やしたが、次は、オブジェクト指向の背景の２つ目として、言語、処理系の歴史を押さえておく。

ソフトウエアクライシス対応 4 フレームワーク

JavaでもPHP5 でも、いいフレームワークが揃ってきている。c++の時代とはずいぶん違う。
使用実績のあるフレームワークを会社に作っておく。蓄積していく。繰り替えし利用することで、毎回テストされ信頼性があがる。
昔でいえば、サブルーチン、プロシージャ、関数の共通化だったが、いわば局所的なパーツの蓄積。その意味では、ずいぶん進歩はしている。

オブジェクト指向の再利用性は、コードにとどまらず、分析、設計にまで及ぶ。経験も必要だが。

新技術は毎日のように出ていて、クライアントは新しいものが魅力的に見える。だか最新ということは、実運用を踏まえた安定性に欠けるということ。バグがあるに違いない。
だが、取り入れなければ、ジリ貧だ。そのリスクを回避しながら、開発することになるが、やはりインクリメンタル開発となる。とにかく、細くてもいいから、ガイドロープを向こう岸にかける。一番最初に、アーキテクチャーのプロト、サンプルコードを書く。
妥当性の検証はしっかりと。
これで、新しいものを取り入れたフレームワークが作れる。