top / index / prev / next / target / source

2007-09-03 diary: 望ましいソフトウェアの構造 , Java言語について思うこと

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

望ましいソフトウェアの構造 , Java言語について思うこと

ふと 望ましいソフトウェア構造などを 徒然に書いてみました。

望ましいソフトウェアの構造: コンピュータシステム開発の本質

ふと 望ましいソフトウェア構造などを 徒然に書いてみました。現在 一気に書き下ろした状態なので、あまり一貫性や論理性は無いかも知れません。後日ふりかえって添削するかも知れません。

保守運用をするコンピュータシステムと保守運用をしないコンピュータシステム

世の中のコンピュータシステムには、保守運用をおこなう場合と 保守運用をおこなわない場合とがあります。対象システムが いずれに該当するのかを抜きに望ましいソフトウェア構造を論じることは出来ません。

もし 保守運用を伴わない 作りっぱなしシステムなのであれば、作る工程そのものの生産性が目標の中心になります。手早く さっさと作るための 様々な仕組みや支援ツールが求められることでしょう。

もし 保守運用を伴う 5年から 10年、あるいは もっと長い年月の間、保守し続ける必要があるシステムであれば、作る工程そのものの生産性は あまり目標の中心とはなりません。むしろ 保守しやすいかどうか、ドキュメントは揃っているかどうか、それら長い年月の間 保守に耐えうるシステム基盤であるのかどうか、などが目標の中心となります。異なる種類のOSや異なるバージョンのOSの上で動くことなど要素についても重要です。

開発者本人が 保守運用をし続けるかどうか

保守を伴う コンピュータシステム開発には、プログラム開発者とプログラム保守運用者とが一致する場合と 一致しない場合とがあります。プログラム開発者とプログラム保守運用者が一致するかどうかによって、コンピュータシステムの望ましいソフトウェア構造は変わります。この前提条件抜きに望ましいデザインは論じるべきではありません。

プログラム開発者が 5年から10年 あるいはもっと長い年月の間、自らが開発したコンピュータシステムをプログラム保守運用し続けるという条件があるのであれば、プログラム開発者が好みのソフトウェア構造を設計して製造すればそれで ほとんど問題ないことでしょう。

もし、プログラム開発者は コンピュータシステムを開発してしばらくしていなくなり、別のプログラマーが 5年から10年 あるいはもっと長い年月の間、他人の開発したコンピュータシステムをプログラム保守運用し続けるという条件があるのであれば、プログラム開発者は好みのソフトウェア構造を設計して製造してはなりません。ソフトウェア構造はプログラム保守運用を担当する人間が考える、あるいは 想定される平均的なプログラム保守運用担当者に適したものを作らなくてはなりません。

もし、どうしても自らの好みのデザインを実装したいのであれば、プログラム保守運用も自分で担当することを申し出るべきです。その責任と決意が無いのであれば、想定される平均的なプログラム保守運用担当者に適したデザインを採用すべきです。

対象となるコンピュータシステムの規模が大きく 製造期間が短い場合は、どうしても開発者本人は 保守運用をし続けることはできなくなります

システム規模が大きく 製造期間が短い場合は、瞬間最大風速的に 多くの人が集められて開発をすることになります。(※ここで論じている大きいシステム規模とは、ステップ数が多いということを意味しています。)そして 保守運用になると それら開発をした人のほとんどは去ってしまいます。つまり、プログラム開発者とプログラム保守運用者とは おのずと異なる人になります。、、、そして世の大規模基幹系システムというのは、ここに相当します。

ソフトウェア開発生産性などを論じる上で

ソフトウェア開発生産性などを論じる上で、今まで挙げたような前提条件を抜きにして論じるべきではありません。どの前提条件のうえで話題を進めているのかについて、私達は明確に示す必要があります。ところが世の広告や記事 (商用記事も含む) は これら前提条件を明示せずに 部分的な効率を述べてしまっていることが多いのです。敢えて明示していないのか、あるいは書き手が本当に知らないので明示していないのか、これは私にはわかりません。

立場の異なる人は、異なる立場の人の状況は なかなか理解できないものです

