リファクタリング-プログラミングの体質改善テクニック:付箋


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

p96 単体テストと機能テスト
p97 バグがきたらまずテストを書くtest
p103 リファクタリングカタログ
以降舐めるように見る
p104 ビジネスロジックならぬビジネスオブジェクトとは?
p116 メソッドの返す値は一つにすべき(タプルで返しちゃう自分はだめな人)
p117 メソッドのインライン化:コードをへらす
p119 一時変数を消去してコードを減らす
p124 説明用変数の導入:一時変数を利用して計算式を分離
p128 一時変数の分離:変数の利用目的は一意になるように
p132 final地獄
p135 メソッドオブジェクトによるメソッドの置き換え:強力だがコード量を犠牲にしてしまう。もう一度読みたい
p157 移譲の隠ぺい:よく分かってない
関連するオブジェクトは減らす
p164 局所的拡張の導入:とばしたのでもう一度読み直したい
p171 自己カプセル化フィールド:これももう一度読み直したい、内部にあるメソッドでもget/setを利用すべきか
p175 オブジェクトによるデータの置き換え:文書をもう一度読み直したい
p179 値から参照への変更,何が実態を管理すべきか
p186 オブジェクトによる配列の置き換え:ラッパ
p189 観察されるデータの複製、このパターンもういちど
p197 単方向関連から双方向への変更、このリファクタリングが良く働く場所とは?
p208 コレクションのカプセル化
p217 データクラスによるレコードの置き換え:レコードとは?
p227 State/Strategyによるタイプコードの置き換え
p232 フィールドによるサブクラスの置き換え
p238 条件記述の分解:当たり前っちゃ当たり前では…?
p241 サンプルプログラム:フィールドによって条件分岐しているのなら、メソッドを抽出した際もフィールドの値を利用すべき
p250 ガード節による入れ子条件記述の置き換え,COND節
p255 ポリモルフィズムの条件置き換えにはクラス作成のコード量増加があるが、どの程度で変えればいいのか
p260 ヌルオブジェクトについてもう一度
p271 メソッド呼び出しの単純化:飛ばし
p300 setメソッドの削除
p320 フィールドの引き上げについて:再読
p328 引き下げについて
p362 継承の分割