11.13 表明を使う 4種類の使い方 正しいソフトウェアを書くのを手助けする 文書化の支援 テスト・デバッグ・品質保証をサポートする 耐障害性をサポートする 表明を正しいソフトウェアを書く道具として使う
11章 契約による設計:信頼性の高いソフトウェアを構築する テーマ* 信頼性を確保するための手法として 「表明」の概念を説明 キーコンセプトは「契約による設計」 例外処理は12章 11.1 基本的な信頼性のメカニズム
11〜12章は今までと少し趣の異なる並列化の話 データベースを適用する上でのポイント DBを適用する上でのポイント サイズ/性能に余裕を持たせる必要 (なぜここでこういう話が?) 複数データベースの連動
今までの説明 → テストの可読性、 有用な診断メッセージ 今回 → 関係あるコードが壊れてる時だけ失敗させる この章の趣旨を一言で表すと… 「何が起こるべきなのかを正確に指定せよ。余計なことを一切指定するな」 情報の表現ではなく中身をテストする 例: 顧客を検索するためのクラスのモック
1章 テスト駆動開発のポイントとは? この章の概要 開発における本書の基本的な考え 開発における「予期せぬ変化を予期する」 (anticipate unanticipated changes) 開発に「入れ子になったフィードバックループ」を形成する ソフトウェアの「 内側と外側の品質」
3 Concurrent Objects – 並行オブジェクト https://gist.github.com/3304936 並行オブジェクトにおける correctness の解説(3.1 ~ 3.5) Quiescent consistency, Sequential consistency, linearizable (最適化のために、並行オブジェクトは実際に実行されたタイミングとのズレが生じる。それをどこまで許容するかの線引きを行う、という認識) 付属の特性 (3.6、3.7)
Linked Lists: The Role of Locking 9.1 Introduction データ構造への各処理をロックでラップした並列化対応 coarse-grained synchronization (粗い同期)と呼んでいる スケーラビリティがあまり良くない