しらみつぶし

検索とは、ループして探すことである。

と思っている人が結構いることには驚く。初心者ならまだしも、中堅プログラマにもいる。

ループして探すというのは、簡単に言えば、こんな感じである。

　　// ID が 123 の人の名前を探す
　　for(i=0; i<n; i++){
　　　　if(data[i].id == 123){
　　　　　　// 発見
　　　　　　you = data.name;
　　　　　　break;
　　　　}
　　}

とするわけだ（ひどい場合は break もしない人がいる）。

しかし、ループによる検索では、データ数が増えたり、他のループの中で入れ子になったりすると、非常に遅くなる。こんなところで文章化するのが恥ずかしいくらいあたりまえの話である。

と思っていたのだが、実際には大量データでもこれをやってしまうプログラマは結構いる。

最近のプログラミング言語では、基本的な検索アルゴリズム（例えばハッシュテーブルや二分探索など）は、標準的なライブラリに用意されていることが多い。にも関わらず、使わないのはなぜか？

単に、そういったアルゴリズムの存在自体を知らないのだろうか？　だとしたら、大至急勉強してもらいたいのである。

C言語による最新アルゴリズム事典

posted with amazlet on 06.03.25

奥村晴彦
技術評論社 (1991/03)
売り上げランキング: 10,972

おすすめ度の平均:

アルゴリズム辞典の決定版

必読でしょう

Amazon.co.jp で詳細を見る

珠玉のプログラミング―本質を見抜いたアルゴリズムとデータ構造

posted with amazlet on 06.03.25

ジョンベントリー Jon Bentley 小林健一郎
ピアソンエデュケーション (2000/10)
売り上げランキング: 2,545

おすすめ度の平均:

納得！アルゴリズムは重要

プログラマなら読むべき本

アルゴリズムって何?

Amazon.co.jp で詳細を見る

テストを簡単にし、品質もアップする方法

EoT（テスト容易性）の高い設計が、よいオブジェクト指向設計である。

今週の「週間オブジェクト倶楽部」（※）で、平鍋氏が提案している考え方である。「テストが簡単に行えるような設計をせよ」ということであろう。

ここでの「テスト」とは、xUnit のような自動テストと考えてよいだろう。自動テストは、プログラムによるプログラムのテストだ。いつでも何度でも実行できるので、初期開発時の品質向上のみならず、仕様変更時や改訂時のリスク低減にもなる。

平鍋氏の言う「EoT の高い設計」を行えば、自動テストプログラムの作成時間を短縮させ、その品質も向上させることができるだろう。そして、そのことが、テストされる側（製品）の品質や保守性をも向上させることは言うまでもない。

しかし、デメリットがないわけではない。「EoT の高い設計」では、製品プログラムを単独で見た場合よりも、テスト用プログラムと合わせて見た場合のほうが、構造的に美しくなるだろう。製品には、本来は不要なはずの「テストのための構造」が入り込むことで、実行速度面やプログラムサイズ面にも犠牲が出るケースも出てくるかもしれない。

とはいえ、多くの開発プロジェクトで、品質が最も重大な問題となっているのは事実であり、全体的にはメリットの方が大きいものと思われる。

更に EoT のような考え方が浸透していけば、例えば、アプリケーション・フレームワークとテスティング・フレームワークの融合が進むだろう。あるいは、自動テストが難しい GUI（画面操作）のテストの方法を、OS やウインドウ・マネージャが提供してくれる日が来るかもしれないではないか。

※「オブジェクト倶楽部」のメールマガジン（2004-39号 No.67）
　　http://objectclub.jp/

JUnitによるテストファースト開発入門

posted with amazlet on 06.03.25

サイバービーンズ今野睦
ソフトバンククリエイティブ (2004/04)
売り上げランキング: 95,598

おすすめ度の平均:

ツール紹介の本

実行例はわかるのですが，説明文が今一つ

ソフトウェアテスト本の新スタンダードかも

Amazon.co.jp で詳細を見る

はじめて学ぶソフトウェアのテスト技法

posted with amazlet on 06.03.25

リー・コープランド宗雅彦
日経BP社 (2005/11/03)

Amazon.co.jp で詳細を見る

設計書がそうなっていました

動かないと分かっているプログラムが堂々と納品されることがある。なぜか。

システム開発では、完成直後の設計書が 100% 正しいということは少ない。このため、プログラミング以降の工程で発見された設計上の問題は、設計者にフィードバックするなどして修正する。筋金入りのウォーターフォール主義者といえども、それは認めるところだろう。

しかし、工程が会社をまたがるような場合、このフィードバックがうまくいかないことがある。ある会社では、プログラミング工程を「作業範囲」として契約を交わすと、とにかく設計書に忠実にコーディングを行う。設計書のバグまで忠実に再現するのである。

