ProgFAN

プログラマの悪癖

C#のMLの過去ログを見ていたところ、Boxing/UnBoxingの利用方法についての討議があった。

ここではBoxing/UnBoxingの説明は割愛する。

その中の意見で気に入ったのが、「Boxing/UnBoxingはその存在を意識しないで利用できるところに価値があるのではないだろうか」と言う意見だ。

ガーベジコレクションもそうだが、どのように動作しているか気にする必要がないように作られたものを、「これはどのように動いているんだ？」と詮索するのは、プログラマの悪癖のように思える。

かく言う私もその一人だが。

再利用可能なフレームワークなどを使用する機会が増えてきているが、この悪癖が直らなければ開発効率を向上させるのは難しいだろう。

まぁ、そのフレームワーク内のバグで苦労することは多々あるが。

パッと見危険

あるニュースサイトで、WindowsXPsp2が9月2日より公開される記事を見たら、「9.2」と書かれていた。

一瞬「9.11」とダブって見えたのは気のせいではないように思える。

オブジェクト指向についての考察(3)

オブジェクト指向の入門書には基本的な説明として条件分岐、繰り返し、関数などの説明を行っているものはほとんどだが、肝心の構造化プログラミングを説明しているものはほとんどない。

これでは足し算引き算だけを教えて、いきなり累乗を教えているようなものだ。
累乗を教えるためにはかけ算を教えなければ、教えるのも理解するのも非常に困難であるはず。

ここでは条件分岐、繰り返し文、関数は一般的な概念として切り捨て、構造化プログラミングの解説から行うものとする。

概念的に説明すると、「プログラム上で行う様々な処理を、分割可能な処理毎にサブルーチンに分けるプログラミング手法」のことである。

処理毎に分割されていれば、同じ処理や似たような処理を同一のサブルーチンを使用することができるため、プログラムのダウンサイジングが可能となる。

例えば、加算を行うプログラム（例えば1 + 1の答えを算出する）では、加算する２つの値の入力を受け付ける処理と、その２つの値を実際に加算する処理、加算した結果を表示する処理などとサブルーチンを分けることができる。

この場合では、入力される２つの値はそれぞれ同じサブルーチンで取得することが可能となる。

つまり、構造化プログラミングで重要となる要素は『処理』であり、プログラム全体をどのような処理で分ければよいかを考える手法となる。

つづく...

オブジェクト指向についての考察(2)

前回の最後に記したように、専門用語を連ねた説明は入門としてふさわしくない。

もちろん、専門的な用語を使用しないで説明している入門書もあるが、その場合たいていはオブジェクトを「もの」として説明している。
例えば、「世界は"もの"によって構成され、人も犬も猫も車や地球さえも"もの"である。それらが相互に関係しあって世界を構成している。オブジェクト指向の世界も同様に、オブジェクトという"もの"が、様々に関係し助け合うことで目的とする処理を行っている。」というように書かれている。

しかし、これでは抽象的すぎる。人や犬が"もの"と言われても、それがプログラミングとどう結びつくのか皆目見当がつかない。

では、どのようにオブジェクト指向を解説するべきなのであろうか？

そもそも、オブジェクト指向は、どのように考え出されたのだろうか？
天才プログラマの閃きによってある日突然出てきた考え方なのだろうか？

私が知るところ、オブジェクト指向はそれまでのプログラミング技術の延長線上にある技術である。

つまり、突然考え出されたものではなく、必然的経験的に試行錯誤されて練り上げられた技術のはずである。

プログラミング技術の歴史を大雑把に振り返ると、機械語に始まりアセンブラ（低級言語）から高級言語に推移し、条件分岐や繰り返し文、関数などが考え出され構造化プログラミングの手法が出てきた後、オブジェクト指向が広まるようになった。

このように考えると、オブジェクト指向を習得するためには構造化プログラミングについての知識が必要であり、そのためには条件分岐や繰り返し文、関数などの概念も理解している必要がある。

つづく...

オブジェクト指向についての考察(1)

JavaやC++などのオブジェクト指向言語が流行っているが、本当にオブジェクト指向で作成されているプログラムはいくつあるだろうか？
そもそもオブジェクト指向とはどのようなものであろうか？

ここでは、私なりのオブジェクト指向について纏めてみる。

まず、オブジェクト指向という名前だが、これはどのような意味を持っているのだろうか？

辞書(goo辞書)を引くとオブジェクトは「(1)英文法で目的語、(2)対象、客観、(3)オブジェクト指向プログラミングにおいて、内部構造を持つデータ」と出てきた。
辞書でオブジェクトを引くと、オブジェクト指向でのオブジェクトの説明が出てくるとはお思わなかった。

続いて、指向を引くと「(1)ある目的を目指して向かうこと、(2)ある特定の方向を指定すること」とある。

ここで、オブジェクトの(3)の説明は抜きにして(あまりに直接的すぎるので)考えると、「ある対象が特定の方向を指定すること」となるが、これではさっぱり意味がわからない。
恐らく、未経験者が「オブジェクト指向」という題目を聞いただけで尻込みする理由がこの辺にあるのかと思う。

仕方がないので、オブジェクトの(3)の説明をそのまま載せてみる。

「オブジェクト指向プログラミングにおいて，内部構造をもつデータ。いくつかの内部データと，その内部データを操作する方法をひとまとまりにして管理したものをいう。オブジェクトは，データ構造を表すクラスのインスタンスとして生成される。その内部データは，通常外部から直接参照・変更することはできず，当該クラスに定義された操作方法によってのみ行える。この隠蔽(いんぺい)機能によりデータの利用方法が統一化されるので，再利用可能なプログラムが記述可能になり，大規模なプログラム開発が容易になる。」(goo辞書より引用)

