Martin FowlerがRefactoringの第二版 を記念してThoughtworks主催でWebinarを開催しました。
内容を箇条書きですがメモってみました。
雑に取ったものなので、誤字や合っていない部分もあるかもしれません。気付き次第、修正していきます。また、録画したものが、もし公開されたら、それをベースにもう少し整地にできれば、と思います。
なぜ新しい版？
- 基本的には変更はいらない
- とは言え
- 言っているコードとかが古い（
java.util.vectorとか） - Javaでない言語とかも念頭に入れたい
- 言っているコードとかが古い（
リファクタリングでないものは？
- 見た目が変わらない変更
- 内部的な変更
- 理解しやすくするため
- 新機能開発とリファクタリングは行き来するもの
まだまだ足りない？なぜか？
- まだ認知が低い
- 新しいエンジニアが入ってきている
- 教育が常に必要
新しい人への助言
- 実践あるのみ
- メンターがいると良い
- 知識を伝達するため、というのも本の狙いでもある。
リファクタリングしどきは？
- コードの意味が分からないとき
- 意味がわかったら、それをまたコードに反映させるべき
- 次の人にわかりやすい
- Ward Cunnighamより
- 次の変更をやるときにできない場合
- リファクタリングしてからの方が速いときとか。
- Kent Beckより
20年間で変わったことは？テストとか少しずつ機能開発とか
- 20年前よりも広まっている
- ただ当然これからも浸透していくのは時間はかかる
- メンターから伝える方が本よりも効果があるから、僕らが伝えていくことが大事。
変更したがらない人がいるが、どうやって伝えれば良い？
- 伝える
- リーダーが見せる、というのも大事
- エンジニアがやらないものだと思いこんでいる可能性がある（リーダーがそう思っていなくても）
バランスは？
- 判断力が一番大事
新しい版と古いやつの違いは？
- リファクタリングのいくつかは削除した。
- それほど重要でないやつ（uni-diretional）
- 新しいやつの追加
- オブジェクト指向でない書き方
- JavaScriptで書き直し
- ただ言語の変更点は特に意味がない。
- コアの
関数型のトレンドの影響は？
- 特にない
- 参照透明性とかはもちろん良いけど、別に大事な点ではない。
パフォーマンスへの影響は？
- 分かりやすくするためにしていれば、影響はないはず。
- とは言え、監視をすることは必要。
- パフォーマンスは計測から始めないといけない。
継続的にリファクタリングでレガシーコードの弊害を防げるか？
- もちろん。
- その効果が分かったから、本を書いた。
リファクタリングの良いメトリックはあるか？
- 良いのは無さそう。
- 行数が多い関数
- コードの複雑性
メトリックはリファクタリングをする理由になるか？
- しょっちゅう更新されるファイルとか
他にオススメの文献は？
- Database Refactoring
- 自分のサイトにあるエッセイも参考になる
アーキテクチャのリファクタリングについて、どう思うか？
- How to extract a data-rich service from a monolith
- 平行に走らせて、なるべく小さい単位で移行していくとかは同じ考え方
CIについて
- 長時間やっているブランチは厄介
- もっと頻繁にmaster（メインのブランチ）にマージしていくことが重要。
- 他の変更を自分の作業に含めることができる
- コンフリクトを早く気付くことができる
- 長くても1日1回はマージするべき
- やってみると意外と簡単で、怖い作業でなくなる。
- ただ今でも移行できない人は多い。
ビジネスとか上司をどうやって説得するべきか？
- そもそも話すべき内容でない。
- プロとして任されているのだから、そこを含めてベストな判断をしてしかるべき。
- つまり、リファクタリングもビジネス的には重要である。
- 正当化するとき モラル的なことを言ってはダメ
- 経済的な理由を言うべき。
- 今後の開発のスピードを上げられる
- 今後の開発で新機能がやれるようになる
コード以外への影響は？アーキテクチャとか
- もちろん。
- 小さい変更をつなげていくことが重要
- 変更は表に見えないものである
- この能力を鍛えるにはいろいろやってみて練習あるのみ
デザインパターンとの関係は？
- いきなり完璧にパターンを適用することを考えなくて良い
- （少しずつ）パターンを目掛けて動くべき。
ペア・プログラミングをどう思うか？
- 良いと思う。
- エンジニアの経験年数はあまり関係なく、技術によって双方もあり得る。
- Reactの話であれば、自分はジュニアになる
- コード・スメルに気付くことを鍛えるのも重要
- 経験の浅い人でも直し方が分からなくても気付ければ、より経験のある人に聞けば良い。
完全に書き直しをした方が良い場合はあるか？
- プラットフォームが移行できないとき
- 言語とか環境とか
- テストが不足している場合
- リファクタリングのときはもちろんテストがあった方が良い。
- とは言え、明確な答えはない。
リファクタリングをするべきでないことはあるか？
- もう変えなくても良いと分かっている部分とか。
- もう変えないなら、分かりやすくする必要はない。
- いきなり直すのではなく、ちょっとずつ直すことを意識するべき。
TDDとリファクタリングの関係は？
- 両方共同じエクストリーム・プログラミングから来ている
- Workflows of Refactoring
テストがなくてもできるか？
- 障壁にはなる。
- Provably Safe Refactoringという研究もある
- あまりやるべきではなく、テストがとても重要。
最後にメッセージ
- リファクタリングの大事なことは やってみること
- 少しずつやって、頻繁にマージすることが大事
- すぐにロールバックできる
- ゴールが明確だからコード・スメルから始めるのがオススメ