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

つらつら書く。

• レガシーソフトウエアとは、古くて大きくて技術的負債のやばいプロダクト
• プログラムの実装だけじゃなくて、それに付随するインフラ、デプロイツール、ドキュメントなどにも目を向けること。あんまりコミュニケーションのないチームは情報交換ができていないからやばい
• コミュニケーションが常に発生しているチームなら本来ドキュメントは不要だけど、メンバーがいなくなったときのことを考えてドキュメントは必要
• ドキュメントは作成するのも重要だが更新し続けることはもっと重要
• 調査的リファクタリングでプロダクトの中身を知る
  • warningを潰すとか
• 20%ルールでレガシーソフトウェアの改善を図る
• 改善にメンバーが難色を示しているなら改善することを秘匿にして少しずつ静かに改善していくこと
• 改善することを可視化して、チームでそれを共有すること
• 作り直しは経営者の巻き込みも必要になるので最後の手段とすること あと作り直しには想像以上に時間がかかる
• リファクタのやりすぎでプロダクト全体が死ぬ可能性がある

考えてみると、今のプロダクトが考えられうる最高の技術とアーキテクチャに基づいているものであることは基本的に稀であり、たいていのソフトウェアはレガシーなコードとレガシーなアーキテクチャに支えられて売上貢献の名のもとになんとか支えられているものがほとんどである。しかもそのプロダクトが会社の売上に本当に貢献しているかどうかも分からない場合がある(レガシーソフトウェアが売上に貢献している(=価値を提供している)かどうかについては特に言及はなかった)。

そういうときに、逃げるのはたぶん簡単。すごく簡単。でも目の前のプロダクトが考えられる最低の技術とアーキテクチャに基づいたものであっても、それが誰かに使われているなら継続的に保守運用していかないといけない。そうでないと、技術的負債が大きすぎてもっと売上に貢献したいってなったときににっちもさっちもいかなくなるから。とはいえ、なんとかしないといけないのは分かっているし分かりきっているのだけれど、なんとかするための時間も労力も技術もない。

この本は、そんな自分に贈られた指南書といえる。だがこの本はJavaベースで書かれているため(Firebugsとか)Javaな人じゃないひとは自分の言語に置き換えてみるといいと思う。ScalaだろうがPythonだろうが、設計や実装がダメなら負債は等しく増えていくから。重要なのは、自分の力で最低限でもいいので、静かに改善を進めていく時間と気力を確保していくことだと思う。この本で書かれているのは、テストをちゃんと書くとか、ビルドツールを入れるとか、バージョン管理システムでソースコードを管理するとか、基本的なことばかりだ。でも世の中は基本的なことさえ出来ていないことも多い。基本的なことすぎてエンジニア以外には、というかエンジニアでさえもその価値を見いだせていないことが往々にしてある。破綻して無くなったときに初めてそれらのありがたみに気づく。

そうなる前にソフトウェアの改善は必要なのだが、改善に必要なのは改善が出来る確かな時間と、システム運用に疲れてヘトヘトなときに改善をやりきる気力と、改善のリリースをエイヤでやりきる勇気だが、残念なことにこのうち気力と勇気についてはあまり言及がなかった。

たぶん個人的に思うのは、とにかく時間を確保することだ。たぶん定常業務の前に30分だか1時間だか2時間だが改善業務を先回りして確保するといい。「定常業務が破綻しない程度に」改善業務を組み込む必要性はこの本はきちんと書いてあった。ただしそれを定常業務の前にやるべきか後にやるべきかについては特に言及はなかったので、たぶん前にやったほうがいい。頭の切り替えは(年を取ってくると)想像以上にしんどい。

良い本だと思った。

レガシーソフトウェア改善ガイド (Object Oriented Selection)