リファクタリングの目的・パターン・思考 joker1007さん講演
以下の勉強会に参加してきました！！
その内容についてのメモです。
長く続いたソフトウェアは複雑化する
特に顧客がつくと簡単に止められなくなる
機能や動きを維持しつつ開発しなくてはならない
開発速度が遅くなる要因
ある機能に影響するコード量が多く理解しきれない
機能同士が密結合している
リファクタリングが目指すもの
読みやすさの向上
疎結合か
複雑なコードの削除
これらを解決することで開発速度アップ
危険シグナル
読みズラくて分からない（怒りの沸点の低い人をレビュアーに入れる）
このメソッドがそこにある理由
他のオプジェクトのメソッド呼びすぎ
メタプロ多すぎ
作業見積もりから乖離ありすぎ
やりたいことに比べこんな複雑なわけがない
いつやるのか
イラついた時
フィーチャ開発時に作業見積もりに混ぜる
まとめて注力する期間を用意
破綻寸前
息を吸うよに日常的にやるのが理想
リファクタリング手法
メソッド分割
１つのj長大なメソッドを段落ごとに名前をつけて別メソッドイン抽出する
効果 読みやすさの向上、モックポイントの挿入
しかし本質的な複雑さには変化がない。
処理の粒度を揃えることが重要。リーダブルコード
完全コンストラクタ
不要なパラメータ私の無駄を避けてオブジェクト生成時に用意できるものを全て揃える
効原則に反するコードを適切な場所に配置し直す
効果 オブジェクトを普遍にしやすい
責任範囲の適正化
デメテルの法則や尋ねるな命じろ、の原則に反するコードを適切な場所に配置し直す
クラス分割
責任が多すぎるクラスをサブクラスに分割する。
名前付けができる、てスタビリティの工場
機能追加の際の影響範囲の限定
パラメータオブジェクト
検索条件等、パラメ０たが大量かつデフォルト値があったりなかったりする場合
ストラテジーパターンもしくはステートオブジェクト
オブジェクトのタイプや状態によって処理内容が変わる場合に処理を専用のオブジェクトに移譲する
gem化
汎用化できそうな処理をgemとして分離する。
ミドルウェアに頼る
DBスキーマ修正
仕様変更
ユーザーの体験を損ねない範囲で規制を緩和するように仕様変更しコードを簡易化する。
機能削除
価値の低い機能ををもそも廃止する。
リファクタリングに必要な思考
コードの良し悪しについて指針を持つ
何がなくせれば何ができるか考える
既存のコードを信用するな
仕様は絶対ではい
追記
スライドをツイッターでシェアしてくださっていたのでそのリンクです！！
