新装版 リファクタリング―既存のコードを安全に改善する 感想
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- 作者: Martin Fowler,児玉公信,友野晶夫,平澤章,梅澤真史
- 出版社/メーカー: オーム社
- 発売日: 2014/07/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (11件) を見る
何年も前に読んだが、その時はふーんという感じだったと思う（できる気にだけなってた）
今回は特にコード変更の目的とかも含めて、納得しながら読み進められた
ただ、パターンが多すぎるので一気には頭に入るはずがない
日常的にリファレンス的に見返すべきものだと思う
抜粋は特にしない
正直うまくまとまらなかったので、以降は読みにくいと思う
いつかまとめ直したい
リファクタリングはどうすれば身につくか
完全に個人の経験から
- 書籍 ★
- 一部、実際に手を動かしてみると良いかも
- とにかくやってみる ★★
- 経験あるできる人とペアプロ ★★★★★
- 自分が教える立場でペアプロ ★★★
- TDDなどのハンズオンに参加 ★★
- コードレビューする／される ★★
- 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog ★★
- IDEに従う ？
リファクタリングを常に意識することがまず第一歩
リファクタリングが身についている人とのペアプロが最も効率よく身につくと思うが、そうそうできる機会はない
コードレビューは非常に良い機会なので、この時にリファクタリングを念頭に置いてできると良い
自分が初心者の時に作ったアプリなど個人のプロジェクトは練習台にしやすい
リファクタリングはいつやるべきか
通常だと次のようなケースがあると思う
- まとまった時間が出来た時
- 今はリファクタリングの時間というように割り当てていることもあるかもしれない
- 不具合などで痛い目にあった後
個人的には違うと思っていて
本来やるべきと思うのは
- できれば常に（リファクタリングの時間というものは無い）
- 3つ目の類似コードが出てきた時
- 不具合が出た時
- 不具合が出た箇所はその後も不具合が出やすい
- 新しく機能を拡張する直前
- 拡張前にこれから変更する部分の理解が深まる
いずれも、テストを書くことが大前提ではある
テストを準備＞リファクタリング＞修正、機能拡張
「新しく機能を拡張する直前」はあまりやる人がいないと想像するので、特に推したい
普通にメンテされているプロジェクトなら動くテストがあるはずだし、多くの面で最も効果的
ここで、1つまたは2つ以上のすでにあるコードをコピペして改変するようだと負け
リファクタリングの良くない例
デザインパターンと同じだが、使ってみたいから適用するみたいなのは良くない
例としてタイプコードの置き換えは有名だが、それらがうまくはまる例にあまり当たったことがない
オーバーデザインで分かりにくくなることもある
個人のプロジェクトでやってみるのはおすすめ
オーバーデザインにしないようにする感覚は自分で痛い目にあうのが一番良い
リファクタリングの心がけ
- このコードを1ヶ月後の自分（他人）が読んだら分かりやすいかを想像する
- 逆の立場で、しばらく見ていないコードに遭遇して分かりにくいと思った時に、1ヶ月前の自分に対して思う事（恨み）を印象付けることも大事
- DRY
- この類似している重複したコードの1部だけが書き換えられたらどんな危険なことが起こるかを想像する
- リファクタリング以前にやらないといけないこと
思うところがありすぎてうまくまとまらない
リファクタリングの第一歩
リファクタリングをあまり意識したことない人が、具体的に何からすべきか考えた
まずは、個人のプロジェクトなどを題材に、テスト追加 -> リファクタリング
すべての基本は「メソッドの抽出」だと思う
まずはすべてのメソッドを10行以内にするくらいを目指すと良いかと思う
その他
おもしろい。ベテランとペアプロするのが最も身につく。
「テストは当然、書いているよね？」
若手開発者の後悔 | 開発手法・プロジェクト管理 | POSTD
リファクタリング否定の記事
http://developers.slashdot.jp/story/15/03/05/0535230/
ある程度の規模、古さになるとリファクタリングによってむしろ悪くなる事はあると思う
危険なのは中途半端なリファクタリング
テストの無いリファクタリングは論外
最近の記事 Ruby5から
Refactoring - When? | Netguru Blog on Dev
Pair with me 思い出した。バッジ作ってみた。メールへのリンクだった。
Pair Program with Me
読み終わって3週間以上経つがそれでもうまくまとまらなかった
社内の勉強会の題材がちょうど同じでシンクロニシティを感じた
今回本を読んでみて、とにかくパターンが多いと思った
ただこういった漠然とした手法を、箇条書きで手順を追って説明してあるのはすごいと改めて感心した
度々思ったのが、リファクタリングは双方向のものがあって、何を適用すべきかは状況によって変わるということ
リファクタリングで大事なのは欲張らない事だと思う
2ステップ以上一気にやろうとするのはやりがちだが良くない
リファクタリングによってアプリケーションが壊れたり、後々デグレが発覚するなど面倒になるリスクもある
反対にレアな条件で起こる問題が発覚していない潜在バグとかをつぶせることもよくある
正しい手順でリファクタリングできてない結果、効果が無いなどと言うのであればそれは残念なことだ
本を読んでみてリファクタリングについてさらに調べたい事やアイデアが思い浮かんだ
今後余裕があったらやりたいが、実際できるかどうかわからない
そもそも、リファクタリング、TDD、テスト、ペアプロなどはその効果を証明するのが難しいというのが課題
効果を人に説明できるようにするにはどうすれば良いかをずっと考えている
手軽に計測できる何かはないかとか
面倒だけど確実にできることは、かかった時間を記録していくことなんだが、これができない
測りたいことはある意味明確だ
リファクタリング（やテスト）をする場合としない場合の比較
ある時点からの不具合発生数、不具合修正・機能追加にかかる工数（時間）、パフォーマンスなど
あるプロジェクトを全く異なるチーム・プロセスで開発させ比較するという実験をすることは夢だが現実ではありえない
現実はプロジェクトそのものを作り変えるというリセット技が行われることも多いと思う
その場合と比べて得なのか、損なのか
でも、リファクタリングが良くされていて見通しが良いと、このプロジェクトの作り直し自体がかなり短時間でできると思う
作り直しの要求は、コードが古くメンテしにくいという理由よりも、契約だったり、依存する言語・フレームワーク・ライブラリのバージョンの都合でなされることも多い
リファクタリングの損得について、普通はせいぜい、個人個人が過去に経験したプロジェクトとの比較を肌感覚でするくらいしかない
チーム開発だとリファクタリングの恩恵を受ける次に変更する人が、リファクタリングした人と別の人ってのもあるな
時間かけてきれいな作りにこだわって実際動きが良いものができても、そのアプリケーションが世に出なかったり、お金を稼がなかったりすることもある
考えるとキリがない
9 hours (8 days 3/4-3/12)
Speed 1/5
★★★★★
Beck - E-Pro
