プログラム修正の際に古いソースをコメントアウトするのはダメ？

質問

SE歴8年目のものです。
現在の仕事では、PHPで開発しており、Subversionで構成管理しています。

私はこれまでソースを修正する場合には、古いソースをコメントアウトし、さらに修正日付、修正者名、修正内容をコメントで入れるようにしてきました。

(例)
-----------------------------------
//090401 update [氏名] #1234のバグ改修 start
/*
[古いソース]
*/
[修正後のソース]
//090401 update [氏名] #1234のバグ改修 end
-----------------------------------

しかし、今一緒に開発している同僚のSEは、「古いソースをコメントアウトしたり、コメントに日付を入れたりするのは、構成管理ツールが無かった頃の古いやり方だ。今はむしろやってはいけない風潮になっているから、すべきではない。」といい、そのやり方に反対しています。

確かに私も商用リリース前のソースの修正に関してはこんなことはしないのですが、商用リリース済みのものに関しては慎重にやりたいので、情報をたくさん残すようにしています。

この同僚のSEの言う通り、このやり方は古くやらない方が良いのでしょうか？
皆様の開発現場はどうされてますか？

回答No.6

mmsb · ベストアンサー

ＳＥやって１６年目になるものです。

同僚の方の主張、何かの本で読んだような気が…と思っていろいろ調べてみたら、
「達人プログラマー」という有名な書籍の中にありました。

『変更管理はツールの仕事。ヘッダに日付と名前と概要だけ書けば良い』
というようなことが記述されています。

改修を重ねるとコメントでソースが読みにくくなるのは気分が悪いですよね～
生産性にも影響しているはずですしね。

「達人プログラマー」を読んで以降、その通りだな～と考えているのですが…

わが社もVSSで管理しているのに修正前のロジックをコメントアウトしてます。
分かっちゃいるけど、やめられない…（＾＾；

そういえば昔、チーム内でソースを「作品」と呼んでいたことがありました。
「このソース、誰の作品？」とか。

みんなで「ソースはアートだ」ぐらいのプライドを持って仕事をすると、
３Ｋとか７Ｋとか言われているこの業界も、少しは人気が回復するかな？
ソースを汚す"修正履歴のコメントアウト文化"は捨てるべきかも知れませんよ（笑

参考URL：

http://www.amazon.co.jp/gp/product/4894712741/ref=sib_rdr_dp

お礼

回答ありがとうございます。
きっと同僚もその本読んだのでしょうね。

今は一切コメントアウトしない方針で開発しています。

回答No.5

MrBan

参考までに、svn blameは使われていますか？

最新版ソースの、どの行を、どのrevで(だれがどんなコメントで)
直したかを確認するコマンドです。(blame：誰のせいだ！)
Tortoiseなら、ソースの左に誰がいつ直したか(マウスを当てればそのときのコメントも)が表示されます。

万全とはいいませんが、追跡調査はこれでかなり絞れませんか。

お礼

回答ありがとうございました。

この機能は初めて知りました！こんな便利な機能があったんですね。
すごく使えそうです。

回答No.4

papa987

>PHPで開発しており、Subversionで構成管理しています。
PHPってほかの言語に比べてバージョンアップに伴う機能拡張がある方だと思うけど
俺自身はPHP4系とPHP5系では使える関数などの違いにより
同じソース内にPHP4用とPHP5用とをコメントアウトで切り替えるレベルのことはよくやりますね。そこをSubversionで管理させるのは逆に非効率的だと思っていますから。
Subversionの枝分かれがすごいことになって分けわからなくなるので

また、一時的にソースを書き換えて挙動を検証する程度の時はソースをコメントアウトする程度ですね。

ついでにバージョン管理ツールもいくつもあるけど
今使っている物から別の物に変える事になったときに
基本的に今使っているバージョン管理ツールを情報を移管できないと
考えると質問者のやり方は間違ってはないけどこれだとソースが汚くなりますよね。
プログラム作るときには関数やクラスでソースファイルを個々に分けて
そのソースファイル毎にバージョンを設定してソースファイル毎差し替える形にして古いソースファイは手元にバックアップとして別の場所に残しておいて最新のソースファイルをコミットすればいいと思います。

