「MoMA」を使って.NETアプリをLinuxのMonoに移植してみる：.NET互換性検証ツールレビュー（5/5 ページ）

[Jeff Cogswell，eWEEK]

　理想的な世界であれば、MoMAのようなツールは必要ないはずだ。わたしは完全主義者であろうとするために、一部のプログラマーの怒りを買うことがよくある。完璧なソフトウェアを作成する方法をプログラマーに教えるという目標に関して、わたしはあまりに理想主義的であると批判されてきた。確かに、この業界も大きく進歩した――ユーザーはもう、コマンドプロンプトに暗号めいたコマンドを入力するよう求められることもないし、ソフトウェアハウスは何か問題が起きると、いつもユーザーのせいにするのは、彼らのビジネスに決してメリットにならないことを理解するようになった。

　しかし完全なソフトウェアを作成するという意味には、堅固なソフトウェアを作るということも含まれる。堅固なソフトウェアの作成には、数多くの要素が関係する。例えば、システムコールを1つのライブラリに隔離するといったことだ（少なくとも、WindowsやLinuxでユーザーが求めるGUI指向のユーザーフレンドリーなソフトウェアの場合はそうだ）。優秀な開発者であれば、このようなコードを作成するのはたやすいことだ。もし堅固なソフトウェアデザインという基本原則をうっかり破ってしまったならば、早い段階でそれを修正すべきである。ソフトウェアが完成した後で、いきなり顧客がそれをWindowsからLinuxに移植するよう要求してからでは遅いのだ。

　言い換えれば、ソフトウェアを移植するつもりがなくても、MoMAを実行するまでに、同ツールで指摘されるような問題に対処しておくべきである――Paint.NETの開発者がそうしたように。

　だが、この意見にはただし書きを付ける必要がある。実際のところ、Monoは.NETの完全な移植版ではないのだ。欠落している部分もあり、MoMAのテスト結果には、「Not Implemented」（未実装）の欄のほかに「Missing」（欠落）という欄もある。わたし自身は、いつかソフトウェアを移植しようと思う“かもしれない”という理由だけで.NETフレームワーク独自の機能を使うのを避けるつもりはない。（ちなみに、Mono ProjectではWPF（Windows Presentation Foundation）APIを実装する計画はない。）

　わたしが夢見ている理想世界の話はこれくらいにしておこう。

　おそらく、最善の方法はシステムコールを隔離することであろう（Paint.NETソフトウェアのように）。そうすれば、いつか移植が必要になった場合でも対応できる。それが不可能であれば、移植を求めてはならず、そのソフトウェアを移植できないことを顧客に理解してもらうべきだ。

　結論を言えば、わたしがMoMAツールを使うとすれば、それはソフトウェアを移植することがはっきりしているプロジェクトの場合だけである。その場合、早い段階で、そして何度もテストすることがポイントだ。早い話、何百万行ものコードが含まれるソフトウェアパッケージがすっかり完成した後で、サポートされていない関数への呼び出しが1000カ所もあるのに気付いて喜ぶ人がいるだろうか、ということだ。MoMAを使えば、そういった状況に陥ることはないだろう……少なくとも理想世界では。

原文へのリンク