悪態のプログラマ -6ページ目
2007年06月24日(日)

異常系とは何であるか考えよう

テーマ:専門用語

システムのテストを行う際、テストの内容を「正常系」と「異常系」に分類することがある。それぞれのテスト項目数や不具合の発生数などを数えて、テストの妥当性や品質の判断に使ったりするのである。


この正常系、異常系という言葉はよく耳にするのだが、その意味は曖昧であることが多い。人によって解釈が違うのである。


例えば、「ユーザーが入力ミスをしたケース」について、「正常な値が入力されていないのだから異常系だ」という人もいれば、「開発者がミスを想定していて、プログラムで入力チェックをしてメッセージを出すなどの処理をしていれば正常系だ」という人もいる。


これは、異常系のテストを、「エラー・ハンドリングのテスト」と捉えるのか、「ハンドリングされていない(開発者が想定していない)事象が発生したらどうなるかを確認するテスト」と捉えるのかの違いである。


どちらが正しいともいえないが、少なくともプロジェクト内で、メンバーの認識をあわせなければ、混乱を招くだろう(もちろん、正常系と異常系に分類しないという選択肢もある)。



もっとも、テストの呼び方を決めるのは難しくない。むしろ、何をハンドリングして、何をハンドリングしないのかを決めることのほうが難しく、しかも重要である。それは、本来、システムに求められる要件(サービスレベル)と開発期間やコストなどのバランスの中で判断されるべきものだ。


また、ハンドリングをするにしても、その処理内容(どんなメッセージを出すのか、どんなログを出すのか等)を決めておかなければ、システム全体としての統一性がなくなる。


しかし、現実には、こうしたことが設計の段階で決められておらず、プログラマの独断で実装される(または実装されない)ことも多いようである。そのため、同じシステム内で同じエラーが発生しても、画面によって表示されるメッセージが違う、というようなことがよく起こる。あるいは、同じようなエラーについて、ある人は関数の戻り値で返し、別の人は例外を投げる(いわゆる TRY-CATCH で処理する)というようなことも起こる。


このあたりも事前にルール化し、十分な例を示すなどしてメンバーに浸透させておかなければ、システムのユーザビリティや保守性が損なわれてしまう。


異常系の設計は、正常系に比べておろそかにされがちだ。しかし、ユーザーテストなど、プロジェクトの最後の方での「手戻り」に繋がりやすいところなので、気が抜けないところである。








■関連記事
どこまで書くか設計書
曖昧言葉
例外論 ~その1~ 警報



知識ゼロから学ぶ ソフトウェアテスト
高橋 寿一
翔泳社 (2005/02/18)
売り上げランキング: 48245
おすすめ度の平均: 4.0
4 現場の目で見た正直な視点が親しみやすい
4 実際にテストを行う人へ
5 始めに目を通しておきたい本


Javaのメカニズム―エラー処理・例外で困っているあなたに
壬生 朗
カットシステム (2006/11)
売り上げランキング: 372916
おすすめ度の平均: 4.0
4 Javaからプログラミングを始めた人に

2007年06月12日(火)

プログラミングを始めようとして何度も挫折した人へ

テーマ:プログラマの心得

少し前になるが、はてな匿名ダイアリーで「プログラミングを始めようとして何度も挫折した」という人の投稿を読んだ(yasuhoの隠れ家さん経由)。色々な意味で考えさせられる話である。


才能以前なんだろうな。必死さが足りないって言われた。でも必死になるってどういう事なのか全然判らない。


元記事のトラックバックでも指摘されているが、この人は「プログラミングをしたい」とは思っているようだが、「プログラムを作りたい」と思っているようには見えない。例えば、「日常の単純作業を自動化するためのプログラムを作りたい」とか、「ゲームを作って友達に見せたい」とか、そういった動機がなければ、プログラミングは身につかないものだ(※1)。


「必死さが足りない」というのは、そういう「動機の薄さ」についての指摘だろう。しかし、「動機」は誰も与えてくれないし、本を読んでも書いていない。自分の中から出てくるものである(「面白いプログラムを作ろう」も参照)。



