レガシーソフトウェア改善ガイド

Twitter で id:hakobe932 さんが言及しているのを見て、週末にちょうどいい具合の隙間時間があったので読んだ。

レガシーソフトウェア改善ガイド

この本ではレガシープロジェクト（保守または拡張が困難な既存のプロジェクト）が抱える問題を説明した上で、それを改善するための技術的話題と、それを取り巻く人間の話が出てくる。開発環境をセットアップするのが困難とかドキュメントが間違ってるとか、そもそもそういうことに気を使わない同僚とか（そして気を使いすぎる同僚も）問題の一部として捉えているのが良かった。

コードがレガシーに（というのは、大雑把に言って、保守が困難に）なるには、多くの理由がありますが、ほとんどの原因は、技術ではなく人間に関係しています。

というのはその通りだと思う。（僕の周りにそういう人がいるとかそういうことを言っているわけではない）

2部からの具体的なリファクタリングの話では、リファクタリングタスクを価値（value）、難度（difficulty）、リスク（risk）の3つの軸で評価した上で、難度とリスクが低い「手がとどく果実」か、価値が高い「傷んだ箇所」に取り組みましょう、というのが良かった。これまでも暗黙的に考えてきた視点ではあるけど、明確に評価するようにすると優先順位づけの議論がスムーズになりそう。

リファクタリングすべきか、リライトすべきか、という点に関しては、それなりの分量を使っていかにリライトが良くないアイデアであるかを説明しているので、リライトを主張する人には一読してもらったうえで続きの議論をしたい。

総評としては、分量がほどほどで気軽に読めた割に、コードの品質を高めようという意識が高まったので読んで良かった。チームで読んでみるのも良さそう。

ただ残念な点として、紹介されているツールが基本的に Java プロジェクトを念頭に置いているので、そうでない環境では「Java にはこういうツールがあるんだなー」くらいの価値しかなかった。（本職の人が読んで価値がある内容かも定かでない…）

それからコードの品質を自動的に監視して、その情報をチームのメンバー全員が利用できるようにするために色々なツールの話が出てくる。その姿勢は見習いたいが、Jenkinsのセットアップ方法とかいらなかったのではないかという気がする。