当然といえば当然の話ですが、ホストOS(ドメイン0)をRedhat Enterprise Linux5、クライアントOSをCentOSにて、準仮想化環境で、複数のCentOSを無事に動かすことができました。
Redhatは、基本的にホストOSと同種のOSを稼動させることを推奨しているようですが、CentOSは、もともとRedhat系だしサポートが充実しているので、クライアントOSの選択肢としてはなかなかよいと思っています。
これから、いくつか業務系のJavaアプリを乗せててみて順次評価しようと思っています。
仮想化技術をいろいろと評価してみて、ポイントは、次の点にあるということがなんとなくわかってきました。
1.完全仮想化と準仮想化
2.1ファイルで提供するか、仮想パーティションを使うか
3.既存環境からの移行手順
2008年6月23日月曜日
2008年6月19日木曜日
[リファクタリング]リファクタリングって、どういう時にやるんだろう?
・例
プロジェクト全体の収支は赤字、あわてて作ったのでソフトウエアの内部構造はいまひとつ整理されておらず、部分部分では直したいところがたくさんある。しかし、一応外部仕様を満たすように完成しており、納品検査も合格している状態。
・問題
上記のような状態のプロジェクトと成果物に対して、機能追加・改善をするとします。追加・改善に必要な費用は発注元が出してくれますが、それ以前の赤字があるので、プロジェクトとしてトータルでは赤字です。
さて、この場合、いまひとつ整理されていない内部仕様をどこまでリファクタリングすべきでしょうか?特にある部分のモジュールは、構造がよくない為将来その部分に関連する拡張が発生した場合、その時の開発者は苦労することが予想されます。当然、今従事している技術者は、そうした「よくない部分」を直したいと主張するでしょう。技術者としては当然の気持ちです。
でも、プロジェクトは赤字で追加開発の費用を発注元からもらってもリファクタリング箇所の費用には当てられません。
また、外部仕様は完全に満たしていて、「よくない部分」を直してもお客様から評価される可能性はありません・・・。
1.「よくない部分」を直して、将来このシステムにかかわる人の負担を軽減してあげる
2.「よくない部分」の内、将来の拡張方針が明確に定義でいる箇所だけを直す
3.今回はリファクタリングを一切やらない
どうでしょうか?
プロジェクト全体の収支は赤字、あわてて作ったのでソフトウエアの内部構造はいまひとつ整理されておらず、部分部分では直したいところがたくさんある。しかし、一応外部仕様を満たすように完成しており、納品検査も合格している状態。
・問題
上記のような状態のプロジェクトと成果物に対して、機能追加・改善をするとします。追加・改善に必要な費用は発注元が出してくれますが、それ以前の赤字があるので、プロジェクトとしてトータルでは赤字です。
さて、この場合、いまひとつ整理されていない内部仕様をどこまでリファクタリングすべきでしょうか?特にある部分のモジュールは、構造がよくない為将来その部分に関連する拡張が発生した場合、その時の開発者は苦労することが予想されます。当然、今従事している技術者は、そうした「よくない部分」を直したいと主張するでしょう。技術者としては当然の気持ちです。
でも、プロジェクトは赤字で追加開発の費用を発注元からもらってもリファクタリング箇所の費用には当てられません。
また、外部仕様は完全に満たしていて、「よくない部分」を直してもお客様から評価される可能性はありません・・・。
1.「よくない部分」を直して、将来このシステムにかかわる人の負担を軽減してあげる
2.「よくない部分」の内、将来の拡張方針が明確に定義でいる箇所だけを直す
3.今回はリファクタリングを一切やらない
どうでしょうか?
登録:
投稿 (Atom)