達人プログラマー 読書ノート 2/3

著者:

Andrew Hunt, David Thomas

訳者:

村上雅章

出版社:

株式会社ピアソン・エデュケーション

発行年:

2000 年

ISBN:

978-4-89471-274-4

第 4 章 妄想の達人

プログラミングの基本的なコツを記述する章？

まずは「契約による設計」の話。

  • <Bertrand Meyer は、契約による設計というコンセプトを Eiffel という言語で採用しました> (p. 111)

    後でいいから Eiffel という言語を調べておくこと。

  • <ルーチンに事後条件があるということは、暗にそのルーチンが完了するということを意味しています> (p. 111)

  • <言い換えれば、生成した新たな下位型が本当に基本型と is-a 関係にある、つまり同じメソッドを提供し、そのメソッドが同じ意味を持つことを保証すべきであるということです> (p. 113)

    おなじみの Liscov の置換原則の説明。

  • <トラブル発生時にコメント化された契約があれば、そこを起点に調査を開始することができる> (p. 114)

Assert およびその周りの話。

  • <言語によっては表明を使うことによって、こういったことを部分的に実現することができます> (p. 115)

    契約をコンピューターにチェックさせると利点が大きいという話。

  • <プリプロセッサによるアプローチは、組み込み機能のものほど優れてはいません> (p. 116)

  • <正確性についての責務を呼び出し側へとシフトする> (p. 117)

  • 例えば数学関数の呼び出しで NaN が返されてしまうと、その呼び出しが終了してから、その戻り値を初めて使う演算でやっとおかしな結果が発生する。

    <問題発生時点で早めにクラッシュする方が問題の早期発見や診断を簡単に行える> (p. 117)

  • ここで言っているループ不変表明だが、案外 assert コード化できない or 面倒な内容であることが多い気がする。サンプルコードの最大値表明もまさにそんな感じ。

  • <DBC がそんなに強力なら、なぜもっと広く使われないのでしょうか> (p. 120)

  • Eiffel のコードの require と ensure は面白いな。

  • 問題の早期発見手段としては、<多くの場合、プログラムのクラッシュはもっとも正しい行いとなる> (p. 123)

  • <障害を抱えて中途半端に動いているプログラムよりも死んだプログラムの方がダメージは少ないはず> (p. 124)

  • assert マクロは、「これは起こるはずはない」という箇所に仕込む (p. 124)

  • 表明に引き渡す条件には副作用があってはなりません。（略）つまり assert 中には実行に必要なコードを記述してはいけないのです> (p. 125)

  • <本当のエラー処理には表明を使ってはいけません> (p. 125)

例外の話。

  • 例外を送出する・しないは「状況による」(p. 129)

    • ファイルが存在するのかしないのか決まっていない場合、それは例外ではない。

    • するはずなのに存在しない、開けるはずなのに開けない場合は例外。

  • 例外は <非局所的な制御の移動> (p. 130) を表現することになる。

リソース管理についての話。

  • <だいたいの場合、リソースの使用はワンパターンなもの> (p. 132) になる。

  • <リソースの割り当てと解放に対して一貫性のあるプラン> (p. 132) を持つ。

  • <割り当てと解放のバランスは、クラスのコンストラクタとデストラクタを連想させます> (p. 135)

  • <例外をサポートする言語では、リソースの解放が扱いにくい傾向にあります> (p. 135)

    言語によって解放処理の書き方のパターンが違う。デストラクタだったり finally だったり。

  • 階層構造を持つリソース割り当てに関するアドバイス (p. 138) を整理しておきたい。

  • 長期間稼働プログラムでは、メイン処理ループの先頭にリソース使用量チェック処理を仕込む (p. 139)

第 5 章 曲げるか壊すか

この章はモジュール、コンポーネントに関する話題。

  • あわただしい変更ペースに追随するために、柔軟性の高いコードを記述する (p. 141)

  • 概念の分離を押し進めることによってモジュール間の結合度を下げる (p. 141)

  • 柔軟性を保つ良い方法はコード量を減らすこと (p. 141)

  • 柔軟性のあるコードを生成するための鍵となるコンセプトは、表現 (View) からデータのモデル (Model) を分離すること (p. 141)

結合度を最小化する方法について議論。

  • <スパイや反体制者のような偏執的なモジュール> (p. 142)

  • モジュール間の結合度を最小化するために、<直接関係のないメソッドへのアクセスをできる限り避ける> (p. 144)

  • デメテルの法則という言葉が出てくるが、法則自身は本書に述べられていない？