まるで、Javaの入門書などの第一章によく書いてある文章のように見える。
いつも思うのだが、このようにクラスやら、インスタンス、やら隠蔽などの用語を使用して、説明を行ってもよけい混乱し、難しいものだと印象づけてしまうように感じる。

つづく...

MVCから見る「良い設計」

システムアプリケーションはよくMVCモデルを意識して開発されている。

MVCとはModel（情報）、View（表示）、Contorol（制御）をそれぞれ独立して扱うことによって、システム全体の見通しをよくしようという考え方である。

最近はやりのWebアプリケーションもこのモデルを当てはめることができる。
つまり、ブラウザに表示されるHTMLがView。ブラウザから送信されてきたリクエストを処理するのがContorol。そのリクエストに応じて表示する情報を保存するデータベースがModel。

この場合はシステム全体がMVCモデルになっているが、もっと小さい単位のMVCモデルも存在する。

つまり、モジュールやライブラリ単位のMVCだ。Javaで言えばJarファイルやパッケージ毎になる。

そして、さらに小さな単位で言えば、クラス毎にMVCモデルを意識することができる。
クラスのMVCは、フィールドがModelになり、インタフェースがView、クラス内の制御がContorolとなる。

つまり、規模の大小（システムであろうとクラスであろうと）に関わらず設計で重要な要素は変わらない。

どれだけ、そのシステムまたはクラスを使用する人のことを考えて設計できるかである。
この場合の「使用する人」と言うのは、一般的なユーザだけではなく、共同開発者や、後日保守をする人なども含まれる。

もちろん、良い設計だけでは不十分で、一般ユーザにはマニュアル、共同開発者には設計仕様書、保守をする人には保守仕様書なども重要な要素となる。

よりよい設計を行いたいと思うならば、使う人の気持ちになって設計するという最も基本的なことに重点を置くべきだと思う。

ノンバグレスソフト

「バグのないプログラムはない」という、有名な格言（みたいなもの）がある。

Hello Worldのようなプログラムでない限り、バグはどこかに潜んでいると思う。
それが致命的なバグであるかどうかは別にして。

そのため、ソフトウェアはリリース後にも頻繁にアップデートを繰り返す。
WindowsUpdateが良い（悪い？）例だ。

しかし、少し前を思い出すと子供の頃に遊んだテレビゲームには無数のバグが存在していた。
が、既に売ってしまったものをアップデートする仕組みがなかったため、そのまま使い続けた。
致命的なバグがあるゲームは非難されたが、ゲームのバグはむしろ裏技的な存在となっていた。

今日ではバグ＝悪的な等式が成り立っているが、冒頭でも言ったようにバグを完全に消し去ることはできない。

ならば、そのソフトを使用するユーザーが「バグはあるもの」という認識を一般的に広める必要があるのではないだろうか？

要するに、「バグがあっても笑って許して」ってこと。

人月の神話

「人月の神話」という本を読んでいる。

システム開発の見積もり（価格）設定は人数×月数で計算される。
つまり、３人のチームで６ヶ月かけて開発するシステムであれば１８人月必要だと計算される。
そして、１人月いくらで受注するかが大体決まっているので、それをかけたものがそのシステムの価格となる。

実に単純な価格設定。

もちろん、この人月のことばかりを追求しているのではなく、システム開発全体の問題点を洗い出し、改善策を模索している。

この本自体出版が二十年ぐらい前のことなので、そこで検証されている技術自体は古くさいものばかりだが、結果として出てくる問題点は現在にも通じている。

つまり、二十年たった今でも問題点が改善されることなくシステム開発が行われていると言うことだ。

この本の中で提案されている改善策や、最近はやりのアジャイル開発による問題解決を図るためには、現状の開発体制では物理的に実現不可能なことも多々ある。

これらの改善策を実行するためには、新規企業を興すか大鉈を振って企業の意識改革および環境改善を行うしかないが、なかなかそれに踏み切れないことこそが最大の問題ではないだろうか？

企業の役割

例えば、小中高大などの教育機関や、進学塾などでは各教科毎に教え方のマニュアルがあったり、教師が教え方の訓練を受けている。

しかし、ソフトウェア開発の現場では新人教育などの時に、開発のプロであって教育の素人が教育担当になる。

そもそも、ソフトウェア企業で技術教育を率先して行っている企業は少ないように思える。

私が思うに、開発部や営業部などと同等に教育部なるものがあっても良いのではないだろうか？

ソフトウェア業界の技術革新は目まぐるしく、とても個人で全てを把握し勉強していくのは無理がある。

会社という一団体が、ただの技術者集団になるのではなく、その企業特有の技術を持ったスペシャリスト（およびその候補生）の集団にならなければ、技術者のコストは下がる一方なのではないだろうか？

javadocs.org

javadocをネットから検索できるjavadocs.orgが公開された。

今まで、javadocを見たい場合googleからクラス名を検索して探していたが、これでその手間が省かれる。

と思ったが、結局まともに出てくるのはJ2SEとJ2EEの標準パッケージのみ。
他ベンダー（Jakarta等）のクラスを検索するとgoogleへ転送される。

さらに検索する言語を選択することができない。（この辺は後々改良されることを願う）

javadocという強力なツールがありながら実際それが有効に利用されていないというのは、プログラマなら誰もが実感していることだろう。（有効利用されているのはsunが提供しているライブラリぐらい）

クラス（ライブラリ）の再利用の重要性が唱えられてはいるが、それを実現するために最も重要なドキュメントの記述が疎かになっているのでは、プログラマの仕事が減る日はまだ遠いのだろう。