何がわからないのかもわからない。基礎の問題とか出して貰っても判らない。用語や文法みたいなレベルで既に躓くというか。なんというか、「言葉」って何で言葉って言うの?みたいな変な疑問ばかり湧いてきて進まないんだよね。


「用語や文法みたいなレベル」といった言葉が出てくるのは、勉強の進め方が間違っている証拠である。ちょうど受験が優先される日本の英語教育と同じだ。英語もプログラミングも、理論より実践が重要なのである。プログラミングを学ぶには、とにかく「実際にプログラムを作る」という経験を積むことが重要だ(「プログラミングは体で覚えろ」も参照)。


上達が早いプログラマは、事前に文法を学ぼうとはしない(家電などを使う場合に、慣れた人ほど「取説」を読まないのと同じである)。とりあえず自分が作りたいプログラムを作ろうとして、途中で分からないことが出てきたら、その都度調べる。このため、「何がわからないのかもわからない」などという状況はありえないのだ。そうこうしているうちに、自然と力がついてくる。



文法も、例えば1+1=2という式があったとして、なぜイコールがこの位置なのかとかくだらない事がずっと気になってしまいます。コロンが付いてたりとか括弧がどうだとか。


音楽家が作曲をする時に「ト音記号はなんでこんな変な形をしているのか」などということは考えないだろう。作曲には関係ないからだ。プログラマもプログラミング言語の「イコールの位置」や「コロン」や「括弧」に、意味を求めたりはしない。そういうことを考えるのは、プログラミング言語の研究者だとか、新しいプログラミング言語を開発しようとしている人の仕事であって、プログラマの仕事ではない。


プログラミング言語はプログラムを作るための道具にすぎない。つまり、プログラマを剣士に例えれば、プログラミング言語は刀である。言語の文法にこだわるのは、剣士になるために刀鍛冶の修行をするようなものだ。全く無関係ではないかもしれないが、進むべき方向を誤っている(※2)。それでも、どうしても刀の構造が気になるという人は、剣士ではなく刀工になるべきだ。



プログラマの仕事はプログラムを作ることである。それを見失ったまま、プログラミング言語をいくら勉強したところで、プログラマにはなれない。





※1
職業プログラマだと依頼されたものを作ることになるのだが、それでも、最初に勉強するときは自分の好きなものを作るべきだ(就職する前にプログラミングを経験すべきというのが私のいつもの主張である)。


※2
弘法筆を選ばずと言うが、有能なプログラマほど言語の違いにはこだわらないものだ(「Javaなんて知りません」も参照)。




新版 明解C言語 入門編
柴田望洋
ソフトバンククリエイティブ (2004/08/28)
売り上げランキング: 7708
おすすめ度の平均: 4.0
4 素人には厳しい ですが、 初心者には適した書籍かと思います
4 Cを学ぶならこれ!
5 K&Rのプログラミング言語Cの真の翻訳書?


なぜ、あなたはJavaでオブジェクト指向開発ができないのか―Javaの壁を克服する実践トレーニング
小森 裕介
技術評論社 (2004/12)
売り上げランキング: 14278
おすすめ度の平均: 5.0
5 オブジェクト指向の使用法を学べる
5 オブジェクト指向がなぜいいのか、どのように書いたらいいのか、単純明快に示してくれます
2 タイトルに偽りあり
2007年06月03日(日)

スパゲティ・コード

テーマ:専門用語

イタリア製の西部劇を「マカロニ・ウエスタン 」という。海外では「スパゲティ・ウェスタン」と言うのだが、日本では、かの淀川長治氏が「スパゲティでは細くて貧弱そうだ」として、マカロニに変えてしまい、そのまま定着したらしい。


しかし、スパゲティにせよマカロニにせよ、西部劇に冠する言葉として、食べ物の名前を選ぶという感覚は、私にはよく分からない(「ハードボイルド」の語源が卵のゆで方だったり、「上を向いて歩こう」が「スキヤキ」になるのと同じくらい分からない)。



それに比べると、「スパゲティ・コード」という言葉は分かりやすい。「処理の流れや構造を把握しにくく、修正や機能の追加が困難なプログラム(e-Word )」(のソースコード)のことを、スパゲティのからまった麺に例えているのである。


