「リファクタリング(第2版): 既存のコードを安全に改善する」の 1 〜 4 章を読んだので

目的

コード改善したい！

• そもそもどこまでやるべきなのか？どこまで時間をかけるべきか？
• review は？
• 動作を変更しない保証は？QA のやり方は？
• データベースの変更が絡む場合は？

などたくさんの課題を思い付きますが、その答えを求めてちょっと本を読んでいるので中間共有

本たち

[Reading]
(1) リファクタリング(第2版): 既存のコードを安全に改善する (OBJECT TECHNOLOGY SERIES)

[TODO]
(2) レガシーコード改善ガイド: 保守開発のためのリファクタリング
(3) データベース・リファクタリング

[関連]
(4) Tidy First? ―個人で実践する経験主義的ソフトウェア設計

---

ここからは
「リファクタリング(第2版): 既存のコードを安全に改善する」の 1 〜 4 章の自分なりのまとめ

テストがない場合とかの対処は「レガシーコード改善ガイド: 保守開発のためのリファクタリング」を読めとのこと

なので、こんな感じを目指すといいかも！みたいな感じで書きます

---

ここでの「リファクタリング」とは

漠然とコードを改善することではなく

• 変数名の変更
• 一部を別関数に切り出す
• for を map にする

のような、型化されたコードの変更のことを言います

この本では、テストがある前提で

(A) "リファクタリング"
(B) コンパイル、テスト
(C) コミット

の塊を繰り返していけば安全にどんなコードでもリファクタできますということが書かれています

まだ読んでいないですが、本の後半には「リファクタリング」の一覧が載せてあるので、それを参考にしながらこのサイクルを回すように意識すれば良いみたいです

とはいえ

• リファクタリングしていくとどんな世界が待っていますか？
• 良いコードって定義できますか？
• 機能開発中に「リファクタリング」はありなのか？
• リファクタリングが長期に渡ることはありますか？
• テストがない場合に、基本的にはテストを書くとして、どんなテストを書けば良い？
• リファクタしたくなるサインは？

とかあるので最後にそれについて見ていけたらと思います。もう少し読み進めたら、またまとめたいと思います

リファクタリングしていくとどんな世界が待っていますか？

良いコードって定義できますか？

単なる好みを超えて、良いコードはどれだけ変更が容易なのかで決まる

機能開発中に「リファクタリング」はありなのか？

この本では推奨されている。ただし、同時にではなく交互にやるように！とのこと

リファクタリングが長期に渡ることはありますか？

上のようなリファクタリングの積み重ねなので、ありえない

テストがない場合に、基本的にはテストを書くとして、どんなテストを書けば良い？

• やばそうな箇所の happy test
• 境界値

コスパとの兼ね合い。ですが、テストをやりすぎるケースはほとんどない。絶対書いた方がいいだと↑

[これは個人の感想] 1 つ目は、そもそもコードの質のフィードバックにもなりそう

リファクタしたくなるサインは？

• 不可思議な名前
• 重複したコード
• 長い関数
• 長いパラメータリスト
• グローバルなデータ
• 変更可能なデータ
• 変更の偏り
  ...

確かにって感じですね！それぞれごとに、どの「リファクタリング」を適用するのがいいか書いてありました