【開発哲学４_９】〜『リファクタリング 既存のコードを安全に改善する』〜第９章 条件記述の単純化〜
感想
普段の現場では、みんな無意識でやっていることを
よくもまあここまで難しく、わかりにくい造語をしながら書けるもんだなあ。
って印象。
詳細
見出しとしては、
条件記述の分解
条件記述の統合
重複した条件記述の断片の統合
制御フラグの削除
ガード節による入れ子条件記述の置き換え
ピリモーフィズムによる条件記述の置き換え
ヌルオブジェクトの導入
表明の導入
てな感じ。
最初のところから読み始めてすぐに
「小分けにしてるだけで、こんなことしたら読んでわかるコードにならないし、美しくなくないか？」
って思ったんだけど（条件記述の統合など）。
やっぱり、後半の表明の導入なんかで、完全に前半の条件記述の統合を自分で打ち消しちゃったね。
複雑な条件記述やネストが深い条件記述は、
こんな小手先の小細工をするよりも、
①＜ルーチンを小分けにできないか＞
↓（①でダメならば）
②＜設計自体を変更できないか＞
で対応するかな。
ルーチンをうまく小分けできれば、
制御文の「入り口ひとつ出口ひとつの法則」も実現できることが多いし。
「入り口ひとつ出口ひとつの法則」が守れないのは、リファクタリング以前に設計が悪いだけ。
ルーチンを小分けにしたり、メソッドを抽出しても
呼び出されるのがループの中だと、小分けにした後で実行結果が想定外になる可能性は常にあるから、どんなに簡単なものでも、リファクタリング後は必ずすぐにコンパイルして実行し、実行結果が期待値どおりか確認するけどね。
こんな相殺する複数のやり方だけをカタログで紹介してると
「コードを起こす段階で読みやすさなんて意識しなくても、色々なやり方があるから、後で直せばいいや」
って人が増えるし、そういう人ほど、結局最初から美しいコードを書けてないから、検証とデバッグに時間がかかって、時間がなくなり、
「コードが汚いけど、要求どおりには動いてそうだしいいや。」
で結局やらないんだよねえ。
👉プログラマに限らず、'後で'と'いつか'はいつまでも来ない。
てか
これだけ小難しくリファクタリングをする暇があったらコードを書いてる対象の設計を見直した方がマジで早い
リファクタリングって要は、
読みにくい、汚いコードを、
綺麗に、美しいコードにし、
保守性とバグの発生を極力高める
だけのものですぜ。
👉読んでわかるコードにしないとリファクタリングの意味はない。
何が伝えたいんだろう、、、。
ここまで読んでくると
ただリファクタリングよりも、
コンストラクションがいかに重要か
がわかるな。
まとめ
💃わからない人や知らない人に説明する時、
頭がいいだけのアンポンタンは、
難しいことを難しく説明し、
賢い人は、
難しいことをわかりやすく説明する🕺
参考記事
コンストラクションの総まとめ的な章の感想はこちら
この記事が気に入ったらサポートをしてみませんか？