～ プログラミングって面白そうと思った方に向けた連載エッセイ ～
プログラム全体をどう構成するか。個々のロジックを組む前に、より広い視点で検討する。ソフトウェアの構造は、建築にならって「アーキテクチャ」と呼ばれる。それを設計する人が「アーキテクト」である。その工程を「方式設計」と呼ぶこともある。
プログラマは、アーキテクトによって設計されたアーキテクチャに従ってプログラムを組む。小さなチームでは、プログラマがアーキテクトを兼ねることも珍しくない。
アーキテクトは、技術者にとって憧れの職種と言ってよいだろう。技術者は職人であり、職人はずっと現場で働きたいものである。組織からは加齢とともに管理職への転身を勧められるが、適性も意欲もついてこない場合が少なくない。アーキテクトは、技術者の上級職と位置づけられる。一般的には報酬も高い。発言力もある。マネージャよりも技術者の尊敬を集めることができる。高度なスキルとバランス感覚、構成力、経験が求められるので、誰もがなれるわけではないし、現状、専門職としてのポストは限られているが、管理者コース以外のキャリアパスとして、今後定着していくことが期待されている。
アーキテクチャ設計で検討する対象は、ミドルウェア、ソフトウェアの枠組み、コーディングスタイル、ネットワーク環境、データベース構成など幅広い。大きな組織では、専門分野ごとにアーキテクトが分業化されることもあるだろう。アーキテクチャはプログラムの基盤となるので、品質や生産性に対する影響は甚大である。規模が大きくなれば、何百人のプログラマがそれに沿って進むことになる。その失敗は取り返しのつかない事態を招くおそれがある。
責任が重大な一方で、もちろん相応のやりがいはある。プログラムの共通基盤を設計するというのは、技術者の腕の見せ所であり、もっとも「おいしい」部分を任されているとも言える。通常、個々のプログラマが担当するのはソフトウェアの一部分であるが、アーキテクチャや、フレームワークと呼ばれる共通の枠組みにおいては、全体像を構築することになる。言わば、小さな世界を作り上げるのである。腕も振るいたくなろう。
美しいアーキテクチャは美しいプログラムの礎となる。だが、アーキテクチャにはプログラムから独立した、それ自体の美しさがある。アーキテクトは美意識の強い人種である。美しさにこだわりを持つ人が多い。また、そうでなくては困る。もちろんその職務に限っての話である。幸運なことに、この美への志向はアーキテクチャの実効性とうまく合致する。最適な方式の選択、均整のとれた部品構成、簡素な実装を促す共通基盤、無駄のない処理の流れ――これらを追求することで、美しいアーキテクチャが構築される。それがプログラムの品質、生産性を支えていくのである。
さあ、美しいアーキテクチャができ上がった。素晴らしい。頑張ったのだから、うっとり自賛するくらいの権利はあるだろう。ただし、いっときである。アーキテクチャは作って終わりではない。プログラミング工程が進めば、想定外のことは必ず起こる。起こりうることはすべて想定しておくのが理想であるが、現実には不可能だし、無駄も多い。最初の決め事は最小限に抑え、必要になってから検討する、という方法論で進められることもある。いずれにしても、アーキテクチャは必要に応じて追加、変更していくものであり、それに耐えうる保守容易性が望まれるのは、プログラム自体と同様である。
序章
第一章 その美の特徴
第二章 見た目と冗長性
第三章 ロジック
第四章 命名
第五章 アーキテクチャ
第六章 リファクタリング
第七章 デザインパターン
第八章 正規化
終章