プログラミング哲学

ペアプログラミングにたいして、ペアスタディというのはどうか？
一人でじーっとし量を読んでいるより、二人であーでもないこーでもないと相談しながら勉強して、
仕様理解であるならば、一人だと詰まった瞬間とまりがちな、質問点をあとでまとめて一変に聞くということも可能ではないか？
技術的問題なら、そのままプロトタイプのペアプログラミングというのも可能だし。

01/1/20

プログラムの最終的に何が問題って、自然言語でかかれた仕様書と、プログラムの差が埋まらないことだ。
つまり、仕様書とプログラムの間に確実な整合性が取りにくい。というより、プログラムと仕様書が二重かされてしまう。
これは昔から指摘されていたことで、クヌース先生あたりの文芸的プログラミングが有名だろう（未読）。

で、実は皆もう一つ重要なことを忘れていた！！
マニュアルだよ。

全てのものの製作者は非常にマニュアルを軽視していた。
たしかに操作が複雑でないものの場合、マニュアルなんておまけみたいなものだ。マニュアルを使わずにすむのが重要なんだから。
製品が完成してから、マニュアルをおまけで作るのではなく、初めからマニュアルも作りながら、プログラムを書くのだ。

っていうか、仕様書をXMLで書いて、そこからマニュアル、プログラム、プログラムのコメントとかを抽出できるのがいいよね。
理想論ね。

00/11/18

ソフトウェア工学有名人の論文風

「悪いのは魔人か乞食か？」

ソフトウェア開発において、顧客が要求したものと違ったものを作ってしまうことはしばしばある。
というより、そういう開発のほうが多いのが現状だ。
この場合、開発者の言い分は「顧客が要求したものを開発した。」であり、
顧客の言い分は「我々の要求したものを満たしていない。」である。
一見矛盾した言い分であるが、実は両者の言い分は両方とも正しい。

この問題をよりわかりやすくするために、三つの願いをかなえてもらう乞食の話で例えてみよう。
ある乞食が川で拾った壷みると、壷が突然話はじめた。
「私は魔人だ。この壷をあけてくれるならば、三つの願いをかなえてあげよう」
そこで、乞食はふたを空けて、魔人を解放してやった。
乞食は最初は「たくさんのお金が欲しい。」といった。魔人が指をパチンと鳴らすと当たり一面お金に包まれた。
今度は「豪邸が欲しい」と言った。魔人が指をパチンと鳴らすと突然豪邸が現れた。
乞食は最後に「一生働くてもいいようにして欲しい。」と言った。少し考えた後、魔人が指をパチンと鳴らすと回りにあったお金も豪邸も消え、乞食はもとの乞食に戻ってしまった。

この場合、魔人は乞食の要求を完璧に満たしている。しかし、乞食の真の要求とは程遠い。
それに、魔人は願いをかなえるという約束は破ったし、乞食は欲しかったものは手に入らなかった。
このとき悪かったのは真の要求を聞かなかった魔人なのだろうか？真の要求を伝えなかった乞食なのだろうか？

この問題は顧客と開発者の問題にも当てはまる。もちろん乞食が顧客で、魔人が開発者だ。
（顧客がみすぼらしくて、開発者が魔法を使うので凄いという意味ではない）
さて、このすれ違いは誰が悪くて誰がどう直せば双方とも利益が最大の結果が得られるのだろうか？
お、ゲーム理論の世界に入ってきたぞ。

00/10/31

一昔前の本などを読むと、
プロのプログラマの定義は「くだらないことにこだわらず、さっさとコーディング終わらせること。」ができる人物だった。
しかし、最近のプロの定義は「くだらないこといこだわらず、さっさとプログラムを完成させること。」に変わってきたことを、ひしひしと感じる。
プログラムはコーディングではなく、テストまで完了して、初めて完成したといえる。
従来の個々が勝手に行うプログラミングの形態であれば、「さっさとコーディングを終わらせる」のが一番の完成への近道だった（と勘違いされていた）。
しかし、それではテスト、保守などに時間がかかりすぎし、たいていの場合は皆で同じようなルーチンを作りまわして、整合性がとれず悩んでいた。
これでは総合的に見て、完成までの時間がかかるのは自明の理である。
だから細かいところにこだわって、きちんとプログラムを整理し、変更にも常に耐えられるシステムにしておくのは当然である。