個人的には、最近、スパゲティ・コードという言葉はあまり聞かなくなったような気がする。オブジェクト指向プログラミングの普及と共に、処理の順番にコードを書いていくようなことが少なくなったからだろうか。しかし、もちろん、読解困難なコードが少なくなったということではない。


アンチパターン ソフトウェア危篤患者の救出 」という本にも、「スパゲティコード」という言葉は出てきている。しかし、それは幾つもあるアンチパターンの中のひとつでしかない。つまり、悪いコードは「スパゲティ」という一言では表せないのである。プログラミング言語の発展により、そのパターンは、いっそう多様化してきたようにも見える。


色々な処理を詰め込みすぎたクラス(「アンチパターン」では「肥満児」と呼ばれる)、仕様変更等で多くの処理が使われなくなり中身が空洞化してしまった関数、異常に長くてうねっているように見えるコード(YukiWikiで「うねりコード」 と呼ばれている)・・・。


・・・ラビオリ、マカロニ、エリーケ。まさに、いろんな種類のパスタを見るようではないか。







■関連記事
オブジェクトの気持ち
簡単コピー・プログラミングの罠
しらみつぶし
リファクタリング ~ 動いているプログラムを触る



■関連リンク
スパゲティプログラム(Wikipedia)
パスタ(Wikipedia)
ハードボイルド(Wikipedia)




アンチパターン―ソフトウェア危篤患者の救出
W.J. ブラウン 3,Hays W. McCormick Raphael C. Malveau Thomas J. Mowbray William J. Brown 岩谷 宏
ソフトバンククリエイティブ (2002/07)
売り上げランキング: 68328
おすすめ度の平均: 4.0
4 面白くて勉強になります
4 開発者~管理者まで参考になる
3 良い本だと思うけど星3つの訳


オブジェクト指向における再利用のためのデザインパターン
エリック ガンマ ラルフ ジョンソン リチャード ヘルム ジョン ブリシディース Erich Gamma Ralph Johnson Richard Helm John Vlissides 本位田 真一 吉田 和樹
ソフトバンククリエイティブ (1999/10)
売り上げランキング: 3526
おすすめ度の平均: 4.5
5 オブジェクト指向言語を用いた開発者に必携の本
5 原書は未だにトップランク
5 理解しておくとよい本

2007年05月28日(月)

教育制度の充実だけでなく

テーマ:ブログ

私の会社は新入社員の研修には力を入れている方だ。例年、新入社員の多くがプログラマとして採用されるが、プログラミング、設計、テストの仕方はもちろん、ビジネス文書の書き方まで厳しく指導されている(必要以上に厳しいので、嫌になってしまう人も多いのだが)。


会社としては、その点は対外的にも強調したいようだ。自社の Web サイトの求人用のページには、「教育制度が充実しています」といった内容に多くのスペースが割かれている。確かに、こうしたアピールは、会社のイメージアップのためには良いのかもしれない。



しかし、良いことばかりではない。就職活動中の学生がこれを読むと、「プログラミングについて何も知らなくてもなんとかなるのではないか?」という気になってしまうからだ。


もちろん、それも間違いとはいえない。確かに、入社時にプログラミング未経験でも、優秀なプログラマに育つ人はいる。しかし、問題は、育たない人も沢山いるということだ。いくら教育制度が充実していても、採用した社員がプログラマに向いていなければどうしようもない。


研修制度に期待して入社したのはいいが、プログラマとしての適性がないと判断された場合、本人も会社も不幸である。そんな不幸を避けるには、就職先を決める前に、自分にプログラマの適性があるかどうか、よく考えなければならない。そして、そのためには、少なくともプログラミングの経験が必要なはずなのである。


もっとも、会社の採用試験等で、しっかりと適性が判断できれば問題ないのだが、私の会社ではあまりうまくいっていないようだ(人気企業でもないので、そもそも選べる立場ではないのかもしれない)。



