『Code Craft』6〜9章
読書メモ。
先々週末、先週末にひきつづき、『Code Craft ~エクセレントなコードを書くための実践的技法~』を読み中。今日読んだのは次の4つの章。
- 第6章 過ちは人の常
- 第7章 プログラマーの道具箱
- 第8章 テスト
- 第9章 誤りの検出
第6章 過ちは人の常
第1章から第6章までは、ソースコード開発の基本についてでした。第6章は、例外処理についてです。例外とシグナルの違いとか、例外をいつ処理すべきかとか、ログに出力すべき情報とか。
本文の流れと関係ないけど、C#では「実質的にはファイナライザである~X()がデストラクタと呼ばれて」いるという脚注について。仕事でC#を使ってるのに、何のこと？と思ってしまった…あとで調べよっと。
第7章 プログラマーの道具箱
ここからは第二部で、コードを書くプロセスの話題にうつります。第7章は、様々なコーディングのためのツールと、ツールを扱う方法についてです。
印象に残ったのは、「言語は、それ自体がツール」という一文。この本では各章の終わりで、良いプログラマと悪いプログラマの習慣が、箇条書きで対比されています。第7章で示される良いプログラマの習慣のひとつに、次のようなものがありました。
自分が使うものをすべてツール（交換可能なユーティリティ）と見なす
「ツール」を「言語」に置き換えると興味深い。実際、本文でも複数の言語を学ぶことの重要性について、言及されています。ちなみに、悪いプログラマの方はこんなかんじ。
少数のツールの使い方しか知らず、あらゆる問題をそれらのツールの観点で捉える
第8章 テスト
第8章は、テストについて。テストを考慮した設計や、テストをビルドプロセスに組み込む話にも触れられています。
品質とは、コードが完成してから上乗せできるような種類のものではありません。（p.175）
泣いた（うそ）。そのとおり。品質は、計画、設計、実装、テスト…と、段階を追って作りこむしかないと思う。
ほかに気づいたこと。
- フォールトトラッキングシステムをリリースノートの準備に役立てる
- うちではリリースノートを省略している。そのせいで、リリースごとの修正。追加事項は、プロジェクトのドキュメントツリーの奥深くにある課題管理表を確認しないと、誰にも分からない状態だ。ゴメンなさい。次から書こう。
- バグレビューのミーティングは、欠陥レポートの扱いを決める場であり、個別のコード修正を議論する場ではない
- たしかに！ でもどうすれば…。ミーティングの戦術については、411ページの「ミーティング運営術」（第17章）を参照…とのことなので、次は第17章「チームの力」を先に読もうかな。
フォールトトラッキングシステムについて解説されていて、読むと、またTracを導入したくなった。こっそり試してみようかなぁ。
