Refactoring 2nd Editionを記念したMartin FowlerのWebinarメモ

Martin Fowlerが[Refactoringの第二版](http://www.informit.com/store/refactoring-improving-the-design-of-existing-code-9780134757599?ranMID=24808) を記念してThoughtworks主催でWebinarを開催しました。
内容を箇条書きですがメモってみました。

:warning: 雑に取ったものなので、誤字や合っていない部分もあるかもしれません。気付き次第、修正していきます。また、録画したものが、もし公開されたら、それをベースにもう少し整地にできれば、と思います。

#### なぜ新しい版？
- 基本的には変更はいらない
- とは言え
    - 言っているコードとかが古い（`java.util.vector`とか）
    - Javaでない言語とかも念頭に入れたい

#### リファクタリングでないものは？
- 見た目が変わらない変更
- 内部的な変更
- 理解しやすくするため
- 新機能開発とリファクタリングは行き来するもの

#### まだまだ足りない？なぜか？
- まだ認知が低い
- 新しいエンジニアが入ってきている
    - 教育が常に必要

#### 新しい人への助言
- 実践あるのみ
- メンターがいると良い
    - 知識を伝達するため、というのも本の狙いでもある。

#### リファクタリングしどきは？
- コードの意味が分からないとき
- 意味がわかったら、それをまたコードに反映させるべき
    - 次の人にわかりやすい
    - Ward Cunnighamより
- 次の変更をやるときにできない場合
    - リファクタリングしてからの方が速いときとか。
    - Kent Beckより

#### 20年間で変わったことは？テストとか少しずつ機能開発とか
- 20年前よりも広まっている
- ただ当然これからも浸透していくのは時間はかかる
- メンターから伝える方が本よりも効果があるから、僕らが伝えていくことが大事。

#### 変更したがらない人がいるが、どうやって伝えれば良い？
- 伝える
- リーダーが見せる、というのも大事
- エンジニアがやらないものだと思いこんでいる可能性がある（リーダーがそう思っていなくても）

#### バランスは？
- 判断力が一番大事

#### 新しい版と古いやつの違いは？
- リファクタリングのいくつかは削除した。
    - それほど重要でないやつ（uni-diretional）
- 新しいやつの追加
- オブジェクト指向でない書き方
- JavaScriptで書き直し
    - ただ言語の変更点は特に意味がない。
    - コアの

#### 関数型のトレンドの影響は？
- 特にない
- 参照透明性とかはもちろん良いけど、別に大事な点ではない。

#### パフォーマンスへの影響は？
- 分かりやすくするためにしていれば、影響はないはず。
- とは言え、監視をすることは必要。
    - パフォーマンスは計測から始めないといけない。

#### 継続的にリファクタリングでレガシーコードの弊害を防げるか？
- もちろん。
- その効果が分かったから、本を書いた。

#### リファクタリングの良いメトリックはあるか？
- 良いのは無さそう。
- 行数が多い関数
- コードの複雑性

#### メトリックはリファクタリングをする理由になるか？
- しょっちゅう更新されるファイルとか

#### 他にオススメの文献は？
- [Database Refactoring](https://www.amazon.co.jp/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515)
- 自分のサイトにあるエッセイも参考になる
    - [Evolutionary Database Design](https://martinfowler.com/articles/evodb.html)

#### アーキテクチャのリファクタリングについて、どう思うか？
- [How to extract a data-rich service from a monolith](https://martinfowler.com/articles/extract-data-rich-service.html)
- 平行に走らせて、なるべく小さい単位で移行していくとかは同じ考え方

#### CIについて
- 長時間やっているブランチは厄介
- もっと頻繁にmaster（メインのブランチ）にマージしていくことが重要。
    - 他の変更を自分の作業に含めることができる
    - コンフリクトを早く気付くことができる
- 長くても1日1回はマージするべき
    - やってみると意外と簡単で、怖い作業でなくなる。
- ただ今でも移行できない人は多い。

#### ビジネスとか上司をどうやって説得するべきか？
- そもそも話すべき内容でない。
- プロとして任されているのだから、そこを含めてベストな判断をしてしかるべき。
- つまり、リファクタリングもビジネス的には重要である。
- 正当化するとき **モラル的なことを言ってはダメ**
- 経済的な理由を言うべき。
    - 今後の開発のスピードを上げられる
    - 今後の開発で新機能がやれるようになる

#### コード以外への影響は？アーキテクチャとか
- もちろん。
- 小さい変更をつなげていくことが重要
    - 変更は表に見えないものである
- この能力を鍛えるにはいろいろやってみて練習あるのみ

#### デザインパターンとの関係は？
- いきなり完璧にパターンを適用することを考えなくて良い
- （少しずつ）パターンを目掛けて動くべき。

#### ペア・プログラミングをどう思うか？
- 良いと思う。
- エンジニアの経験年数はあまり関係なく、技術によって双方もあり得る。
    - Reactの話であれば、自分はジュニアになる
- コード・スメルに気付くことを鍛えるのも重要
    - 経験の浅い人でも直し方が分からなくても気付ければ、より経験のある人に聞けば良い。

#### 完全に書き直しをした方が良い場合はあるか？
- プラットフォームが移行できないとき
    - 言語とか環境とか
- テストが不足している場合
    - リファクタリングのときはもちろんテストがあった方が良い。
- とは言え、明確な答えはない。

#### リファクタリングをするべきでないことはあるか？
- もう変えなくても良いと分かっている部分とか。
    - もう変えないなら、分かりやすくする必要はない。
- いきなり直すのではなく、ちょっとずつ直すことを意識するべき。

#### TDDとリファクタリングの関係は？
- 両方共同じエクストリーム・プログラミングから来ている
- [Workflows of Refactoring](https://www.youtube.com/watch?v=vqEg37e4Mkw)

#### テストがなくてもできるか？
- 障壁にはなる。
- Provably Safe Refactoringという研究もある
- あまりやるべきではなく、テストがとても重要。

#### 最後にメッセージ
- リファクタリングの大事なことは **やってみること**
- 少しずつやって、頻繁にマージすることが大事
    - すぐにロールバックできる
- ゴールが明確だからコード・スメルから始めるのがオススメ