ソースコードの劣化を防ぐにはどうすればいいのだろうか？

昨日、「なぜ、ソースコードは劣化するのだろうか？」と言うことを考えてみました。

legacycode.hatenablog.com

昨日考えた事は、

ソースコードの性能：
新しい付加価値を追加するなど、新しいソースコードを作り出せる能力

ソースコードの品質：新しい付加価値を持ったソースコードの作りやすさ
保守性⇒変更をどれくらい容易に変更を行えるか？
可読性⇒ソースコードの読みやすさ

ソースコードを道具だと考えた場合、性能や品質を保つための使い方とメンテナンスの方法を考える必要がある。

使い方：劣化を最小限に防ぐようなソースコードの変更技術
メンテナンス：リファクタリング

劣化を最小限に防ぐようなソースコードの変更技術

について、少し考えてみたいと思います。

「劣化を最小限に防ぐようなソースコードの変更技術」として、一般的な考え方（？）が、「動いているプログラムは触るな」かもしれません。

「動いているプログラムは触るな」での、変更方針は、最小のソースコードの変更で変更を実現すること。
これなら、ソースコードの変更は最小限になって、ソースコードの劣化は最小に抑えられる。クーロンコードによって品質が良くなるという論文も、そんな考えから出てきているのかもしれません。

d.hatena.ne.jp

一見、「動いているプログラムは触るな」は、正しい方法に思える。

でも、なんか変ですよね。

ソースコードの品質：新しい付加価値を持ったソースコードの作りやすさ
保守性⇒変更をどれくらい容易に変更を行えるか？
可読性⇒ソースコードの読みやすさ

と考えた場合、「動いているプログラムは触るな」は、明らかにソースコードの劣化を引き起こす。

保守性も悪くなるし、可読性も悪くなる。

「動いているプログラムは触るな」は、ソースコードが紙媒体で、修正を加えると物理的に紙が痛む（消しゴムで消すとか）場合は正しいかもしれない、でも、ソースコードの品質を保つための変更方法としては適切ではない。

品質として何を選ぶかにもよる気もしますが。

ちょっと、「動いているプログラムは触るな」方式でソースコードを変更したらどんなことになるか？を考えてみたいと思います。

ソースコードは、物理的な構造を持ちませんが、論理的な構造を持ちます。
「動いているプログラムは触るな」方式で変更をすると、論理的な構造が崩れます。

論理的な構造は、本の構成みたいなもので、変更を繰り返すうちに、
１～10章あるうちの１章が全体の半分を占めてしまったみたいな感じになったり、
１～9章での話が、10章で実は全部嘘でしたみたない展開になったります。

イメージで言うとこんな感じです。

なぜ、「動いているプログラムは触るな」は根強い人気？

「動いているプログラムは触るな」で、ボロボロになったソースコードは、いたるとこに転がっている。
経験のあるプログラマーなら、「動いているプログラムは触るな」は、あまり良い方法ではないと、うすうす気が付いていると思います。でも、現在進行形で「動いているプログラムは触るな」方針で変更されている現実がある。

それは、なぜだろうか？

一つに、ソースコードの変更に対する技術が確立されていないと言うことがある気がします。ほとんどが、新しいソースコードを作るための技術で、ソースコードを上手く変更する手法といった本はあまり見たことない。

XDDP:派生開発に最適化した開発プロセス
ソースコードの劣化を最小限に抑えるようなプロセスを可能にする。
ただ、この劣化を最小限にと言うのは、コーディング技術ではなく、仕様漏れによる手戻りや、間違った箇所の変更など、無駄な変更を最小限に抑えると言う意味。