memorandums

日々の生活で問題解決したこと、知ってよかったことなどを自分が思い出すために記録しています。

CODE COMPLETE (下) 第2版

帰宅する前に来週の出張にもっていく本を選んでいました。出張時は格好の読書時間になります。あまり重い本は持って行きたくないな。。。と思いつつ手に取ったのが以下です。ずいぶん前に購入したものの、論文で引用する部分しか読んでいなく。。。お恥ずかしい限りで。

CODE COMPLETE 第2版 下 完全なプログラミングを目指して

CODE COMPLETE 第2版 下 完全なプログラミングを目指して


うわさに違わず名著ですね。。。参考文献がもの凄く豊富。これだけでも本の価値があります。上巻はコーディングに関わる話題が中心ですが、下巻は品質管理やテストやリファクタリングなど、コーディングの周辺の部分を扱っています。インスペクション、レビュー、テスト、XP、TDD、リファクタリング、品質予測。単にキーワードの解説だけではなく、実践的な話題やコードを絡めての説明なので納得します。後半が楽しみです。


中でも面白いと思ったのは、エラーの除去率とデバッグの戦略の話でした。


エラーの除去率は単一の手法よりは、複数の手法(インスペクションやレビューやテストなどという意味)を組み合わせた方があがるとのこと。公式なインスペクションがもっとも除去率が高い。高いけどコストも高い。公式なインスペクションをきっちりやっている企業ってどれくらいいるのかなぁ?また、意外なことに?ペアプロも高いそうです。


ちなみにインスペクションの原論文(PDF)はこちらからDLできるようです。

"Design and code inspections to reduce errors in program development," by Michael Fagan
IBM Systems Journal, Vol. 15, No. 3, pp. 182-211



ほとんどの開発者は「感覚的」にデバッグしていると思いますが、このようにテクニックとしてまとめてあるとわかりやすいですね。特に初心者である学生に説明しやすい。以下、一例を抜粋します。(→は私が追加しました)

■構文エラーのためのテクニック

→初心者が良くやる「;」忘れなどは、次の行の行番号がエラーだ、と言いますからね。。。「そのあたりだ」という程度で受け止めましょうと。

→実際はエラーメッセージを読まない学生が多いのでこれ以前なのですが、読んだとしてもそこに書かれているのは犯人かもしれないけど、もしかすると親分(本当のエラー)が他にある可能性はあるよ、ということですね。

→これもそう。エラーメッセージが山のように表示されてうんざりしますが、一番上のメッセージを消したら全部一気に消える場合もあります。2番目は見ない、くらいがちょうどいいということですね。

  • 分割して攻略する。
  • コメント記号や引用符の閉じ忘れを探す。

→これも良くあるエラーです。


初心者にもわかりやすいエラーメッセージを表示するプログラムを開発したいと思った時期はありましたが未着手です。プリプロセスしてコンパイラとは別処理のエラーチェックをするか、表示されたコンパイルエラーについて、良くある間違い例と対処例をガイダンス表示するとか、まずは考えられそうですが。


学校では、構文やアルゴリズムや設計法は学んでもデバッグ法をきちんと学ぶ機会は、そうないと思います。うちでもプログラミングの講義では明示的に取り扱っていないと思います。デバッグは仮説検証の連続です。仮説が立てられるようになるには、まずプログラムの動きを理解しなければならないはずです。初心者は構文を学習しながらデバッグを嫌がおうにも学ぶわけですから、大変な作業になりますね。。。エラーシーディングしたパターンをいくつか用意して段階的に解かせる、デバッグの訓練システムのようなものを用意すればいいのかなぁ?