メタプログラミング

ここも実践的。

  • <システム設定を変更できるようにしましょう。（略）こういった項目は、本来オプションとして実装されるべきものであり、システムに組み込んでしまったり、決め撃ちで行うものではないのです> (p. 148)

  • <アプリケーションを描写する（略）すべてのデータを意味するために、メタデータという言葉を用いています> (p. 149)

  • <できるためメタデータを経由してアプリケーションの設定と駆動を行うべきなのです> (p. 149)

  • <設定用メタデータはプレイン・テキストで表現することをお勧めします> (p. 151)

時間的な結合

  • ワークフローを分析することで、アクション同士の本当の依存関係を明確にする (p. 156)

  • <並列アクセスからすべての大域変数や静的変数を保護すること> (p. 159)

  • C 言語の strtok を槍玉に上げて、並列性を意識した設計の重要性を説く。

単なる見かけ（ビュー）

Observer パターンと MVC の話のようだ。

  • <he sees what he wants to see and disregards the rest> (p. 161)

  • JTree (p. 166) の話が面白いので、後で調べる。TreeModel, TreeCellRenderer, TreeCellEditor を実装すればそれで OK なものらしい。

ホワイトボード

このセクションではホワイトボードシステムとやらについて議論している。

  • <証人そのものを貼り付ける> (p. 172)

  • <単一かつ整合性のあるインタフェイス> (p. 172)

  • <冷蔵庫の横のメッセージ・ボードや仕事場のホワイトボードを使っていますか？それが効率的なのはなぜでしょうか？> (p. 174)

    使っているし、確かに効率的だと思う。

    自宅のケースでは、文字を書くのではなくて、振込用紙とか申込用紙とかをマグネットで直貼り。外出時にひっぺがして、現地へ直接持って行けるようにする。

    かばんに入れてもよさそうだが、なんでホワイトボードなんだろう？

第 6 章 コーディング段階

  • <プログラムを長期間正確かつ生産的なものとするためには、熟考や熟慮を要する意思決定が常に必要なのです> (p. 175)

  • <動かなくなった時もその理由が判らなかった> (p. 177) というようなことにならないように、偶発的なプログラミングをしない。

  • <開発者間で矛盾している> (p. 179) 仮定があってはならない。

  • <信頼のおけるものだけを前提としてください。（略）そういった区別が行えない場合は、最悪の仮定を置いてください> (p. 179)

  • <陳腐化したコードがあれば、それが全部であっても置き換えるのです> (p. 180)

  • \(O()\) 記法にも弱点はある。2 つのアルゴリズムのオーダーが同じであっても、一方が他方の 1000 倍速いという場合もあり得る (p. 182)

  • n が小さい場合は特に注意 (p. 185)

リファクタリング

  • ソフトウェアは建築と言うよりもガーデニングに近い (p. 188)

  • <ガーデニングのメタファーはソフトウェア開発の現実にかなり近い> (p. 188)

  • <リファクタリングが必要なものの記録を取っておきましょう> (p. 189)

テストしやすいコード

  • <集積回路を接続していくようにソフトウェアのコンポーネントも接続していけるようになるべきである> (p. 193)

  • <初期の段階からソフトウェア中にテスト機構を構築> <接続する前にテスト> (p. 193)

  • <モジュールに対する一通りのテストを一定の条件下で行い、実際の幅広い世界でどのように反応するかという感触をつかむ> (p. 194)

  • 単体テスト作業イコール <テストを行うコードそのものの作成作業> (p. 194)

  • 単体テスト用コードは <手近などころに置いておく必要がある> (p. 196)

  • <より大規模なプロジェクトであれば、各テスト・コードをサブディレクトリ中に置いておくことをお勧めします> (p. 196)

  • シェルスクリプトも活用できる (p. 197)

  • <Kent Beck と Erich Gamma の xUnit を調査してみてはいかがでしょうか> (p. 198)

  • <貧弱で整合性の取れていない診断フォーマットは、単なる「たれ流し」> (p. 200)

邪悪な魔法使い（ウィザード）

  • <作り出されたコードの意味が本当に理解できていなければ、彼は自分自身をだましていることになるのです> (p. 203)

  • ウィザードを使うなと言っているわけではない。むしろ<自身でそれを記述することに 1 セクションを丸ごと割いています> (p. 203)

  • ウィザードが生成したコードは、開発者のアプリケーションに統合され、その一部になってしまうのです> (p. 203)