アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

032

of Mad）」と呼ばれるアンチパターンに陥ってしまいます。これはまさ

にスパゲティコードと言える状態であり、この状態で何らかの仕様変更

に対応しようとすると以下のような事態が生じます。

●

どのプログラムを修正すればよいか特定が難しい

●

複数箇所に同じような修正を加える必要がある

●

修正により副作用が生じて他の部分が壊れてしまう

デグレードをおそれるあまりに既存のコードをコピー＆ペーストで複

製して修正するパッチワーク的な対応を行うと、ますますコードが複雑

化するという悪循環から抜け出せません。

⹅

図1.3.2　

巨大な泥団子

内部品質を高める方針

経験を積んだ開発者であれば、依存関係が絡み合った「悪いコード」

の状態を避けて「良いコード」を書くことができるでしょう。しかし、

プロダクトのコード品質がコードを書く人に依存してしまうのはよくあ

りません。誰がコードを書いたとしても一様に「良いコード」であるこ

033

1

とが担保されて、初めてソフトウェアはアジリティを持つことができる

のです。

変化への対応を容易にすることを目的とし、コードの保守性や拡張性

を確保することでソフトウェアの内部品質を高めるための、一貫した方

針や仕組みが必須となります。それこそがソフトウェアのアーキテク

チャなのです。