コンピュータシステム開発という狭いジャンルにおいてすら、ここで挙げたような立場や状況における差があります。そして これらの一方しか経験の無い人にとっては、他方の立場による状況というものを、なかなか理解できないものです。しかもコンピュータシステム開発に関する業界において、これら条件を抜きに論じている記事が 非常に多いという 具合の悪い状況が重なっているので、自分と異なる立場や状況というものがどういうものなのかについて、なかなか理解できないなんていうレベルどころか、全くもって理解できないというシロモノになっているようにも思われます。これは非常に憂うべき状況です。

職業(プロ)とアマチュアの ２つの立場

時間がないので割愛しますが、これ以外にも、ソフトウェア開発に職業(プロ)という立場と アマチュアという立場の いずれの立場で関わっているのかについても、前提条件として論じる必要がでてくる時代が来るかも知れません。アマチュアの立場であれば、自分の好きなことにだけ没頭できます。素晴らしい身分です。職業(プロ)という立場だと、自分の好きなものは作れないことが多いです。そのかわり労働の対価を得ることができます。

職業(プロ)の立場の人が自己実現のために オープンソースなどに アマチュアとして参加するのは、自分が好きなものを作ることが出来ない不満を解消するためにおこなっているように思えます。、、、自分の好きなものを仕事で作るようになるとオープンソース活動に割く時間は減ってしまうかも知れませんね…。望ましいのは 職業(プロ)として 好きなオープンソース活動に従事できることです。一部の恵まれた人たちは、そのような立場で活動しているように聞き及びます。

プログラミング言語や開発環境について思うこと

ここからは、プログラミング言語や開発環境についてのことです。

Java言語について思うこと

上記の前提条件のうち、保守運用あり ＋ 開発者≠保守運用者 ＋ 大規模システム という条件下において、Java言語は 最も優れた最適なプログラミング言語なのでしょう。Java言語は そのようなところで 非常に多く利用されています。Java言語は 多くの人たちに利用され、多くの人たちに愛され、そして多くの人たちに 忌み嫌われています。これは C言語が背負っている業にも似たものを感じます。(ちなみに 私は C言語を愛していて、そして同時に 忌み嫌っています) 、、、別の経験を持った人にとっては JavaはCOBOLと同等の地位になったんだ、と感じるのかも知れません。(そこは私にはわかりません) 少なくとも 多くの人に愛され、そして多くの人に忌み嫌われているプログラミング言語というものは、それは プログラミング言語としての 究極の高み なのだと思います。

また Javaが提供する Java仮想マシン環境は 多くの異なるOSに移植された 素晴らしい仮想マシンのひとつです。私が Javaで最も気に入りまた評価しているのは Java仮想マシン環境という実行形態についてです。Java仮想マシン環境は 既に多くのOSに移植され 既に長きにわたり保守運用された実績を持ち、そしてオープンソース化が予約されているので、将来に渡っても安定した実行環境を得ることが出来る期待を持てます。

Microsoftは 画面デザイナとして 非常に完成度が高いツールを提供しています

2007.09.06追記

そんな Java言語なのですが、相対的に弱い面があります。それは 画面デザイナ系の機能で定番となるものが無いという点です。JSP, JSP, Swing, SWT、いずれの画面デザイナツールにおいても、これぞ定番という画面デザインツールが存在していません (と私は考えています)。

秀逸な画面デザイナを古くから提供している組織のひとつは、他ならぬ Microsoft社です。Microsoft 社のツールは VisualBasic (VB)時代から 秀逸な画面デザイナを提供し続けてきました。それは VisualStudio .NET となった今でも 他を寄せ付けない 高みのポジションにいます。更に Microsoft は Windows Presentation Foundation （WPF） や そのプラグインである Silverlight を出してきています。.NET Frameworkランタイムとして Linux版の Monoについても追認する姿勢を出し始めています。デザイン面としては、Expression Blendといった よりデザイナ向けのデザイン系ツールまで提供し始めています。

私は私見として、サーバサイドは Java言語が好適なのだけれど、クライアントサイドは Microsoft .NET Framework の方が好適なのではないのか、なんて最近思い始めています。まあ、そこらあたりで心が揺れているという状況です。クライアントサイドに より刺激的な見栄えが求められるようになってくると、Microsoft .NET Framework (または WPF) は要チェックになるのではないかな、と予想しています。