その会社にしてみれば、設計に関する作業は「契約範囲外」ということだろう。たしかに、あまりに出来の悪い設計書を受け取った場合などは、このような考え方をしたくなる。しかし、他にも、もっと良い対策もあるはずである（例えば、契約時に「設計書に修正が発生した場合どうするか」といった取り決めを行うなど）。

それにしても、「このプログラムは動きませんが、設計がそうなっていましたから」と堂々と言ってのけるのは、いかなる心境だろうか。意地悪な受け止め方をすれば、「動かないのはお前らの設計が悪い。自業自得だ」と言っているようなものである。

正しいプログラマとは、正しいプログラムを作る者である。正しいプログラムとは、単に設計書と一致しているプログラムではなく、「正しい設計書」と一致しているプログラムである。

プログラマ諸氏へ。設計書に疑問があれば表明せよ。

※「設計書がそうなっていました」という言葉は、ソースコードのレビュー等でもよく聞く。「ここんとこ、何でこうなってるの？」「設計書がそうなっていました。」という具合。仕様を理解せずに、機械的にキーパンチしている証拠である。いずれにせよ、好きな言葉ではない。

デマルコ大いに語る―ソフトウェア24の閃きと冴え

posted with amazlet on 06.03.25

トムデマルコ Tom DeMarco 大野徇郎
日科技連出版社 (1998/12)
売り上げランキング: 90,103

おすすめ度の平均:

物語としておもしろい

Amazon.co.jp で詳細を見る

ソフトウエア開発プロフェッショナル

posted with amazlet on 06.03.25

スティーブ・マコネル松原友夫山浦恒央
日経BP社 (2005/01/20)
売り上げランキング: 16,616

おすすめ度の平均:

ソフトウェア関わる人すべてにお勧め

ソフトウェアエンジニアリングとは？

「ニセ実力主義」の組織のすべての人へ

Amazon.co.jp で詳細を見る

プログラマ三原則

第一条

プログラマは、顧客に損害を与えてはならない。また、他人のバグを看過することによって、顧客に損害を及ぼしてはならない。

第二条

プログラマは、設計者によって与えられた設計書に、服従しなければならない。ただし、与えられた設計書が第一条に反する場合は、この限りではない。

第三条

プログラマは、第一条及び第二条に反する恐れのない限り、自己を守ってもよい。

※これはもちろん、アシモフのロボット三原則のパロディ。しかし、当たらずとも遠からずではないかと。。。

後日談（2006/3/25記）。

既に、フィンローダさんのところに「プログラマー３原則」というのがありました。FPROG 時代（パソコン通信 NIFTY-Serve のフォーラムですね）で発表ということなので、かなり前からあったんですね。不勉強でした。

私はなるべく原文を変更しないようにしていますが、フィンローダさんは第三条の最後を「残業してはならない」とされています。そのほうがプログラマにとっては、リアルに響きますね。

わたしはロボット

posted with amazlet on 06.03.25

アイザック・アシモフ伊藤哲
東京創元社 (2000/00)
売り上げランキング: 91,701

おすすめ度の平均:

どこまでロボットは進化するか

ロボット三原則＝実は人間三原則

連作

Amazon.co.jp で詳細を見る

アイ,ロボット特別編

posted with amazlet on 06.03.25

20世紀フォックス・ホーム・エンターテイメント・ジャパン (2005/02/04)
売り上げランキング: 6,145

おすすめ度の平均:

アイモフの小説を全く無視した映画

これはヒューマンドラマだ！

これはおもしろいぞ！

Amazon.co.jp で詳細を見る

Javaなんて知りません

システム開発の業界では、特定のプログラミング言語を経験しているかどうかが重要視される場面は多い。例えば、プログラマの求人広告などを見てもらえばわかるだろう。

また、プログラマの側にも、「自分は Java は知らないから」と、新しい仕事を尻込みする人が結構いる。これは大きな問題だと思う。

秒進分歩とも言われる世界で、新しいことを知らないことはごく当たり前のこと。逆に、自分が知らない技術については、むしろ貪欲であるべきではないのか？

そもそも、プログラマのスキルにおいて、特定言語の経験の有無はそれほど重要だろうか？　即戦力が必要とされるような短期プロジェクトでは、重要である。しかし、長期のプロジェクトや社員の採用となると、その重要性は低いはずである。

そんなことよりも、プログラミングに必要な普遍的な考え方を心得ているかどうか、ということのほうが重要である。それが何であるかをこの場で述べるのは難しいが、例えば「オブジェクト指向」、「アルゴリズム」、「処理効率」など、特定の言語に依存しない言葉を思い出してもらいたい。あるいは、より安直に、「プログラミングのセンス」と言ったほうが伝わるだろうか。

プログラミング言語の文法を学んだり、ライブラリの使い方を覚えたりすることよりも、プログラミングの「センス」を磨くことのほうがはるかに難しい。そして、そのことを知っているプログラマは、言語の違いなどには、それほどこだわらないのである。

※もちろん、好きな言語、嫌いな言語はあると思うが。