はじめに
リファクタリング(第2版): 既存のコードを安全に改善する
という書籍を読み始めました
せっかくなので要点をメモしておきます
第１章 リファクタリングー最初の例
流れとしては、最初に100行くらいの改善前のコードがあって。
それを以下の３つのステップで改善していく流れ。
- 大きめの処理は関数として切り分ける
- 計算部分とフォーマット部分の処理をそれぞれ別の関数に分割する
- switch文で処理を分けていたのをクラスとインスタンスを使ったものに置き換える
感想
最初に無駄にリファクタリングの歴史とか効用とかをつらつら書くんじゃなくていきなり最初にリファクタリング前のコードを載せてくれてるのが良い！
まずそれを見て、自分だったらどうやってリファクタリングするかな〜って考えて。
それから答え合わせ的に先を読む、と。
うん、こういう作り大好き
リファクタリングも、「な、なるほど〜！」と思うやり方がたくさんあってめっちゃ勉強になった
正直技術書を舐めてました、、w
技術なんて手を動かすのが一番早くて詰まったらググればOK!的に思ってたけど今後は技術書も読むべきだな〜と思わされた
あと解説がめちゃくちゃ丁寧
修正した箇所だけじゃなくてその前後のコードも毎回贅沢に載せてくれるので変更箇所が分かりやすい
訳もめっちゃ分かりやすい
分かりにくい訳とかは一切ない。
安くはないけどすでに買って良かった〜感を感じてるw
よし、２章も読むぞ〜
第２章 リファクタリングの原則
「リファクタリングとは？」とかメリデメとかの話
感想
優れた設計とまずい設計のどちらが開発時間がかかるか？のグラフが面白かった
一見すると優れた設計の方が早く作れそうだけど、実はコードが少ない内は逆なんだよね
最初は適当なコードでぐわーっと書いちゃった方が早い
けど、それだとコードが大きくなるにつれて時間がかかるようになるのよね
で、「あ〜もう最初からやりたい涙」ってなるw
まさにbot開発で経験済みだから超納得した
体感的には1000行超えるともう適当コードじゃ詰む
例えば仕事でツールの納品のやつとかで小さいコードだったらもう変に構造化を意識しすぎずにぐわーっと書いちゃった方が早いかもしれない
お客さんがコード見ない人でエンハンスは担当しない、とかだったらその方がいいかも
けどエンジニア魂的には良い感じの設計にしたくなるからバランスが難しいね、、
＞変更の要求が来たら、まず変更が用意になるようにする。それから容易になった変更を行う
なるほどな〜
第３章 コードの不吉な臭い
どのタイミングでリファクタリングすべきか？というお話
もちろん明確な機銃はない
不吉な臭いを感じたらリファクタリングしよう
感想
なんか少し抽象的な話が多くてう〜んという感じ
具体的な方がが好きだ、、
あと全体的に後ろのページの参照が多すぎる
どう読んだらいいのか分かりにくい