世間のレンタル Webサーバの多くは Javaランタイムを利用できません

2007.09.06追記

現時点の 世間のレンタル Webサーバの多くは Javaランタイムを利用できません。そのため、単純に Java言語で開発したアプリケーションは世間の レンタルWebサーバの多くでは実行することが出来ません。ふむ、これも Java言語のウィークポイントですよね。

コンパイラ系かインタプリタ系か

一般的な傾向として、コンパイラ系のプログラミング言語は インタプリタ系のプログラミング言語よりも 規模の大きなアプリケーションを得意としています。これはそのソースコードの妥当性のチェックについて コンパイラが実施してくれるからです。(ふむ、私は ここで ソースコードの妥当性チェック機能のことをコンパイラと呼んでいます)規模が大きい場合には、クラス名、メソッド名、型といったものの妥当性を 言語処理系が担保してくれるというのは 生産性・保守性に非常に大きなメリットとなります。逆に言うと、クラス名、メソッド名、型といったものの妥当性を言語処理系が担保してくれないという状況は 規模の大きなアプリケーションの面倒を見るうえで かなりのデメリットとなりえるのです。

…経験上 規模の大きなアプリケーションをインタプリタ系言語 (妥当性チェックを言語処理系で担保しない種類のもの) で開発したものを、クラス名、メソッド名、型などの妥当性を自動テストで担保することは事実上不可能です。、、、そんなに規模が大きくないものだったのですが、ダメでした。

素朴に、大規模システム開発系では 言語処理系のチェック機能に依存するところが大きいのです。

SQLは 確固たる地位を得たプログラミング言語です！

プログラミング言語のうち SQLだけは 確固たる地位を得ています。SQLは プログラミング言語界の 唯我独尊状態です。これは衆目の一致するところなんだと私は勝手に思っています。

SQL言語は集合を扱うのが得意なプログラミング言語です。Java言語や C#.NET言語 あるいは Ruby言語などといったノイマン式プログラミング言語(?)とは ある意味決定的に異なるポジションにいます。そして、SQL言語に対抗しうる本命は 未だに登場していません。

プログラミング言語の いろいろなことを調べていくうえで、SQLには 歴史の重みや その特長など、興味深いヒントが数多く隠されていると思っています。

究極的には プログラミング言語なんて なんでも良いのですよね…

エンドユーザ観点において、究極的にはプログラミング言語なんて、なんでも良いんです。利用者は なにかアプリケーションを使いたいときに、プログラミング言語あるいは プログラミング言語のためのランタイムライブラリを取得して、そして実行したら良いだけなのですから、、、。

エンドユーザのために重要なのは、その利用したいアプリケーションが いったい動くのか それとも動かないのか、ということだけのはずです。ゲーム機で例えると、、、PlayStation 用のソフトウェアは ほとんどの場合 PlayStation 2 で動作することでしょう。でも PlayStation 2 用のソフトウェアは PlayStation では動作しないのでしょう。Wiiでは PlayStation 2用のソフトウェアは動作しないことでしょう。(裏は取っていません) そして、それらゲームのソフトウェアが 何言語で開発されているのかについては、ほとんどのエンドユーザには興味のないことなのです。そうなのです！ プログラミング言語で これが好き・これが嫌いなんてのは、開発者の単なるエゴだったのです！ (開発者の単なるエゴなのですけれども、生産性は無視できないから、どれを選ぶのかについては重要なのですけれどもね…)

このように、私たちがプログラミング言語を論じるときには、エンドユーザ観点を失っていないかどうかを自分に問いかけることも重要なのです。それは、Javaのバージョン、.NET Frameworkのバージョン、あるいは ＸＸＸ言語のバージョン、そういう所にも関係あるのですよねぇ。

それでも私は Java言語が好き (苦笑)

それでも、あるいは だから? 、、、いずれにせよ、私は Java言語が好きなのですけれどもね… :-Pそういう気持ちを、オープンソース開発に充てているのだと思います。(そんなところに落ちました)

この日記について