quattro_4's diary

また同じ過ちを繰り返すと気付かんのか!?

レガシーコード改善ガイド 感想

レガシーコード改善ガイド

レガシーコード改善ガイド

メモ

  • レガシーコードとは、単にテストのないコードです
  • eXtreme Programming:エクストリームプログラミング
  • テストの最大の障害となるのが依存関係
  • 一貫して小さな改善を続ければ、数ヶ月の間にシステムは見違えるような状態になる
  • スプラウトメソッドとラップメソッド
  • Null を渡す (nilを渡すのは便利な手法)
  • 一度にあまりにたくさんの変更をしようとしているのかも
    • 「そのメソッドを壊したら、この場所で変更を検出できるか?」と、問いかけてみることです
  • 仕様化テスト(characterization test)
    • コードの実際の振る舞いを明らかにするテスト
  • 試行リファクタリング(scratch refactoring)
  • 「どうしてもprivateメソッドをテストしたいのなら、そのメソッドはprivateにすべきではない」ということ

感想

  • 長かった
    • 以前少し読み始めていたが序盤で断念してた
    • Javaのコードだったのもあって、コードがある部分は結構飛ばし読み
  • 本が10冊以上くらい紹介されていた
  • この辺りは個人的に結構身につけられていると思うので、斬新な発見はあまりなかった
  • スプラウトメソッドとかよくわからないところもあった
  • テストを壊したり、リファクタリングしたり参考になる手法がいくつかあった

レガシーコードはだんだんそうなるんじゃなくて、書く人や状況によっては最初からレガシーコードなんじゃないかって思った。
ただ、それらを後からレガシーコードじゃなくすることは可能だとわかったし、個人的にテストを重視することを続けてきて良かったと思えた。
自分のコードでさえ、それが1ヵ月以上後の自分にとってわかりにくいコードならそれもレガシーコード。
最近コードを見る時、頭を空っぽにする(前提知識のない人を想像する)ことや、視界を狭めたり(エディタで見える範囲で変数名などの妥当性を考える)広げたりするのをよく意識している。

レガシーソフトウェアについてはレガシーだったり、そうじゃないコードの集大成なので、だんだんレガシーになるもので合ってると思う。

せめて自分の触る部分は、レガシーを生み出さない、レガシーを治すようにしたい。


最近テストが落ちるような変更をしてコードを改善していく手法を、自分で発明したかのように思っていたのだけど、
(→ テストをわざと壊して効率的に開発する - quattro_4's diary
色々試して場合によっては破棄するという点で「試行リファクタリング」とほぼ同じなんじゃないかと気づいた。
昔からあったものだった。

それと、過去の自分まあまあ良いこと書いてあった
新装版 リファクタリング―既存のコードを安全に改善する 感想 - quattro_4's diary



10+h
Speed 3/5
★★★★★
10-FEET - nil?