大体、考えてみれば、建築だったら「こんな建物作りましょう。」といって、個々が好き勝手に自分の担当部分だけをつぎはぎだらけで作って、見栄えも良くなく、使い勝手も悪く、あとで配線に困って顧客に「なんでそんなこと考えないのだ」と文句を言って、地震が来たら一発で崩壊するような建物を作るような奴らを、自分だったらプロとは呼びたくないし、金だって払いたくない。

00/9/7

ファンクションポイント法について考えてみる。

ファンクションポイント法とはソフトウェア開発時の総作業量を見積もる際に用いる手法で、
古典的だが、現在もそれ以上のものが現れていない。

オブジェクト指向な時代になぜ、機能中心なものを使うのか。
とも一瞬思ったが、データが少しでも、それをいじる機能がたくさんあれば結局、作業量は増える。
逆にデータが沢山あっても、それを表示するだけ。とか機能が少なければ作業量は極めて少ない。
総作業量は結局のところ、機能の増加にともなって増加するのである。
（それがどれくらいの割合で増加するかは不明）

00/9/4

問題
日本で一番大事だけど、一番必要とされないものはなんでしょうか？
答え：基本

00/8/31

一つのシステムを作成するときに、SEはいろいろ考えねばなりませんが、
この考えるパターンはかなり限られている。

世の中には問題解決へのフローチャートをパターン化したものがあるので（エキスパートシステムや、TRIZ)、
それをまねしたSEサポートフローチャートという技術は作る価値があると思う。
システムのパターンによってかなり複雑になるとは思うが。

まずは企業向け受託開発あたりを中心に行うのが良いかもね。

もうあるのか？

00/8/28

プログラマのちょっと良さそうな話
その１２３５１３４２４（のんきな父さん風）

己の専門を持つな。

己の技術に専門を持ってはならない。
変化の激しいこの業界で専門領域を持つことは、全てのものが時代遅れになる業界にとっては、すなわちそこで進化が止まることに等しい。
常に何が重要かをわきまえれば技術の乗り換えはさほど難しいことではない。
そして、全ての技術は他の技術と密接にからみあっている。
つまり、本当のスペシャリストならば、むしろ多くの技術に関する知識を有しているのである。
自分の専門しか知らないスペシャリストは存在しえないのである。

だからへぼいプログラマが凄いプログラマになんでも知っていると思うのである。
凄いプログラマはなんでも知っているのは必然である。

00/4/25

「最新技術は英語で入手すべし、だから英語はプログラマにとっては必須技術だ。」
って言葉はよく聞くけど、
「最新技術は自分達で考えて生み出せ。ドキュメントは当然日本語でかけ。
  こちらのハンデ（英語を勉強しなければならない時点で、時間的に大きなハンデを負うのは当然）を
  欧米の技術者どもに思い知らせてやれ。」
という言葉をまったく聞かないのはどうしてだろうか？

00/3/1

へぼいプログラマはおまじないが大好きです。
わからなくなると、すぐに動いているソースを書き換えて「動くかな？」ってやってます。
料理で言えば「あ、これしょっぱいから砂糖入れよう」ってなことを毎日繰り返しているんです。

99/12/19（大幅改変）

プログラムは理系頭脳（人間ではない）を持つ人にしか書けないのか?

正確に言うと、数学が全くできない人間はプログラムが組めてもテストができないのではないか？
少なくとも（タイミングがからんでぐちょぐちょなものはともかく）単純な処理をするだけのプログラムで、自分の書いたものがどうやったらテスト完了かわからないのは問題だと思うぞ。
つまり、「自分の書いたプログラムが正しく動く」という行為の証明
という超重要なプロセスには、著しく数学で用いた証明の能力が必要になってきます。
証明問題で、証明すべき問題を利用して、証明を行う人間はむいてないかもね。

だから世間一般でいわれているように「プログラマは理系も文系も関係ないよね」とは私は言いません。
理系（の能力を持った）の人間でないとプログラマは勤まらない。