修正する前のソースの全体ではなくて極一部が必要になる事って時々ありますよね。
そういう時ってバージョン管理システムだとめんどくさい時ってありますよね。
(全体を引っ張ってくるのは楽だけど)
それが数世代前の物で正確な世代がわからないとなおさら。

お礼

回答ありがとうございます。

＞そのソースファイル毎にバージョンを設定してソースファイル毎差し替える形にして古いソースファイは手元にバックアップとして別の場所に残しておいて最新のソースファイルをコミットすればいいと思います。

古いソースに関してはSubversionを信頼してそこから引っ張ってこれば良いかと思っています。

気にしているのが、修正してデグレが発生した時に、該当ファイルを1つずつ履歴とcompareしなければいけないのが面倒だなと思っているのですが・・・。
ソースに書いてあればそこさえ見ればわかるので楽かなと思っていたのですが。

回答No.3

MrBan

昔は軒並みソース内に残してました。
今でも外にソース提供してるもの(リポジトリが見れない前提)はコメントアウト(ifdef含む)もあります。
また、商用でないモックやテストコードなどはコメントアウトすることもあります。

そうでないもので、Subversion前提なら、
差分管理と修正コメントと修正者の記録はSubversionにやらせてます。
その方が見やすいですし、結果として誤りも少ないです。

また、コメントアウトが増えるとsvn diffを阻害するケースもありますし、
人間の目で見ても、修正コメントだらけのソースって結局保守性(特に可読性)低いと思ってます。

ソースの中にコメントアウトされてたところで、その内容を有効にしての実績はあるのか？とか、
いつの時点の修正だ？とかいうことになりますし、コメント内容も結局信頼できないのは大差ないですし。
(例えば、コピペミスがありえるコメント内の日時よりは、サーバ記録のsvnのcommit時間の方がまだ信頼できる)

いざって時のための修正前情報の保全は、tagsやexportによるsnapshotで完全に別にとってます。
(非常時用は原始的な手段の方が安心ということもありますが、
例えばTortoiseのdiffなら当該箇所だけ反映できたりとかしますし、
経験上、ソースのコメントアウトより便利な気もします)

> 例えば、複数の人が「同時に、Ａ、Ｂ、Ｃの機能の修正を開始した」とします。影響のあるソースは数十ファイル以上あります。
> ここで、クライアントが「Ｂだけ元に戻して」と言った場合、差分ツールで「Ｂの機能が修正される前」に戻すと、ＡもＣも修正される前に戻ります。
> こういう場合、ツールで何とかするには「Ａだけ修正した差分」「Ｂだけ修正した差分」「Ｃだけ修正した差分」を持たねばなりません。

SubversionはVSS等と方式が異なり、ロックなしの同時編集を許します。
AとBとCの修正箇所が衝突するソースの同じ箇所でなければ、
commit前にupdateすれば他人の修正とマージできますので、
必ずしもAの修正にBとCを待つ必要はありません。
(AがBやCに依存してる/衝突する場合は別ですが、そういうものはいずれにせよ同時に直しようがありませんし、
Subversionからコンフリクトが通知されるでしょう)

また、Subversionのような版管理ソフトを正しく運用し、
A、B、Cなどの意味のある単位できちんとcommitしていれば、
commit単位でマージやリバートできますので、「Bだけを戻す」「B以外を戻す」等もできます。
人間が個別に直すより、機械的に直して人間が最終チェックの方が安全じゃないかと思います。

むしろ、個人的に「一つのプロジェクトで並行進行する」状況で、
完全に人力のマージとかロールバックとか、怖くてやりたくありません。

機械任せにしろといっているのではありませんが、人間×人間のクロスチェックよりは、観点の異なる人間×機械の方を信頼できると思ってます。
まぁ、開発環境によっては「常にSubversionに接続できるとは限らない」こともありますし万能だとはいう気もありませんが。

お礼

回答ありがとうございます。

＞また、コメントアウトが増えるとsvn diffを阻害するケースもありますし、
＞人間の目で見ても、修正コメントだらけのソースって結局保守性(特に可読性)低いと思ってます。

