コードを問い合わせ可能なデータ構造に格納すべきか？

作者 Sadek Drobi , 翻訳者 James Neoman 投稿日 2008年7月4日

セクション

プロセス/プラクティス,

デベロップメント,

設計/アーキテクチャ

トピック

Architecture ,

コード分析

タグ

IDEs ,

Visualization

今日のコードを表現するために主に非構造化ファイル(フラットファイル)を使うというやり方は果たして最適だろうか？このパラダイムはもう止めるべきだというRick Minerichのポスト(リンク・英語)に反応して、ブログ界で多くの議論が引き起こされた。

Rickは、非構造化ファイルでコードを表現すると最適な方法でコードを構造化できないとと主張している。プログラマは、ファイル内の関数やクラスの順序やプログラムのフォルダ構成の双方の選択を通じて、コード構成や、意味を表現するアイデアを反映させる。しかし、「いかなる2人のプログラマも、同じようには考えない」、ソースコードに複数のコントリビュータが関わるようになるとすぐに、構造が変更されるようなことになり、ファイル中のコード構造やプログラムのフォルダ構造の各々のレベルで一貫性が失われてしまい、結果として、コード構造とフォルダ構造に矛盾が生じることになりかねない。

例えば、コードのかたまりを切り出し、できるだけ多くのファイルに分割する等、リスクを減らすようなソリューションがあるとしても、Rick Minerichは、こういったソリューションが「非構造化ファイルに括り付けられている」ので、自身が提示した問題に対する部分的な回答にしかならないと考えている。

さらに、場合によっては、「仕事によって順番や意味を変える」のも面白いかもしれないが、別々の仕事ごとに非構造化ファイルで表現されているコードを再編成するようなことはあり得ない。

こういった問題に答えるために、Rickはコード表現への異なるアプローチを提唱している。

抽象データ構造のようなプログラミング言語で交番二進符号(グレイコード)を扱うことができるなら、同様に抽象データ構造でソースそのものを保持することができるのではないでしょうか？プログラムの構造は、リストというよりグラフに似ていないでしょうか？

[…]

我々のコードを問い合わせ可能なデータ構造の形で保持できるなら、我々が選ぶどんなやり方にでも環境を設定するのは簡単です。たとえば、あるメソッドとそれを参照するすべてのものを表示することもできるはずです。コード可視化の可能性は、無限です。

[…]

変更に伴う本当の利益は、我々が自身で選ぶどんなやりかたででもプログラム構造の視覚化することができるようになることから得る力と理解です。

Rickのポストは、多くの反応を引き起こした。Steve HawleyはRickと視点を共有しており、コードへの問合せに基づくアプローチをサポートするためにLINQを使うことを提案している(リンク・英語)。

ある命令行をコンパイルする時、どの変数に影響を与えているかを調べるプロセスは、実はデータベースへ問合せであるということに気がつきました。スコーピングそのものとスコーピングの意味は、どのようにデータベースが構築されたかと同様に問合せの一部です。

さらに、完了したコンパイルの実際のリンクは、それがビルド時に行われるのであろうとラン・タイムで行われるのであろうと、別の問合せです。

コンパイルのプロセスは、実際にはデータベースを構築するプロセスでなければなりません。

しかし、数人のコメンテータは、コードへのそのようなアプローチがすでに存在する(ｒ)という事実に注目した。Keith Braithwaiteが言うには、たとえば、Rick Minerichが言うところの論理的帰結は、SmalltalkやLispにも存在するイメージベースの環境である。Smalltalkに関しては、別のコメンテータがVisual Age Suiteの例を挙げている。Visual Age Suiteでは、「全てのソースコードはコードデータベースに格納されている。［…］そして、自分の好きなやりかたで、コードデータベースに問い合わせができる。」 

しかし、Steve Hawleyと他のブロガー達は、非構造化ファイルを使うことの長所を忘れてはならないと強調している。非構造化ファイルを使うことで、効率的にコードを辿ることができる。なぜなら人間というものは「空間と物の空間的配置をよく理解しており、これを自然に非構造化ファイルに変換できます。」従って人間は、「ファイルの配置にすぐに慣れ、強力な記憶を通じて非常に効率的に非構造化ファイル内を正しい位置へと進むことができます。」 

Redditでの議論の中で、あるコメンテータは、Rick Minerichが考えるところの非構造化ファイルの欠点、すなわち任意の構造は、むしろ利点として考えてもいいのではないかと言っている。コメンテータは、その理由として、構造を定義する際の柔軟性を意味を表現するのに使える(source)からとしている :

演算子の間のスペース数のようなものを、並列的な意味を持っている数行の連続行を、そろえて並べるのに使うことができます。関数の順番付けを使って、なんらかの説明をさせることもできます。みんな、表現力豊かなコードを書くためのツールの使い方に関して極めて創造的になっています。もし、これをできなくしてしまおうとするのなら、それが無い代わりに、それと同じような効果を持ったなにかがあるんだろうと期待します。

Keith Braithwaiteは、非構造化ファイル表現を止めるということは、同時に、テキストエディタやバージョン管理ツールにも別れを告げることになるが、プログラマ達は、まだその準備ができていない(リンク・英語)という事実を喚起させようとしている。別なコメンテータであるJSJは、より大規模なツール群をもってしても、システム側での対応なしに、複数のイメージベースのフォーマットには対応できないし、「ツールを一揃い作れば、プログラミング言語の全てとは言わないまでもほとんどの言語にそれを使える」能力が「非構造化ファイルのとても大きなメリット」であると強調している。

Rick Minerich自身もツールの問題をあげている。それによると非構造化ファイルがまだ使われる理由の一つに、全てのツールが非構造化ファイルを使って構造化したコード用に作られてきたという事実があるとのことだ。たとえば、ほとんどすべてのコンパイラは、プログラムが完成していることを必要とする。Rickは「伝統的なコンパイルやリンクと結びつけられていない言語は、コードを抽象データ構造内に保持する研究に理想的である」と信じており、問合せベースのコードをサポートするためのソリューションとしての第一歩だと言っている。

望ましい第一歩は、データベースでコードの全てを管理することができ、プログラマがビューを構築したり、コードを操作するための問合せをダイナミックに構成できるIDE/エディタだろう。そして、そういった環境では、既存のコンパイラと互換性を維持するために非構造化ファイルを生成することができるだろう。

原文はこちらです：     http://www.infoq.com/news/2008/06/storing-code-in-db

• 次へ >