ほとんどのヨーロッパの大聖堂は、いろいろな時代にわたってさまざまな建築家が建てた部分との間に、構想や建築様式の相違がみられる。
後代の建築家は、様式の変更や好みの違いを反映させるため、それ以前の設計を「改良」したいと思うものだ。
だから、穏やかなノルマン建築の外廊が、高くそびえ立つゴシック様式の本堂と隣接し、互いに主張しあっている。
その結果、神への賛美と同じくらいに建築家の奢りを物語ることになる。
これに反し、ランス大聖堂の統合された建築様式は見事な対照を見せている。見るものは、個々の美しさ同様にそのデザインの見事な調和に心を動かされる。
ガイドブックにあるように、この完全さは八世紀にわたる建築家の自己犠牲によって得られたものであり、全体が統一されたデザインになるよう、彼らはそれぞれ自分のアイデアを犠牲にした。
その結果、そこには神への賛美のみならず、堕落した人間を奢りから救出する神の力が示されることになった。
コンセプトデザインの完全性こそ、システムデザインのもっとも重要な考慮点だと言いたい。
ー Frederick Phillips Brooks, Jr. 人月の神話
ザ・ブックからそのまま出てきたような
ー ポール・エルデシュ
コーディング規則には、次の目的がある。
✓ コンセプトデザインを統一し、コードを読みやすく美しく仕上げる。
趣味で一人書くコードにコーディング規則は不要だ。自分が正しいと思う方法でコードを書けばいいだろう。
しかし、プロがチームでおこなう開発にはコーディング規則が必要だ。
世の中には正しく美しいスタイルやコンセプトがいくつも存在する。しかし、それらが混在してしまっては、もはや正しくもなければ美しくもない。
コンセプトデザインの完全性こそ、システムデザインのもっとも重要な考慮点だと言いたい。
✓ コーディング規則によりコードの共有化の基盤をつくる。
Steve McConnell の「CODE COMPLETE」によれば、プログラムを作成するのに必要な時間には人によって10対1の差がでるそうだ。
もちろん、McConnell の主張は「だから優れたプログラマになろう」ということなのだろう。
しかし物事を裏側から眺めれば、たとえ最高のプログラマであっても最低のプログラマの10倍程度の生産性しか出せないことになる。
個の力を高めるのは言うまでもなく重要だ。しかし、一人でできることには限界がある。時間は有限のリソースだ。
コードの共有化による集合知の構築を目指そう。
✓ コードを読むとき、内容・本質に重点を置くことができる。
コーディング規則は、コードの内容・本質については何も語らない。
コードの内容・本質ではなく、コードを書く上で検討が必要になる識別子の命名規則やレイアウト規則、コメントの書き方などディテールを説明する。
こうしたディテールの一つ一つを規則化・パターン化しておくことで、プログラマはコードの内容・本質に集中できるようになる。
