asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

メモ:進化できるとできないの区別

書きなぐり。後でちゃんと議論したい。思いつつままに書いてる。


カウフマンの「自己組織化と進化の論理」を読んでいて感じたこと。

ソフトウェアが進化できるとできないの区別は何か?


新たな要求に対応することが難しくなったとき、いくつかの対処が考えられると思う。一つは、スクラッチで書き直す。もう一つは、再構造化などをする。もう一つは、そのまま難しいけど、要求に対処する。

スクラッチで書き直す場合、ソフトウェア進化だといえるだろうか?

他の二つは違和感はない。


で、感じたのは、すでにある要求を保ちながら進化する必要があるという前提がありそうなこと。

この前提を破ればどうなるだろう? 

追加しながら進化することはできそうなのに、削除して追加というプロセスがあまり聞かないのはなぜだろう?

モジュラリティはこれにどう影響してるんだろう?

モジュラリティが高ければ、容易に追加できるというのはよくきく。容易に削除できるというのもありそうな話。プロダクトラインとかフィーチャー指向プログラミングとかではそういう観点だと思う。


構造の再構築は、少なくとも、機能要求を保ったまま行われる気がする。構造が変われば、構造の性質(保守性や、性能、モジュラリティ)なども影響が受ける気もする。

要求を満たしたまま、進化させようとするのは何故だ?

もし、あるシステムが10の機能要求からなるとしよう。

そのうちの半分の5個の機能要求を分離できたとして、別々に進化はできるだろうか?

いったん全体として進化(成長)してきたら、もう個別に進化はできないのか?

モジュラリティが高ければ、ここのモジュールは、他に影響することなく進化でやすといわれる。もちろん、インタフェースは保つ必要があると思うけど。


機能5個を実現する構造と、その機能5個+5個を実現する構造は異なる?


機能・非機能要求を保ったまま進化しなければならないのは何故だろう?


10つの要求を満たすためにデザインされた構造があるとする。後に、そのうちから一つの要求を削除する必要が出たとする。で、実際に削除する。このとき、構造は、9つの要求に対して最適なデザインといえるだろうか?

もちろん、何が最適なのかを議論する必要があるとは思う。

でも、たとえば、デザインパターンは、初めから適用しまくるべきではなく、状況にあわせて適切に使っていくべき(Refactoring to Patterns)という議論もある。

アルゴリズムが一つの機能要求を表すとしよう。二つのアルゴリズムをサポートするだけなら、Strategyパターンは必要ないかもしれない。10個のアルゴリズムになったら、必要になる。

その後に、8つのアルゴリズムが不要になったとする。Staretegyパターンをアンリファクタリングするだろうか?

さらに、一つのアルゴリズムだけになったら?

よほどドメインを絞っていない限り、ソフトウェアに要求される機能は増えていくと思う(リーマンの法則に書いてたっけ?)。


でも、フルスクラッチで書き直すこともないかもしれない。コアの部分(フレームワークを想像)はコピペできるかもしれないし、末端のユーティリティクラスなんかは、再利用できる可能性がある。

ユーティリティクラスが、独立して進化していけるのは、直接要求を満たしていないからか?


結局モジュラリティの話?

スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/85-a1333c57
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。