最適化の原則 - Strategic Choice
最適化の原則磨く前にプロトタイプを作れ。最適化する前にプロトタイプが動くようにせよ。どういうこと？最初にプロトタイプを作るようにすれば、ごくわずかの成果のために多すぎる時間をつぎこむのを防ぐことができます。ボトルネックが何かがわかる前に最適化に走ると、設計を台無しにします。透明性や単純性を犠牲にしてスピード、あるいはメモリやディスクスペースの節約にこだわったあげく、コードが無理なものになったり、データレイアウトがわかりにくくなったりします。それらは、多くのバグを生み、莫大な作業を浪費します。そうしてまで得られたものはといえば、デバッグにかかる時間と比べてはるかに安い、リソース使用量のわずかな節約にすぎません。部分に対する半端な最適化が、全体の最適化の妨げになることもよくあります。設計を半端に最適化すると、「設計全体にわたった大きな効果が得られる変更」ができなくなるので、パフォーマンスが低い
コマンドとクエリ分離原則 - Strategic Choice
コマンドとクエリ分離原則ファンクションは抽象的な副作用をもたらしてはならない。どういうこと？コマンド オブジェクトを修正するために使われる。プロシージャとして実現される。クエリオブジェクトに関する情報を返すために使われる。フィールドとして確保されるか、ファンクションとして実現される。ファンクションについて、クエリに答えるというファンクションの公の目的を超えてオブジェクトを変更（＝副作用）してはならない。どうすれば？メソッドをコマンドかクエリかのどちからに分類し、コメントにもどちらなのかを明記する。クエリに分類されたメソッドは、オブジェクトの状態を絶対に変えない。効果メソッドをコマンドと捉えると、Tell, Don't Ask（求めるな、命じよ）という考え方を強く意識できる。クエリから副作用がなくなれば、ユニットテストもしやすくなる。コマンドとクエリの分類を意識すれば、そのデータを外部から見
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
