学習メモ：プリンシプル オブ プログラミング

3.18 ポリシーと実装の分離

ポリシーと実装は別モジュールにする。
実装は安定だが、ポリシーは不安定であるため。

3.20 参照の一点性

参照透過性

• 呼び出しの結果が、引数のみに依存する
• 呼び出しが、他の機能の動作に影響を与えない

3.46 表現性の原則

情報はデータに寄せて表現する。
データはロジックよりも御しやすいため。

3.62 シェルスクリプト活用

Use shell scripts to increase leverage and portability.

グルー言語としてシェルスクリプトを使う。

3.64 フィルタ化

ソフトウェアをフィルタとして設計する。ソフトウェアの本質は、データを「処理」することで「生成」することではない。
データ入力には標準入力を使用し、データ出力には標準出力を使用しよう。

6.2 契約による設計

6.3 防御的プログラミング

契約の内容を、あらかじめ関数のコメントに記す。
契約履行のチェックのためのコードを、アサーションで表現する。

バリケードの外側では、データに関して何かを想定する（こうなるはずだと決めつける、期待する）のは危険である。 関数に渡すデータの妥当性を、関数を呼び出す前に検証して不正な場合はエラー処理する。

バリケードの内側に渡されるデータは（バリケードを通過する前に）消毒済であるはずなので、 バリケードの内側で不正なデータを検出した場合はデータのエラーではなく、コードのエラーである。コードの実行の審議をコード事態で検査するアサーションを適用する。

7.2 コンウェイの法則

アーキテクチャは、それを作った組織を反映する。 例えば、3チームでコンパイラを作る場合は「字句解析」「構文解析」「コード生成」の3パスのコンパイラができるが、4チームで作る場合には「字句解析」「構文解析」「コード最適化」「コード生成」の4パスのコンパイラができる。

アーキテクチャを設計して、それを十分に検証した後に組織再編するのがよい。ただし、「データベースチーム」「メインフレームチーム」「Webサーバチーム」「テストチーム」のように、技術分野でチーム分けをおこなうと、どんなに小さな機能の実現においても、互いに他のチームの作業に依存しすぎて、大量のコミュニケーションが必要となるため QCD いずれも悪化する。