読者です 読者をやめる 読者になる 読者になる

道草道

大崎上島での移住の記録(2016年4月~):子育て・古民家改造・裏山開拓・造船所・たまにプログラミング

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

プログラミング

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

 

legacycode.hatenablog.com

 

昨日考えた事は、

 

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

 

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


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

 

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

 

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

 

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

 

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

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

d.hatena.ne.jp

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

 

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

 

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

 

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

 

それは、なぜだろうか?

 

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

 

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

「派生開発」を成功させるプロセス改善の技術と極意

「派生開発」を成功させるプロセス改善の技術と極意

 

 

リファクタリング
外部の振る舞いを保ちつつ理解や修正が簡単になるようにソフトウェアの内部構造を変化させること。

リファクタリングする(動詞):
一連のリファクタリングを適用して、外部から見た振る舞いをの変化をなしにソフトウェアを再構築する。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

 

 

ソースコードの劣化を防ぐ答えがここにありそうです。

 

ソースコードの劣化(保守性、可読性)を防ぎ、価値を生み出すソースコードを保つには、リファクタリングが必要なだと思います。

 

リファクタリングを常に実施しながらコーディングする方法としてはテスト駆動開発があります。

テスト駆動開発入門

テスト駆動開発入門

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2003/09
  • メディア: 単行本
  • 購入: 45人 クリック: 1,058回
  • この商品を含むブログ (161件) を見る
 

 

既に劣化してしまったソースコードリファクタリングする方法として、レガシーコード改善ガイドがあります。レガシコードと戦うプログラマのバイブルのような存在の本です。

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

 

 

じゃあ、テスト駆動開発してリファクタリングを日常的にすればいいじゃないかと思うのですが、やってみたことある人は分かると思いますが、ここの壁が大きいんですよね。

  

1年前くらに書いた、レガシーコードへの取り組み。

現場にテスト駆動開発を導入してソースコードを改善しようと悪戦苦闘していました。

1年間に比べたら、今はずいぶんと改善された気がします。 

legacycode.hatenablog.com

 

今日は、時間がなくなったので、次回、なぜ、リファクタリングが選択されずに、「動いているプログラムは触るな」が選択されるのか考えてみたいと思います。