先日、今年で最後という YAPC::Asia に参加してきました。
中でも面白かった Benさんのリファクタリングの話についてまとめてみたのでご共有。
（実は職場で紹介する予定だった）
テーマ
- Adventures in Refactoring
発表した人
トーク概要
リファクタリングとは
- 振る舞いやIOを変えずにソースコードを変えること
⇒ あたりまえのことだけど機能を変えてはダメ絶対
リファクタリングをする理由
悪い理由の例
- コードの一貫性を増すこと
- DRYにこだわること
- 抽象化レイヤを追加すること
⇒これら自体は良いこと。でも、これをやるためにリファクタするというのはよくない
リファクタリング結果の成否を測定できないから
良い理由
- Developer がハッピーになること
- パフォーマンスの向上
- 将来の作業への自信（技術的負債の返上）
- Developer の教育
⇒これらはリファクタリングの成果が計測しやすい
どのようにリファクタリングするか
計測できること
- git diff stats でコードが減っている（例：+31 -40だと10行減った）
⇒行数が減るということは、エラーが起こりうるコードが減ったということ - テストカバレッジの改善
- パフォーマンスの改善
- 開発者満足度
スタイルガイドの重要性
- メンバーの方針をあわせる
- スタイルガイドも PullReq でメンテナスしていく
具体的なテクニック
- ”_” でつないでいる長いメソッド名の一部をオブジェクトに切り出す
pull.branch_valid? pull.branch_exists? ↓ pull.branch.valid? pull.branch.exists?
リファクタリングの落とし穴
- 既存バグの修正と一緒にリファクタリング
- 抽象化レイヤの追加によるパフォーマンスの悪化
小さなところからハッピーになる
- 少しづつリファクタリングすること
- リファクタリングと機能追加の優先順位判断
⇒ 機能追加に自信が持てなければリファクタリングすべき - リファクタリングが成功した PullReq には、ご褒美として「:hocho:」を与えること
