まだ読んでる最中なのでwipです。おっ、となったところだけメモしておきます。文章も雑だと思います。全部読んだらまとめます。
全体的に思ったこと
例えば、大きな関数のなかの処理の一部を別の関数に切り出す、といった普段当たり前にやっているようなことにも「Extract Function」のように名前を付けているのは良いと思った。
とりあえずパターン化して名前を付けておけば少しでも頭を使う機会を減らせる。
思考停止で「とりあえず〇〇パターンを適用しておこう。」といった具合に。
Chapter 1
page 5
The first Step in Refactoring(はじめにやるべきこと)
リファクタに取り掛かるときはじめにやることはいつも同じ。
対象の箇所に十分なテストコードがあることを確認する。
明示的にそうとは書いていないが、テストコードがなければ書く必要があるということを示唆している。
当然といえば当然の話だけど、テストコードもない状態でリファクタに取り掛かったことが(そして失敗したことが)何度もある身なので今後これは絶対に守る。
page 10
名言的なやつ
Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.
動くコードなんて誰でも書ける。良いプログラマはリーダブルなコードを書く。
非エンジニアの人にも知っておいてもらいたいです。
単に動くコードなら誇張無く小学生でも書けると思います。
(基本的に)プログラミングの難しさはプログラムを動かすことではないんです。
動いているプログラムに新しい機能を追加するときや、既存のコードを修正するとき、その既存コードが読みやすいかどうかで死ぬほど難易度に差が出ます。
そして、自分以外の誰かが読みやすいコードを意識して書き続ける、というのがとても技術的にも精神的にも難しいんです。。
これを完全に放棄しているように見えるエンジニアもよくいます。
page 12 - 14
この章で一番うおってなるやつ。
正直、自分の言葉でこれを相手に納得できるように説明できる自信がない。
一回のループで複数の処理をしている箇所をいくつかの関数に切り出して、ループの回数は増えるけど読みやすくなる、ということをやっている。
自分はファウラー氏の説明で多いに納得できた。
が、よほどレビュアーを信頼していないとこのPRは出せない、、、
これは本を買って読んでほしいです。
RefactoringとOptimizationは分けて考えろ。リファクタが終わったあと、必要であればパフォーマンスを改善すれば良い。みたいな感じのことを言っている。
Chapter 2
page 55
ファウラー氏が受ける質問で多いのが、「えらい人にリファクタリングをどう説明したらいい?」というもので、回答はというと「説明なんかするな」と。
(僕の意訳です)
これをざっくり説明すると、以下のような感じ
「我々はプロだ。やり方はある程度任されてしかるべきだ。考えられるかぎりできるだけ速く開発を行いたい。速く開発するためにリファクタリングは必要だ。だからリファクタするのが当たり前だ。」(日本語雑ですいません、あとできれいにします)
自分の解釈だけど、開発とリファクタリングを分けて考えてないように感じた。
我々が行っているのは「開発」です。と。
これなら「(リファクタをえらい人に)説明なんかするな」は意味が通る。
ちなみに本を読めばわかるんですが、ファウラー氏は機能を追加するとき、修正するとき、大体リファクタを合わせて行っているらしいです。
page 56
なんのためにリファクタをやるのか忘れるな。
"We refactor because it makes us faster - faster to add features, faster to fix bugs"
我々はリファクタリングを行う。なぜならそれが開発速度を速くするからだ。
「キレイなコードを保つため」や「良いプログラマの習慣だから」だったりのモラル的なことを理由にリファクタを正当化しようとするのは危険だ。
リファクタの目的はあくまで開発を速くすること。
重要かもしれないので補足
一回のリファクタに掛ける時間はせいぜい数分から最高でも数時間で、それ以上(数日とか)掛かるようであればそれはもはやリファクタではない、といったことを言っています。
page 60
if you have a big legacy system with no tests, you can't safely refactor it into clarity.
The obvious answer to this problem is that you add tests. But while this sounds a simple, if laborious, procedure, it's often much more tricky in practice.
のあたり。理想論だけでなく現実的な話が続きます。こんど続きについて書きます
page 64
リファクタとパフォーマンスの話ふたたび。
リファクタは、短期的にはソフトウェアを遅くするかもしれない、しかしリファクタは、ソフトウェアをパフォーマンスチューニングを行いやすいものにする。
補足
上には「遅くするかもしれない」と書いたけど、実際には「遅くする」と書いてます。
原文: It slows the software in the short term while I'm refactoring, but makes it easier to tune during optimization.