修正履歴

プログラミング

修正したら、ソースコードにコメントで修正履歴を残すようにしてくれ、みたいなことを品質管理をしている人から言われたのだけれど、絶句してしまった。
そういえば、他の人のソースを読むと、人によって、日付と修正内容（一行くらい）がやたらと書いてあって、さらに古いコードがコメントアウトされて残っているのを見て、どうしてこんな読みにくくなるようなことをするんだろうと思っていたのだけれど、そういうことだったのか・・・。
これって、お仕事プログラミングでは普通のことなんですかね？

      • -

私の考えでは、ソースコードの本体は、そのコードがその時点で意図していることが的確にわかるように構成されているべきで、本筋を見失いかねないような過去のコメントやコードの断片を残しておくべきではないと思っていて、仕事でもプライベートでもその考えに従ってプログラムを書いています。修正内容をコメントに残すこともありますが、それはその後に続く作業に対するメモなので、用が済んだら基本的には消しています。
では、過去に処理したのと同じような問題が再現した時や、新たに発生した問題が過去の修正に原因がある可能性がある時に、過去の対処方法を調べたいときにはどうすればいいのか、ということを考える人がいるかもしれませんが・・・

      • -

まず、過去にどういう風に書かれていたかを知るには、コメントアウトして残してあるソースを読むのではなく、バージョン管理ソフトから過去のリビジョンを抜き出してくるべきですよね。
最近の修正ではない場合には、trunkからはファイルが削除されている可能性がありますが、適切にbranchをしていれば、branchesから過去のファイルを取ってくることができます。（ちなみに、信じられないことですが、私の職場には、バージョン管理ソフトでbranchを管理するという概念がありません・・・）
このようにして取ってきた過去のファイルは、コメントアウトしたものとは違って、その場でコンパイルして動作させることができるというメリットがあります。

      • -

では、過去の修正が、どういう問題に対して、どう考え、どういう方法で修正したのかということの記録はどうするのがよいかというと・・・
私の知っているところでは、結城さんの「作業ログ」（http://www.hyuki.com/d/200605.html#i20060531075544）がスマートでよいなと思っています。コメントに残すのでは、記述が少なすぎたり、記述が分散して全体像を捉えにくかったりするのですが、専用のテキストファイルならそういうことはないですし、必要ならソースコードをコピペしておいてもいいわけですし。
他にも、研究日誌のように日誌を書いておくのもよいかと思います。検索性は悪いですが、手書きなら図を書くのも書きやすいので。
私がプライベートで実際にやっているのは、はてなに書いておくことです。もう、思いついたことを片っ端から書いておきます。仕事でも、ブログをツールとして導入してもいいなと思っているのですが、それはまだ検討中です。周囲の理解を得るのが大変そうなので。