今回がラスト
○第１４章 継続的改良
コマンドライン引数を解析するArgsクラスを題材に著者がリファクタリングをしていく過程を追体験できる。
最初に最終結果が提示されたため、それがスタート地点かと思ってびっくりしたが実際は真逆だった。
最初に最終結果を見せなければもうちょっと追って見る気力が出てきたのに。
○第１５章 JUnitフレームワーク
JUnitに対して著者がリファクタリングをしていく過程を追体験。
特記事項は無いので割愛
○第１６章 SerialDateのリファクタリング
OSSのライブラリに対して著者がリファクタリングしていく過程を追体験。
特記事項は無いので割愛。
○第17章 においと経験則
筆者によるチェックポイントのまとめ、よくまとまっていて、レビュー時に使えそうなので全て写経!
- 不適切な情報: 作者、更新日、更新履歴は不要
- 退化コメントを削除：コメントは陳腐化するのでいらなくなったらこまめに削除
- 冗長なコメント
- 記述不足のコメント
- コメントアウトされたコード：読みにくくなる以外の効果は無い
- ビルドに複数のステップを要する：1操作でできるべき
- テストに複数のステップを要する：1操作でできるべき
- 多すぎる引数
- 出力引数：オブジェクトの状態を積極的に変更する
- フラグ引数：2つの関数に分けよう
- 死んだ関数：呼ばれてない関数は削除する
- 1 つのソースに複数言語を混ぜない：コメントにHTML形式のレイアウトを入れない とか
- あって当然の振る舞いが実装されてない：大文字／小文字の区別とか
- 境界値に対する不正確な振る舞い：きちんとテストすること
- 安全軽視：コンパイラの警告はきちんと対処する
- 重複：DRY! Once and only once
- 抽象レベルが正しくないコード
- 継承クラスに依存したクラス
- 情報過多：メソッドは少ないほどいい、インスタンスは少ないほどいい
- デッドコード：決して通ることが無いif文は無いか、カバレッジ計測ツールで確認
- 垂直分離：変数宣言は使用場所の近くで
- 不整合：規約の選択は慎重に、決めたらコロコロ変えない
- 雑然：未使用変数、意味が無いコメント、呼ばれない関数は削除する
- 人為的な結合：意図の無い結合は避ける
- 機能の羨望：実装を他のクラスにさらすべきではない
- セレクタ引数：小さな関数に分割しよう
- 不明瞭な意図：計算過程を変数名で説明するとよい
- 責務を持たせる場所の間違い：直感的にあるべき場所に置く
- 不適切なstatic
- 説明的変数を積極的に使う
- 関数名は名は体を表すべき
- アルゴリズムを理解する
- 論理的な依存性を物理的なものとする
- if/else, switchよりも多態を使う
- 標準規約に従う
- マジックナンバーを定数化する
- 正確であること
- 規約より構造
- 条件をカプセル化する
- 条件の否定形を避ける
- 関数では1つのことに集中する
- 隠れた時間軸上の依存関係を見えるようにする
- いい加減にならないこと：矛盾が生じないように
- 境界条件はカプセル化する
- 関数は一つの抽象レベルを担うべき
- 設定可能なデータは高い抽象レベルに置く
- 推移的なナビゲーションを避ける
- 記述的な名前を選ぶ
- 抽象レベルに適切な名前を選ぶ
- 可能な限り標準の用語を使用する
- はっきりした名前
- 広いスコープには長い名前を割り当てる
- エンコーディングを避ける
- 名前で副作用をあらわす
- 不十分なテストを避ける
- カバレッジツールを活用する
- 些細なテストを省略しない
- 境界条件をテストする
- バグの周辺は徹底的にテストする
- 失敗パターンの傾向に着目する
- テストは高速に実行できるように
これで400ページ弱の本が読み終わったー！
