Code Compete 第2部 高品質なコードの作成 第5章コンストラクショ

Code Complete 第2版 上　完全なプログラミングを目指して

5.3.5|秘密の隠蔽(情報の隠蔽)
　2種類の秘密
　　情報隠蔽の「秘密」は、大きく2種類に分類される
　　-複雑さを隠ぺいして、特に必要がなければ考えずに済むようにする。
　　-変更の源を隠ぺいして、変更が発生した時に、その影響を1か所に留める。

　　-パフォーマンスの明らかな低下
　　　一般に問題となるのは、コーディングレベルの方である。データ項目への間接的なアクセスが、オブジェクトのインスタンス化やルーチン呼び出しなどを新たに発生させ、実行時のパフォーマンスを低下させるのではないかという懸念だ。それを心配するのは時期尚早である。システムのパフォーマンスを測定し、ボトルネックを突き止めるまでは、コードレベルのパフォーマンスを向上するために最良の方法は、モジュール性の高い設計を行うことである。そうすれば、ホットスポットを突き止めた時に、システムの残りの部分に影響を与えずに、個々のクラスやルーチンを最適化できる。

パフォーマンスが心配なら、それを考慮しながら実装するより、テストにて実パフォーマンスがどの程度のものか確認する工数が必要ということか。
実装時はあくまで疎結合となるよう考慮しながら実装することが第一優先、パフォーマンスが悪いようならそれ用にテストとボトルネック発見の工数を用意して、その中でやるべし、と。
#となると見積り段階でパフォーマンスに懸念がある部分は洗い出す必要があるが、果たしてそう都合良く洗い出せるのか？

5.3.6|変更の可能性が高い領域の特定
　+変更されそうな項目を特定する
　+変更されそうな項目を分離する

　-業務ルール
　-入出力
　-設計とコンストラクションの難度が高い領域
　-状態変数
　　-状態変数としてブール型の変数を使用しない。代わりに列挙型を使用する。
　　-状態変数を直接参照するのではなく、アクセスルーチンを使用する
　-データサイズの瀬谷区

状態変数を分離するという発想はなかった。今のシステムでは列挙型を活用する方式になっており、「状態変数に列挙型を使用」することはできている。
アクセスルーチンを利用した状態変数の参照はやっていない。ただ、そこまで難しい判定を行っているわけではない。
#機会があれば参考にしよう

　-セマンティクス結合

#保守フェーズなら仕方ない部分は少なからず出てくると思う。開発時点でこんなことやってはならない

5.3.8|一般的なデザインパターンの検索

#「デザインパターン」という単語が通じるのが会社に一人しかいない、自分もそんなに詳しくはないので、理解を深めねば。

5.3.9|その他のヒューリスティクス
　-ブルートフォースの検討

理論的には正しいがうまくいかない方法にこだわるべきではない。総当りを軽く見てはならない。
#自戒を込めて、どうしても面倒さが先に立って軽く見てしまう。

#3年以上ぶりに再開