既存のソースコードに詰まったノウハウと関係者の持つ暗黙知のサルベージがしたいなぁ。

なんて話を、id:ruzia さん*1 としている今日この頃。

ソフトウェアを新規に作り直すという愚

ソフトウェア開発を行う組織の多くは、十分に保守されていないソースコードを抱えていることがあります。そして、ある時点で、同様のソフトウェアをフルスクラッチで再開発したり、同様のノウハウを必要とするソフトウェアを全く別のアプローチで新規開発することがあると思います。おいらは、その流れに疑問を持っています。既存のソースコードとそれに詰まったノウハウを捨てることはメリットよりもデメリットの方が大きいと考えているからです。

この手の話はある程度コンテキストを共有したほうがいいと思うので、以下の記事をベースにしたいと思います。

Things You Should Never Do, Part I

It's harder to read code than to write it.

人のソースコード *2を読むのは難しいです。しかし、人のソースコードを読まずに、人のソースコードよりも優れたソースコードを書けるとなぜいえるでしょうか。

おいらの経験則では、長期的にソフトウェアの保守をしない人や、利用者*3にソースコードを読めというタイプの人に「コードは書くよりも読むほうが難しい」ということに気がついていない人が多い傾向があります。理解する側の能力の問題だという主張も0.001%くらいの可能性で考慮する余地があるかもしれませんが、利用者側が難しいといえば、それは、その『場』*4においてダメなコードなのです。こういうダメなコードを野放しにすると、ソースを読むのがますます難しくなって、最終的には誰にも読めない(読めたとしてもコスト的にとても割に合わない)コードになります。

コードを読む技術力を高めるとともに、自分の書くコードは読みやすくする努力が必要ですね。

Why is it a mess?

古い物を否定して全く別の新しいものを作ろうとする場合は、ほとんどのケースがこれを考えていないのでは？　本当に単純に messy なのか意味があってそうなっているのかを、ソースを読んで理解した上で判断することをせずに、「全体的にダメなプログラムだからオレ様が全部書き直してやる」的なノリで新規開発が始まるケースって多いのでは*5。ソースコードに詰まったノウハウは、顧客、営業、マーケティング、カスタマーサポート、保守開発部隊、その他みんなで一丸となってバグをつぶしたり改良してきた活動の成果であり、それを無視するのはおいら的には悲しいですね。

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

どうして自分の書くコードのほうが優れているとか無条件で思うんでしょうね。自分のことを漠然と優秀だと思っている*6エンジニアにつける薬はありませんね。

それ以上に問題なのは、それを認めるマネージャの存在です。リスク管理出来てるんでしょうか？「熊とワルツを」*7とか多くのアジャイル系の本にソフトウェア開発におけるリスクとかリスクポートフォリオとかリスクエクスポージャとかについて書かれているので、最低限そこら辺は理解しておいてほしいなぁ。