どうも。

今日はブログラマはプログラムを書くべきではない、という一見矛盾した私のポリシーについて記していきます。

プログラムは量より質

言わずもがなですが、プログラムは当然、「量」よりも「質」が重要視されるものです。長きにわたり保守されていくのが普通ですから、長期間の利用にも耐えうる、運用を考慮した設計にすることは非常に重要です。そこに開発工数を多くかけたとしても、きちんと設計できていれば後々保守コストが大幅に削減されるため、結果的に全体の工数を抑えることができます。また、納品物も拡張性の優れたコードにすることができます。

「量」、すなわちシステムで言うところの「機能」を多くし、様々な顧客の要望に応えることも重要ではありますが、「質」があってこそのものです。「質」が著しく低下している状況のシステムに、さらなる機能追加を行い「量」を増やす行為は、後々の拡張性を捨てる行為に等しく、保守をより困難にする行為に他なりません。

一定以上の「質」を確保した上で、「量（機能）」を増やしていかなければならないのです。

「質」を上げるために、プログラムを書かない

では、「質」を向上させるためには、どうすれば良いか。

答えは簡単です。

多くの人に利用してもらい、多くのコードレビューを受け、それらのフィードバックから多くの適切な修正を行う。そのサイクルを数多く回せばいいのです。

しかし、そうとは言うものの、実際にそれを独自のシステムの細部にわたって実施するのは、困難を極めます。そこで、外部ですでに開発されたモジュールを利用します。

現在では、多くのプログラミング言語で、様々な高機能でかつ再利用可能なモジュールがすでに開発されており、フリーなライセンスで配布されています。これらのモジュールの中で特にメジャーなものは、すでに多くの利用実績があり、様々な開発者のレビューを受け、数多くの修正が行われています。また、新たなバグが発見された場合には、こちら側で修正を行わずとも、多くのプロジェクト参加者が修正・テストを実施しリリースしてくれますので、こちらはバージョンアップされたコードを適用するだけで済みます。

つまり、最大限、外部モジュールを利用する設計にすれば、モジュール間の連携インタフェースや画面を開発するだけで、プログラムを極力書くことなくシステムが完成します。

コード量を極力減らす努力をする

しかしながら、実際の開発現場では、モジュールを利用していたとしても、コードの量が増えてしまう場面が多々存在しています。そういう現場では、「コード量を減らす」ということを考えていないエンジニアが多いように感じます。

例えば、同じ動作をするコードが2種類あったとして、片方が40行、もう片方が60行あったとします。

プログラムは書く時間よりも読む時間の方が多いです。一度書かれたプログラムは、開発や保守などの様々な場面で、他の開発者によって繰り返し読まれます。つまり、40行の方では読むのに10分かかったとすれば、60行の方は単純計算で15分かかることになります。

しかし、読む機会は1度ではありません。長い間、繰り返し機能拡張などをするシステムであれば、数百回読まれることもあるかもしれません。100回読まれれば、5分のロスも500分（8時間20分）になります。

こうしたコード量に対する意識の低いプロジェクトでは、一貫してすべてのファイルを通して、コード量が多くなる傾向にあるため、保守コストの増加は尋常ではありません。

逆を言えば、開発時に正しくリファクタリングしていれば、保守コストを2/3にすることも可能だということです。

再利用してコード量を減らす

さて、ここで疑問になるのが、「どうやってコードの量を減らすのか」ということですが、それは「再利用できる箇所は極力再利用する」、に尽きます。

そもそも、外部モジュールの利用という考え方自体が、再利用の考え方ですが、なぜか、現場では「既に外部から提供されているモジュールは利用するが、自分ではモジュールを作成せずにインラインで記述する」という設計が非常に多いように感じます。外部で開発されたモジュールと同様に、そのプロジェクト独自のモジュールも再利用しやすい形で開発すればいいのに、多くの設計者は「開発工数がかかる」などの理由で、インラインで複数箇所に分散的に記述していきます。

そして、これらの設計者の多くは、オブジェクト指向プログラミングや構造化プログラミングの知識およびそれらの重要性への理解が乏しいです。つまり、「動けばいい」と思っているエンジニアです。決して信用してはなりません。

1機能をモジュール化しておくことで得られるメリットは絶大です。以下のようなメリットが得られます。

• 全体的なコード量が減少する
• 再利用が容易になる
• 機能変更があった場合に、修正箇所が1ヶ所で済む（バージョンアップが容易になる）
• 単体テストが容易になる
• 多くの場面で、理解が容易になる
• 多くの場面で、変数のスコープを適切に配置しやすくなり、メモリ削減になる
• 多くの場面で、内部構造の隠蔽が可能になり、バグを含みにくくなる
• コンパイル言語の場合、分割コンパイルが可能になり、デプロイ期間が短縮される

まとめ

上で述べたような理由から、保守が容易で拡張性が高いコードというのは往々にして記述量が少ないものです。優秀なプログラマーは保守が容易で拡張性が高い設計をしますから、コードの記述量は少ない。すなわち、優秀なプログラマーは、（極力）コードを記述しないのです。最低限のコードで機能するようにします。

そしてそのようなシステムの設計をする際は、オブジェクト指向プログラミング、特に構造化プログラミングへの理解が必須だと考えています。正しく理解して、保守不能なコードをこの世から撲滅させましょう！！

私の業界がWeb系だから、デザイナー上がりの動けばいいや系PHPエンジニアが周りに多く、本当に苦労します。

悪気がないのはわかりますが、さすがに無知は罪だと言わざるをえないです。逆に悪気がない方がタチが悪いです。

心当たりのある方は、気をつけましょうね！