レガシーコード改善ガイド 感想
- 作者: マイケル・C・フェザーズ
- 出版社/メーカー: 翔泳社
- 発売日: 2016/01/15
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
メモ
- レガシーコードとは、単にテストのないコードです
- eXtreme Programming:エクストリームプログラミング
- Uncle Bob Books - Clean Coder
- テストの最大の障害となるのが依存関係
- 一貫して小さな改善を続ければ、数ヶ月の間にシステムは見違えるような状態になる
- スプラウトメソッドとラップメソッド
- Null を渡す (nilを渡すのは便利な手法)
- 一度にあまりにたくさんの変更をしようとしているのかも
- 「そのメソッドを壊したら、この場所で変更を検出できるか?」と、問いかけてみることです
- 仕様化テスト(characterization test)
- コードの実際の振る舞いを明らかにするテスト
- 試行リファクタリング(scratch refactoring)
- あらゆる方法を用いてリファクタリング
- そのコードは再びチェックインせずに破棄
- 「どうしてもprivateメソッドをテストしたいのなら、そのメソッドはprivateにすべきではない」ということ
感想
- 長かった
- 以前少し読み始めていたが序盤で断念してた
- Javaのコードだったのもあって、コードがある部分は結構飛ばし読み
- 本が10冊以上くらい紹介されていた
- この辺りは個人的に結構身につけられていると思うので、斬新な発見はあまりなかった
- スプラウトメソッドとかよくわからないところもあった
- テストを壊したり、リファクタリングしたり参考になる手法がいくつかあった
レガシーコードはだんだんそうなるんじゃなくて、書く人や状況によっては最初からレガシーコードなんじゃないかって思った。
ただ、それらを後からレガシーコードじゃなくすることは可能だとわかったし、個人的にテストを重視することを続けてきて良かったと思えた。
自分のコードでさえ、それが1ヵ月以上後の自分にとってわかりにくいコードならそれもレガシーコード。
最近コードを見る時、頭を空っぽにする(前提知識のない人を想像する)ことや、視界を狭めたり(エディタで見える範囲で変数名などの妥当性を考える)広げたりするのをよく意識している。
レガシーソフトウェアについてはレガシーだったり、そうじゃないコードの集大成なので、だんだんレガシーになるもので合ってると思う。
せめて自分の触る部分は、レガシーを生み出さない、レガシーを治すようにしたい。
最近テストが落ちるような変更をしてコードを改善していく手法を、自分で発明したかのように思っていたのだけど、
(→ テストをわざと壊して効率的に開発する - quattro_4's diary )
色々試して場合によっては破棄するという点で「試行リファクタリング」とほぼ同じなんじゃないかと気づいた。
昔からあったものだった。
それと、過去の自分まあまあ良いこと書いてあった
新装版 リファクタリング―既存のコードを安全に改善する 感想 - quattro_4's diary