ライティングソリッドコード—バグのないプログラミングを目指して (マイクロソフトプレスシリーズ)
posted with amazlet at 11.07.25
スティーブ マグワイア
アスキー
売り上げランキング: 207178
アスキー
売り上げランキング: 207178
最近読んだ本の書評です。
ともに Microsoft Press アスキー出版局
この２つの本の共通点は「Microsoft社が過去の挫折と失敗から得た教訓」を 題材にしているということです。具体的に Excel のあるバージョンが バグのために出荷不能となってどうのこうの、といった生々しい商品名が 続出します。
まず Writing Solid Code です。 Ｃ言語の具体的なコーディング例をあげながら、バグのないソフトウェアを 開発するためにプログラマが習慣にすべき事柄を挙げていきます。
チームがバージョン管理システムを使用していることが前提で、 一人一人のプログラマがバグの入ったコードを checkin することを 防ぐことで、品質の高いソフトウェアを予定されたスケジュールで 開発する、というのが大きな目標になっています。
具体的には次のような提案がなされます。
これらの提案の根底に流れている思想は「バグの自動検出」です。 自分があるバグを出してしまったときに、 「このバグを二度と出さないためにどのような自動検出手法が可能か」 と常に問い掛け、新たな自動検出手法を自分なりに日々生み出していく 姿勢が重要である、と著者は言います。
本著に出てくるＣソースはじっくり読まないといけないものが多く、 Ｃ言語の初心者には読みこなせないと思います。（私も斜め読み状態。。）
が、著者も書いていますが、経験の浅いプログラマの仕事の多くは、 熟練プログラマが書いたプログラムの保守であり、熟練プログラマが この本の指示に従うことが、チーム全体の雰囲気を変えていくための 第一歩になるでしょう。
また、この本はＭＳの言語プロダクトのマニュアルには書かれていない 設計思想を学び取るのにも役立つでしょう。 ＭＳがＣ言語だけでなくあらゆる言語プロダクトにステップ実行の可能な デバッガを用意し、デバッグモードとリリースモードを用意していることは、 この本が説いている思想とダイレクトに結びつきます。 コンパイラの警告メッセージをすべて日本語訳する方針（ボーランドは 翻訳しない）も、どんな初心者プログラマもすべての警告を読む必要が ある、というＭＳ流の思想なのではないか、と思うくらいです。
また MFC が OOA 的発想でなく SDK の wrapper として出発した点も 「既存のコードを０からリライトすると新しいバグが混入する」 という経験則の延長線だったと言えるでしょう。
つぎに Debbuging The Development Process です。 こちらはプログラムをデバッグする本ではありません。 ソフトウェアプロジェクトの運営方法論をひとつの「アルゴリズム」と とらえ、これをいかに改善するか（＝開発プロセスのデバッグ）を 考えていく本です。
この本の大きな主題と呼べるものをあえて言うなら
「週４０時間、休日出勤なしで競争相手に負けないように働くには？」
という目標です。
労働時間が長くなるのは怠けているからではなく、プロジェクトの運営方法に 問題がある。そういう姿勢で著者が Microsoft の社内プロジェクトのいくつかを コンサルティングした事例がこの本には挙げられています。
時間を使うのではなく頭を使って生産性を上げて、夜と週末は自分の時間を エンジョイしよう、ということです。
仕事に励むだけの生活は、いつまでも 8MHz の IBM PC を使っているような ものだ、と著者は言います。
この本はソフトウェア・プロジェクトの運営方法論なので、プロジェクト・ リーダーのための助言が多くなされています。
筆者自身もいくつかの個人的な習慣を紹介しています。
この２冊の大きな主題は「デバッギング……」に書かれた次の言葉に 集約されるかも知れません。
「必死に働くことではなく、必死に頭を働かせることに重点を置くこと」
こうしてまとめて読んでみると、これらの方法論が「市場も製品も開発環境も 常に変化しつづける」という Microsoft のビジネスの特異性から生まれた ものだろうと推測できます。
そして、ＭＳを支えているのがカリスマでも根性でもなく、地道かつ 単純な思想の実践である、ということも感じられます。 おそらく、ソフトウェア産業におけるポストＭＳ企業は、ＭＳ的な方法論を ＭＳと同等かそれ以上に実践することになるでしょう。そして、それは 不可能でも苦痛でもなさそうだ、というのがこの２冊の読後感です。