Bob Warfield氏は最近のブログの中で、類似製品が提供しているからという理由で、クライアントが当然視しているコンポーネントを構築するために、少なくともコードの70%が記述されており、そうしたコンポーネントの例(source)としてはフォームやUI、データベース接続、メッセージング、データフィード、キャッシュなどがあると論じている。Warfield氏はこうしたコードを「無駄」と見なしているが、その理由は最終製品に何ら競合的差別化をもたらさないからである。
そうしたわけで、ビジネスにとってはどのみち何の違いもないので、陳腐という烙印を押される。Warfield氏はこれを「革新に対する負担（税金）」と呼んでいる。プログラマーは、何度も何度も同じコンポーネント構築用の「メカニズムを再発明し続けて」いるか、ゼロから造り直している。Albert Wenger氏もこの問題を提議しており、Wenger氏が独創的な機能を提供する新しいプラットフォームが必要(source)と考えているのに対し、Warfield氏はコード再利用の促進を提唱している。
そうしたわけで、ビジネスにとってはどのみち何の違いもないので、陳腐という烙印を押される。Warfield氏はこれを「革新に対する負担（税金）」と呼んでいる。プログラマーは、何度も何度も同じコンポーネント構築用の「メカニズムを再発明し続けて」いるか、ゼロから造り直している。Albert Wenger氏もこの問題を提議しており、Wenger氏が独創的な機能を提供する新しいプラットフォームが必要(source)と考えているのに対し、Warfield氏はコード再利用の促進を提唱している。
Warfield氏は、「プログラマーがコードの再利用を嫌うのは、コードを読んで理解するのが嫌だから」と理解している。しかし、これはプログラマーにつきものの特徴というよりも、プログラマーの雇用者が「デベロッパーに学習させる投資をほとんど行わないこと」や、C言語の排他的使用が原因だ、とWarfield氏は主張する。こうした「{ } (中括弧)」はコードの無駄の削減やコード再利用の促進には何の役にも立たないと、Warfield氏は確信している。{ } (中括弧)はUnix構築のために考案されたC言語の派生であり、「オペレーティングシステムなどの最も難しい種類のソフトウェア」を創り出し、「仮説をまったく立てることなく最も詳細レベルの細部に取りかかる」能力をもつことで特徴付けられる、システムプログラミング言語と見なされている。しかし、こうした{ } (中括弧)が普通にアプリケーションソフトの構築に使われている。
では、システムではなく、アプリケーションをプログラムしたい場合、{ } (中括弧)はどうなるのでしょう。[…]ハードウェアと通信できますが、オペレーティングシステムのことはほとんど知らないのです。[…]アプリケーション・フレームワークなしでは、「Hello, World」（皆さん、こんにちは）と表示する以外には、ほとんど何もできません。
こうしたフレームワークは「コードの再利用ができるよう、標準化されている」はずだが、数え切れないほどたくさんあって、習得が難しい。同時に、こうしたフレームワークは、コンポーネントの70%（差別化されていないコンポーネント）を構築するための機能がないため、実は無駄なコードを削減するためのソリューションにはなっていないのである。Albert Wegner氏がさらに感じていることは、現在の業界では「ある役目をまったく念頭に置かずに作られたツールをその役目に使っている(source)」ことだ。Warfield氏によると、コードの無駄を削減し、再利用を向上させるには、「『中括弧はパワーツール』的な考え方をしばし忘れる」必要がある。なぜなら、こうしたツールは「所有による利点」を生み出すようなコンポーネント構築に使われるからである。
もし、コードコンポーネントが再利用されるのであれば、習得の潜在的負担を最小化するような、もっと単純なサービス指向型アプローチを使って「差別化されていない70%の機能性」を構築できるだろう。Warfield氏は実際、OOPよりもSOAの方がコード再利用に役立つと確信している。OOPは「オブジェクトのきめ細かい動作を複雑な方法で制御するもの」であり、多数の事柄を「暗示的に、多くの、いろいろな場所で発生させる」ため、その結果、より分かりにくいコードとなっている。Warfield氏はこの件に関するブログの第２部で、単一の{ } (中括弧)の使用から脱皮する利点(source)について詳しく述べている。
こうした言語はレベルが低すぎます。マルチテナンシーやWebページ、セキュリティ、スケーリング、そしてWeb2.0やSaaSビジネス構築時に直面する無数の問題のどれに対しても、サポートが全然ありません。選択肢は3つあります。「すべてを自分で記述して70%のオーバーヘッドの負担（税金）を負う」、「多言語プログラマーになる」、「その仕事に最適なツールを選び、中括弧のパワーツールは高度な独自仕様の専売作品が必要になるまで仕事場に確実しまっておくことにより、オーバーヘッドを最小限度にとどめる」の3つです。
Warfield氏は、Martin Fowler氏とNiel Ford氏が開発した多言語プログラミング(source)に言及し、Warfield氏から見てすでにこのアプローチを採用したと思われる「抜け目のない企業」の例を挙げている。「独自のコンポーネント・アーキテクチャ・フレームワークもしくはコアテクノロジー」を創り上げたFacebook、Amazon、Googleである。
Googleの言語は実はC++ではなく、MapReduce、BigTable、Google File Systemであると主張する人もいるでしょう。C++は、こうした他のプラットフォームがマッシュアップするモジュールを記述するために使われたアッセンブリコードにすぎません。実際、CやJava、C++を単なるハンディなアッセンブリ言語と考えれば、「なるほど」と思えるのです。
こうしたアプローチを用いれば、企業は「既存資源のずっと大きな部分を、独自の専売的な強みを創り出す方へ集中させる」ことができる、とWarfield氏は信じている。その上、そうした言語不可知論的なアプローチにより、Albert Wenger氏が欲するようなプラットフォーム、つまり、革新に対する負担（税金）を削減するソリューションを提供するプラットフォームをベンダーが構築できるようになり、そのようなプラットフォームは「ゼロから構築されるため、最新のWebサイトやアプリケーションの使用が可能になる」のである。
原文はこちらです：http://www.infoq.com/news/2007/10/reducing-code-waste
原文はこちらです：http://www.infoq.com/news/2007/10/reducing-code-waste