多すぎるコード行に殺される？

Steve Yegge氏は、彼の最新のブログ記事(source)で、開発者コミュニティの神経を逆なでした。ソフトウェア開発において最も重要なのはコードサイズを最小限にしておくことだ、とSteve氏は主張した。彼の視点からみると、コードの行数を少なく保つためにいくつかのデザインパターンを放棄し、リファクタリングを避ける必要がある、と言うのである。さらに、あなたの抱えている問題が非常に大きいなら - 他のプログラミング言語に切り替える必要があるかもしれない、と言っている。

...私は断固として、コードベースにとっての最悪の事態はサイズ (が大きいこと) だと信じています。

Steve氏によれば、コードのサイズは

少数派だとは思いますが、私の意見としては、山のように積み重なったコードは最悪で、人やチーム、そして企業にも襲いかかる、と言うことです。私は、コードの重量がプロジェクトや企業を押しつぶし、一定のサイズになると書きなおす必要が生じ、コードが山にならないようコードベースを保つことに、優秀なチームが全力を注ぐことになる、と信じています。

Steve氏は、それを「コードの肥大化」と呼ぶこともできたが、開発者が肥大化を認識しないことが問題なのであり、一般的な意味での「非本質的な複雑さ」について語っているのではない。

私の考えを表すのに、そこそこ適格だと思える"サイズ"と言う言葉を用いました。私の語彙の中ではより良い言葉が見つかりません。私の意味することをあなた方が理解して、より良い単語を提案してくれるまでは、こうした回りくどい言い方をしなくてはなりません。"肥大化"と言う単語はより正確かもしれません。なぜなら、全ての人が"肥大化"はよくないことだと知っているからです。しかし不幸なことに、いわゆる「経験豊かな」プログラマは肥大化に気づくすべを知らず、凄まじく肥大化したコードベースを指して、「ガリガリに痩せたコードだ」と主張するのです。

このブログエントリの背景には、Steve氏は現在500,000行のコードから成るオンラインゲームをJavaで書いており、そのコードベースのサイズが理由で、もはや彼自身保守できなくなってしまっている、と言う事実がある。少し前に彼はそのゲームの開発をやめ、現在JavaScriptでそのゲームを書きなおしている。

人々がコードベースのサイズについて真剣に語ろうとしないので、私はこの意見を獲得するのに苦労しました: コードベースのサイズは、問題としては広く認識されていません。実際、問題ではないことだと広く認知されています。

しかし、ツールについてはどうだろう？ツールは、コードの管理を容易にはしてくれないのだろうか？

この業界の人間は、大きなコードベースを扱うためのわずかな助けになるような、様々なアイデアに対して非常に興奮を覚えます。例えばコードを"代数構造"として扱えたり、インデックスサーチを行えるIDEなどです。こうした人々はコードベースを、まるで道路工事の作業員が道路の汚れを見るのと同じように見る傾向があります。道路の汚れを取り除くのに、非常に大きなマシンを必要とするのです。

今までのところは、多くの開発者がSteve氏に賛同するだろう。巨大なコードベースにかかわったことのある人々は、コード行それ自体が苦痛を伴うということを知っているからだ。

もし1"ページ" あたり50行だとして、あなたのコードが100万行あったとすると、それは20,000ページにも及ぶコードだということです。20,000ページの導入マニュアルを読むのにどれくらいの時間がかかりますか？単にコードベースを眺めて、全体の構造をつかもうとするだけでも、その密度にもよりますが、数週間から数か月かかります。重要なアーキテクチャの変更を行うには、数か月もしくは数年かかるでしょう。

しかし、多くの開発者よりもSteve氏は過激化する。コードベースを最小にするためには、デザインパターンやリファクタリングを避けるのがよい選択だ、と提案する。

Javaのような言語にリファクタリングを適用することの問題、これこそが今回の主張における本当の中核ですが、それは「リファクタリングはコードを大きくする」と言うことです。私の見積もりでは、今日のIDEがサポートする標準的なリファクタリングのうち、コードを小さくするためのものは5%以下です。

デザインパターンについては、こう書いている。

そしてデザインパターン - 少なくとも、"Gang of Four" の本に書かれたパターンのほとんど - はコードベースをより大きくします。悲劇的にも、コードをより小さくする助けになる唯一のGoFパターン (インタープリタパターン) は、体のいろんな箇所にデザインパターン名のタトゥーを入れているようなプログラマによってさえも、完全に無視されています。

少し前に、InfoQは依存性注入（DI）についての議論を要約(参考記事)した。Steve氏はDIもコード肥大化につながるとしている。

依存性注入は、Javaにおいて人気のある新しいデザインパターンの例ですが、RubyやPython、Perl、そしてJavaScriptを使っているプログラマは恐らく聞いたことがありません。そしてもし聞いたことがあったとしても、恐らく彼らにとっては必要がない、と結論付けるでしょう (それは正しいです)。依存性注入は、Javaをよりダイナミックにするための、驚くほど凝ったインフラですが、それはより高級な言語には本来備わっているものです。そして - 想像してください - DIは、あなたのJavaコードをより大きくしてしまいます。巨大さと言うのは、Java と共に生きるためには必要なものです。コード量の増加が人生の本質です。Javaは、テトリスのようなゲームにおいて、他のピースによって作られた隙間を埋めるピースがない、というのに似ています。あなたにできることは、それらを無限に積み重ねることだけです。

コメント欄で活発な議論が行われている。多くの人は、ライブラリに細かく分割し、全てのコードを理解する必要をなくす、と言うのが最低限の解決策だと考えている。Udi Dahan氏(ブログ・英語)は質問している。

そうした方法であなたのコードを構造化したとして、1,000行以下のコードを一度に見る役には立つでしょう。しかし、50万行では大きな問題になりませんか？

Jay Levitt氏が割り込んでUdi氏に異論を唱え、彼の意味するところを説明するために階層化という言葉を作った。

私の見たところ、ここにはアンチパターンが存在しますが、良い名前がまだ与えられていないようです。私はそれを"階層化"と呼びます。

基本的には、低レベルのライブラリをラップした、ハイレベルなライブラリを書けば書くほど、低レベルのライブラリを使う機会が減ります。従って、あなたがそれを理解する必要も減ります。いくつかの点で、そうした事実を忘れているように見えます。こうした点から言うと、あなたはハイレベルなライブラリの「上に」さらにハイレベルなライブラリを書き、低レベルの機能を再作成することになるでしょう。

サイズは問題なのだろうか？私たちは、非本質的な複雑さは悪であり、取り除くべきだということにはすべて賛成する。しかし、コードが実際にはクリーンでも、依然として大きい場合 - 私たちはそれを受け入れるべきか、それとも、サイズを小さくしておくために、リファクタリングを避けたり、他のプログラミング言語を使用すると言った全く異なる対策を取るべきなのだろうか？サイズはどれくらい重要なのだろうか？

原文はこちらです：http://www.infoq.com/news/2007/12/does-lines-of-code-kill