41 常に並列性を意識した設計を行うこと
並列的な考えかたを用いてアーキテクチャの設計が行えるようになれば、それを
広域分散可能な多くの並列サービスに対しても応用可能になるはず。
並列性のないアプリケーションに後づけで並列性を付加するのは難しいので、
始めから並列的な設計をしておく。
42 モデルをビューから分離すること
Publish/Subscribe(イベント生成側とイベント受け取り側)
すべてのイベントを1つのルーチンで受けとるのは正しくない。
巨大なif文を使うくらいなら、まず設計を見直すことを考える。
オブジェクトには必要な情報のみが入っているべきであり、
それ以外の不必要なイベントを受けとるのは好ましくない。
データを弄らず見た目だけを弄るファイルが必要となる。
例：
特定のデータを違う方法で表示させるとき、モデルからデータを
コピーするよりそれぞれのビューファイルを作成したほうが効率がよい。
この考えかたを応用したのがRoRなどのMVCのコンセプトである。
また、MVCを使うにあたり、GUI開発だけに拘る必要はない。
43 ワークフローを協調させるにはホワイトボードを使用すること
ワークフローを使えば、考えられる組み合わせと状況をすべて処理することが
出来る。
ホワイトボードを使えば必要な情報を的確に抽出することができるし、
関係者たちを協調させるのにも役立つ。
偶発的プログラミング
44 偶発的プログラミングを行わないこと
もし何らかのルーチンを呼び出す場合は、ドキュメント化されている振舞いのみを
前提とするようにする。
慎重なプログラミングを行うためには、
- 常に何をやっているのかを意識する
- 自分の仮定をドキュメント化する
- 目隠しでコーディングをしない(理解していない手法でコーディングはしない)
- 信頼のおけるものだけを前提とする。偶然や仮定に依存してはいけない。
- コードをテストするだけではなく、仮定をテストする
- 作業に優先順位をつける
- 過去のしがらみにとらわれない。既存のコードによって未来のコードが影響されないようにする
45 アルゴリズムのオーダーを見積ること
O()記法とは、n件のソートを行うソートルーチンがあり、それがO(n^2)時間かかるばあい、
ソートは最悪の場合n^2だけ時間がかかる、ということ。
O(1) 定数
O(lg(n)) 対数(バイナリサーチ)
O(n) 線形(順次検索)
O(n lg(n)) 線形よりも悪いがさほどわるくない(クイックソードなど)
O(n^2) 2乗(選択ソートや挿入ソート)
O(n^3) 3乗(2つのn行n烈行列の積)
O(Cn) 指数 (巡回セールスマン問題)
ちなみに巡回セールスマン問題については、
wikipediaなんかを参考のこと。