これは激しく同意です。
厳しい会社だと、「単体試験以降の修正はすべて元ソースを残す」っていうルールがあったりするので、改修・仕様変更が重なるとソースの9割コメントアウトとかになりますよね。
なので可読性が明らかに落ちるようなコメントアウトは反対なのですが、そうでないのであれば残しておいて損はないと思っているのですが・・・。

あとソースを自分の名前で検索すれば自分の修正箇所がすぐにわかるというのも便利なんですけどね。

回答No.2

chie65536（@chie65535）

＞構成管理ツールが無かった頃の古いやり方だ

そうやって「すべてをツールに任せ、情報を残そうとしない人」は、後で泣く事になります。

ツールは万能ではないので、クライアントか「この部分の、この機能だけ、元に戻して欲しい」と言われた場合、ツールでは「すべての機能を、変更する前に戻す」のは可能ですが「特定の、指定の部分だけ、元に戻す」のは不可能です。

例えば、複数の人が「同時に、Ａ、Ｂ、Ｃの機能の修正を開始した」とします。影響のあるソースは数十ファイル以上あります。

ここで、クライアントが「Ｂだけ元に戻して」と言った場合、差分ツールで「Ｂの機能が修正される前」に戻すと、ＡもＣも修正される前に戻ります。

こういう場合、ツールで何とかするには「Ａだけ修正した差分」「Ｂだけ修正した差分」「Ｃだけ修正した差分」を持たねばなりません。

Ａ～Ｃの差分を個別に持つには「Ａの修正が終るまで、Ｂ、Ｃの修正はしない」「Ｂの修正が終るまで、Ａ、Ｃの修正はしない」「Ｃの修正が終るまで、Ａ、Ｂの修正はしない」と言う「決まり」を作らなければなりません。そうしないと「Ａ～Ｃの修正点の差分が、ゴチャゴチャに混ざって」しまいます。

通常、実際の作業現場では「Ａの修正が終るまで、Ｂ、Ｃの担当者が、何もしないで待っている」って事は有り得ないので、Ａ～Ｃは「同時進行」しますから「○だけ修正した差分」は作る事が出来ません。

そうなった時「ツールだけに頼る」と「全てを元の状態に戻す」か「記憶のみを頼りに、手作業で特定の修正部分のみを元に戻していく」しかありません。

＞この同僚のSEの言う通り、このやり方は古くやらない方が良いのでしょうか？

「ツールのみに頼る」のも駄目ですし「古いやりかたをしてツールを使わない」のも駄目です。

質問者さんの言う事も、同僚さんの言う事も、どちらも「不十分」です。

正しいのは「ツールではカバー出来ない部分は、古いやりかたを踏襲し、ツールでカバー出来る部分はツールでカバーする」と言う方法です。

１つのプロジェクトで複数の修正を同時進行する場合は、必ず「何に関する修正なのかを分類出来る情報（つまり、ソース内に残すコメント）」と「初代に戻れるまでの差分の情報（つまり、差分ツール等による自動の履歴管理の情報）」の両方を持つようにしましょう。

どちらの情報も「１つだけ残して、あとの全部を元に戻す」とか「１つだけ元に戻して、あとの全部を残す」っていう場合に必要になります。

お礼

回答ありがとうございます。

「古いやりかたをしてツールを使わない」と言っているわけではなかったのですが・・・。

＞１つのプロジェクトで複数の修正を同時進行する場合は、必ず「何に関する修正なのかを分類出来る情報（つまり、ソース内に残すコメント）」と「初代に戻れるまでの差分の情報（つまり、差分ツール等による自動の履歴管理の情報）」の両方を持つようにしましょう。

ここなのですが、要するに「修正内容のコメントと構成管理ツールを使いましょう」ということでしょうか？

回答No.1

salam70

15年やってますが、私も履歴はソースに残します。

もし次の瞬間私が死んで十分な資料を残せなかったとしても、
ソースが後任者に歩んできた歴史を語ってくれますから。

でも古いやり方なのか・・・

お礼

回答ありがとうございます。
伝統ある古い会社だときっと今でもこの方式だと思うんですけどね。

昔ある開発大手企業の仕事で、他人が書いたソースを直そうと思って見てみたら行数が10kくらいあって、「すごいソースだな～」と思ってよく見てみたら9kコメントアウトでしたｗ。