プログラミングと心理学
現在、大学で心理学を中心に勉強しているのですが、こんな本を見つけて読んでみました。前半の社会心理学的アプローチの記述は、共感できる部分も多いのですが、時代が古くインターネットの利用が前提となっている現代にはあてはまらない部分もあり、適応読み替える必要があると感じました。 後半の認知心理学的アプローチの記述は、自分自身が現在認知心理学系を中心に講義をとっていることもあり、非常に興味深く感じました。 |
実際に仕事でプログラミングをしていると、人の書いたソースコードを読む機会が非常に多くありますが、その中には「何でこうなっちゃたの？」と思わされる記述が良くありますが、そんな中での一つをご紹介します。
■ bcopy ってなんじゃらほい
時代は今から約１０年と少し前のこと、WindowsNT4.0上でのアプリケーション開発をしていた時のことでした。開発言語はC/C++。VisualC++を使っていました。そんな時、某プラント系上場企業のエンジニアが書いたというコードに遭遇。
void bcopy(const void *src, void *dest, size_t n);
という関数を自前で実装し、それを自分のコードの中から呼び出していました。それを発見したときに思ったことは…
・bcopyって何だ？何で作っちゃったの？memcpy使えばいいじゃん。
・しかも、srcとdestが逆だよ。何でこんな紛らわしいことするかな。
→ANSIのコピー系関数は皆、右から左にコピーします。これは代入が右から左に行われるからだと聞いたことがあるのですが、本当ですかね？
・きっとタコプログラマが書いたに違いない。
まぁ、この人が書いたコードがバグだらけだったのと、当時私がまだ若かった？せいもあったのかもしれませんが、こんな帰結とあいなった訳です。
しかし、今現在になって調べてみると、bcopyというのはUnix系では認知されているようですが、ANSIに含まれていないこともあり、VC++には含まれていなかったようです。
このような情報から以下の様なことが想像できるのではないでしょうか？
・これを書いた人は、ANSI世代よりも前のプログラマだった。
・#define bcopy(s, d, n) memcpy(d, s, n) と書けば良いのにと思ってしまうが、memcpyの存在を知っていれば、bcopyを自前で実装するという行動には出なかったはずなので、memcpyの存在を知らなかったと言える。
・非ANSI系のコンパイラは結構使いにくいので、gccを導入して使っている人は結構いたはずですが、種々の制約により、それも実現できていなかった。
プログラミングにおいて、過去の歴史を知らないというのが問題になることは少ないですが、現在の流行というか標準を知らないと、周りに迷惑をかけることがあると言えるかもしれません。
ちなみに、現在ではC99なんてのも出ていますが、これの可変引数マクロが使ってみたいです。
http://ja.wikipedia.org/wiki/C99
■ 認知心理学的な観点から…
この事例を認知心理学的な観点から考察してみます。
第１段階
bcopy 関数を使ったら、コンパイルエラーになった。調べてみたが、サポートされていないようだ。
第２段階
それでは、自分で実装すれば良いだろう。対して大変な処理でもないし。
という思考のステップを踏んだのではないだろうかと想像されますが、ここで想起されるのは「bcopy は、非常に利用頻度の高い関数なのにサポートされていないのはおかしいと、なぜ考えなかったのか？」という疑問です。
要因として想像されるのは、従来からUnix系での開発を行っており、Windows上での開発が初めてであったからということです。一般的に大企業では、一つの長いプロジェクトに継続して従事することは、その当時では珍しいことではなく、Unix系での開発しか経験がなかったというのは、想像に難くありません。国や地方の文化でもそうですが、一つの国や地方にしか住んだことがなければ、自分が普段接しているものが、自分の周囲に固有の物なのかそうでないかの、区別が付きません(秘密のケンミンSHOWではその良い例がたくさん紹介されますね)。そこから類推すれば、bcopyが存在しないことに対して、存在しないのだから作るしかないと思ってしまったというのは、あながち短絡的な判断とも言えないのかもしれません。
また、Unixのみの環境に対しての知見しか持ち合わせていないとすれば「このような非常に利用頻度の高い関数ならば、同一か非常に近い関数が存在するはずだ」という推論も困難であろうかと想像できます。
現在では、インターネットを利用して検索することができるので、このような事態は起きえないのかもしれませんが…
■ 対策
考察した結果から導出される対策は…
・自分が普段使い慣れている機能が存在しない場合には、その機能の一般性を評価して、一般的であると想像できる場合には代替機能が存在するという前提で調査する。
・直接代替可能な機能が存在しない場合には、その機能を構成要素に分割して、その構成要素毎に代替機能の存在を調査する。
・よく知っていると思われる人に聞く(実際、これが一番早いですね:-)
その昔、さんざん苦労して調べて行き着いた先が、VC++のチュートリアルだったなんてことが、一度や二度ではないことはナイショです。
