#blognavi
#blognavi
システムのバージョンアップと改修時の影響範囲、「ストッパー」に関する備忘録。
システムのバージョンアップ時の開発は、
「影響範囲」との闘いである。
「影響範囲」との闘いである。
システムのある1機能に修正を行う場合、
その1機能のみを見ればよいわけではない。
その1機能と連携する他の機能も見る必要がある。
ともすれば、その範囲はシステム全体まで及ぶ場合もあり、
そのため、影響範囲の把握に大変な労力を要する。
（これをサボるとバグが出る。そりゃあもうあっさりと）
その1機能のみを見ればよいわけではない。
その1機能と連携する他の機能も見る必要がある。
ともすれば、その範囲はシステム全体まで及ぶ場合もあり、
そのため、影響範囲の把握に大変な労力を要する。
（これをサボるとバグが出る。そりゃあもうあっさりと）
と、ここでストッパーが登場。
ストッパー。「ドミノ倒しのストッパー」のようなもの。
ストッパー。「ドミノ倒しのストッパー」のようなもの。
各機能間の入出力（インタフェース）の取り決めを
明確にしておくことで、
「今回のこの機能の変更は、インタフェースルールの範囲内だから、
その外側は見なくていいな」
といった判断が可能に（容易に）なる。
「各機能間の入出力（インタフェース）の取り決め」がストッパー。
明確にしておくことで、
「今回のこの機能の変更は、インタフェースルールの範囲内だから、
その外側は見なくていいな」
といった判断が可能に（容易に）なる。
「各機能間の入出力（インタフェース）の取り決め」がストッパー。
改修時に便利ってことは、
バグが起こったときの原因解析も容易になるってこと。
バグが起こったときの原因解析も容易になるってこと。
こういう、システムの機能自体に関係のないものが、
長期間運用されるシステムでは重要になる。
長期間運用されるシステムでは重要になる。
で、
うちのプロジェクトは、そーゆーのがひじょーにずさんである。
哀愁
哀愁
愚痴らない。
少しずつでも直していこう。うん。
少しずつでも直していこう。うん。
カテゴリ: [日記] - &trackback() - 2009年06月15日 00:45:16
