システム開発にアーキテクチャ設計は必須か？【万能ではないが】

他人が書いた汚いコードをメンテするのって嫌ですよね。「なんで、こんなひどいコードになったんだ！？」って驚くコードがたまにあります。

そんな時、よく耳にするのが「最初にアーキテクチャをしっかり設計しておけばよかった」って話です。

アーキテクチャがしっかりしてもコードが荒れる場合はありますが、振り返ってみると、新規開発で自分たちでしっかりとアーキテクチャ設計したシステムのコードはリリース後メンテを繰り返しても割ときれいなコードが保てていた気がします。

そんなわけで、今回は「アーキテクチャ設計」について話してみます。

そもそもアーキテクチャとは？

アーキテクチャには大きく分けて２種類あります。

1. システムアーキテクチャ（インフラアーキテクチャ）
2. アプリケーションアーキテクチャ

１のシステムアーキテクチャは、「Linuxサーバを2台構成でDBはMySQL、WebサーバはApacheでAPサーバはTomcatでプログラミング言語はJavaを使用する」みたいなものです。一言で言えばインフラ設計のことです。

２のアプリケーションアーキテクチャはプログラムをどう作るかです。この記事でいうアーキテクチャはこちらです。

「フレームワークはナニナニを使って、こういうコーディング規約に従って、プログラムを作りましょう！」というものです。

アーキテクチャが決まるとモジュール分けのルールが決まる

メジャーなフレームワークの多くはMVC(Model View Controller)というアーキテクチャを採用しています。プログラムをモデルとビューとコントローラに分けます。

• モデルにはビジネスロジックを実装
• ビューには表示ロジックを実装
• コントローラーにはモデルとビューを制御するロジックを実装

フレームワークを使うとアーキテクチャが決まり、アーキテクチャの規則に従ったコードが自然と書けるようになります。

各モジュールの中の実装は担当するプログラマー次第

フレームワークを使うと、どのモジュールにどのロジックを実装するかが決まりますが、

• 具体的にどんなコードで実装するか？
• どんなアルゴリズムを使って実装するか？
• 変数名にどんな名前を付けるか？

等は担当するプログラマー次第です。

よって、しっかりとアーキテクチャ設計をしても、メンバーのレベル次第では、モジュールの中は汚いコードを書かれる可能性があります。

しかし、経験上初めにしっかりとアーキテクチャを設計したプロジェクトのソースコードは綺麗になっています。なぜそうなるのでしょうか？

『ルール』があることで規律がうまれる

フレームワークを採用してアーキテクチャが決まると、どのモジュールにどのロジックを実装するかが決まり、その規則に沿って開発を進めていきます。モジュール分割に一貫性が生まれます。

そして、その分割したモジュールの中にロジックを書くわけですが、この時にも、ロジックの中に規律を持たせようとする気持ちが無意識に湧いてきます。

「ルールを守り一貫性のあるコードを書こう」という意識があると、ルールが決まっていない部分(モジュールの中)においても、きれいなコードを書こうとする意識が働くようになります。

汚いコードを書く原因は、ただ単にスキルが低いからではなく、「規律のあるコードを書こう！」という意識を持っていないことなんです。

そんなわけで、ぜひアーキテクチャ設計を取り入れてみてください！