Web で求人するのなら、教育制度だけを強調するだけでなく、仕事に要求される技術力の高さ、難易度の高さについても触れておいたほうがよいだろう。「尻込み」する学生がいるかもしれないが、それは望むところである。本当に高度な技術者を目指す人なら、高度な技術が要求される職場を選ぶはずだからだ。特に、プログラマの場合、能力の個人差が異常に大きいのだから、人数を多く確保することよりも、能力が高い人材を確保することを考えたほうがずっとよいはずである。







■関連記事
プログラマは誰でも同じ?
プログラミングは体で覚えろ
面白いプログラムを作ろう
プログラマとして歓迎したい人とは
簡単フレームワーク・プログラミングの罠



超求人成功法 ~あなたの会社に人が集まる51の知恵~
岡野 弘文
インデックス・コミュニケーションズ (2006/09/07)
売り上げランキング: 97532
おすすめ度の平均: 4.5
5 実績を持った人だけが親切に書ける内容満載の本
5 確かに・・・
5 大変勉強になりました!


採用の超プロが教えるできる人できない人
安田 佳生
サンマーク出版 (2006/03/02)
売り上げランキング: 5338
おすすめ度の平均: 4.5
4 採用に関係ない人でも読める
5 面接の採用者の目を知ることができました。
4 確かにカツノリは古田にはなれなかった。

2007年05月20日(日)

見かけの進捗

テーマ:ブログ

顧客や上司への進捗報告を行う際、進捗が遅れていても「予定通り」と報告する人がいる。遅れを責められるのが嫌なのだろう。しかし、最後までそういうことを続けていると、遂には納期に納品できなかったり、テストを省略 してボロボロのシステムを納品してしまったりして、もっと責められることになる。


私は、進捗報告は「控えめ」にすることにしている。予定より進んでいる場合は「予定通り」、本当に予定通りの場合は「少し遅れている」と報告するのである。実際、進んでいると思っていても「手戻り」が潜在していることがあるから、そのくらいの方がよい(もちろん、顧客や上司を心配させない程度に)。



そういえば、昔、進捗を「実際より進んでいるように見られてしまった」ことがある。顧客に開発中のシステムの画面を見せた時のことだ。内部の処理は全く出来ていなかったにも関わらず、顧客に「ほとんど出来てるじゃないですか」と言われたのだ。


確かに、画面の表示は完成品のように見えた。当然である。ダミーデータをソースコード内に埋め込んで表示させることで、表面的な動きだけ「それっぽく」なるようにしていたのだから。画面のレイアウトや動作仕様を顧客に確認しておきたかったので、あえてそのようにしたのである。


もちろん、私は「今はダミーのデータを表示させていますが、中身はほとんど出来ていないんですよ」と言ったものの、顧客は満足げな表情を変えなかった。





デスクトップ・アプリケーションにせよ、Web アプリケーションにせよ、画面の設計は早いうちに決める。なるべく早く顧客に確認を取りたいところなので、事前にモックアップ(紙芝居)を作って見てもらうこともある。そうでなくとも、イベント駆動型プログラミング の場合は、画面の外見から先に作るだろう。もし、こうした画面の見た目だけでシステム開発の進捗を判断するならば、プロジェクトの初期に進捗率が一気に進み、中盤以降は伸び悩んでいる(手を抜いている)ように見えるだろう。


システム開発についてよく知っている人なら、こうした「見かけの進捗」を本当の進捗だとは思わない。しかし、よく知らない人は、後半、開発者は何をやっているのかとイライラするかもしれない。そうした人に画面の動きを見せるときには、あらかじめよく説明しておいたほうがいいかもしれない。







建築屋は鉄を、システム屋はテストを削る
どのくらいでできる?
やってみなきゃわからないという現実




プロマネはなぜチームを壊すのか 知っておきたいプロジェクトのヒューマンスキル
伊藤 健太郎
日経BP社 (2007/03/15)
売り上げランキング: 2211
おすすめ度の平均: 4.5
5 プロジェクトマネジャーをさせてもらえないPMPに薦める本
5 非経験者ですが
5 プロマネのヒューマンスキルを真正面から扱った良書です。


Ameba人気のブログ

Amebaトピックス