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

道草道

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

なぜ、ソースコードは劣化するのだろうか?

プログラミング

ソフトウェアの開発中にソースコードの劣化と言う話をよく聞きます。

ソースコードの劣化』とは何を意味しているのだろうか?ということを考えてみたいと思います。

 

ソースコードは、コンピュータへの指示書のようなもので、コンピュータはそのソースコードに従って動きます。(厳密にはコンピュータは直接ソースコードを理解出来ないので何段階かの翻訳が入ることになるのですが、それは省略します)

 

プログラマーとは、ソースコードを書くことを職業としている人です。
ソースコードは、パソコン内にあるデジタルなファイルなので、物理的な紙などと違って、時間の経過よって色あせるとか文字が見えなくなるといった物理的な劣化はしません。

 

では、何が劣化するのでしょうか?

 

ちょっと、『劣化』とは?について調べてみます。

kotobank.jp

ソースコードの劣化とは、ソースコード性能品質などが低下して以前より劣ってくること。

 

ところで、ソースコードの性能とは何でしょうか?

 

これはソースコードを使う目的を考えれば、分かります。

今のソースコードを使って、新しい価値を持ったソースコードを作り出すことです。

 

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

 

その場合の品質とは何でしょうか?

品質 - Wikipedia

「本来備わっている特性の集まりが、要求事項を満たす程度」

こっちの方が分かりやすいかもしれません。

 

ソフトウェア品質 - Wikipedia

「品質とは誰かにとっての価値である」

その道具としての機能が、それを使う人の要求をどれくらい満たしているか?ということだろうと思います。

 

プログラマが、今のソースコードを使って、新しい付加価値を持ったソースコードを作り出したいと言う要求を、どれくらい満たすか?
その尺度として保守性と可読性がよく使われます。

 

ソースコードの品質:新しい付加価値を持ったソースコードの作りやすさ

保守性⇒変更をどれくらい容易に変更を行えるか?
可読性ソースコードの読みやすさ

 

ソースコードの性能・品質は、なんとなく分かりました、それでは、

 

いつ劣化が発生するのでしょうか?

 

先に説明しましたが、ソースコード自体はデジタルなものなので時間が経過しても劣化はしません。

ソースコードが劣化が発生するのは人がソースコードを使用する時、つまり、ソースコードを変更する時です。

 

ソースコードはコンピュータにとっては指示書で、コンピュータがソースコードをいくら使っても劣化しません。

 

なぜ、ソースコードが劣化するのか?
それは、人がソースコードを変更するからです。

 

ソースコードが劣化する時:

人が今あるソースコードを使って、新しいソースコードを作り出す時

なぜ、ソースコードが劣化するのか?

人がソースコードを変更するから 

 

劣化を防ぐには?

 

では、どうすればソースコードの劣化を防ぎ、ソースコードの性能を保つことが出来るのでしょうか?

 

そこで、少し無理はありますが、ソースコードを新しいソースコードを生み出す道具と考えてみたいと思います。
ところで、他の道具はどうやって劣化を防いでいるのでしょうか?

 

車の場合は、車検、走行前の点検、など定期的にメンテナンスを行います。
また、日常的にどんな運転をするかも、劣化に影響します。

どんな道具でも長く使おうと思うと思うと、劣化を防ぐために使い方やメンテナンスをする必要があります。

 

使い方:劣化を防ぐような運転技術
メンテナンス:車検、日常点検

 

ソースコードの性能や品質を保つために、どんな、使い方、メンテナンスの技術があるでしょうか?

 

例えば、こんな感じでしょうか?

 

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

 

ソースコードのメンテナンスを考えると、

 

・いつメンテナンスするのか?
・どこまでメンテナンスするのか?
・どのようにメンテナンスするのか?

 

など、ソースコードのメンテナンス計画を立てる必要がある気がしますが、ソフトウェア開発現場で、ソースコードのメンテナンス計画を立てる話を聞いたことがありません。

 

ソースコードを道具として考えた場合、メンテナンスするという概念がなければソースコードが劣化するのは当然な気がします。

 

僕が知っているメンテナンス計画に近いもの

テスト駆動開発

実装の前に単体テストを先に各開発手法。
1.テストを書く⇒テスト赤(テストNG)
2.コードを書く⇒テスト緑(テストOK)
3.リファクタリング⇒テスト緑(テストOK)を保つ
1~3を繰り返す。コードを書く=リファクタリング
常にメンテナンスしながらコードを書いていく。
1行新しいコードを書くたびに、メンテナンスを行う。

テスト駆動開発の場合には、

テスト駆動開発入門

テスト駆動開発入門

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

 

XDDP

派生開発を制御するための技術

変更要求仕様書、トレーサビリティマトリックス、変更設計書の3点セットにより、効果的なレビューを可能にし、ソフトウェア改造時の混乱を防ぐ。

XDDPにリファクタリングを制御方法も触れられている。
リファクタリングプロジェクト

 プロジェクト開始前にリファクタリングだけをしてしまう。
・小さなリファクタリング

 今回変更する変更箇所に限定したリファクタリング

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

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

 

 

以前読んだ本では、今日の作業を始める前に、前日のコードの整理から始めるということをしていて印象に残っています。

30日でできる! OS自作入門

30日でできる! OS自作入門

 

 

ソースコードを劣化させないためには、各現場にあったメンテナンス計画を立てる必要がある気がします。

 

・いつメンテナンスするのか?
・どこまでメンテナンスするのか?
・どのようにメンテナンスするのか?

 

そんな、ことが大切でないかな?と考えています。