最近、気になる事ですが、自分が経験したどの開発現場でも、修正部分をコメントで残せ!

というルールがあって、だいたいどこでも最初のバージョンからずっと残ってて、
非常に読みづらい状態になっています。

この「修正部分をコメントで残す」というのは、よく見かけるコーディングルールだと思うのですが、
CVSなり、VSSなり、変更履歴はリポジトリで管理すればいいことで、
なぜわざわざ読みづらく、リファクタリングし辛いルールを設定するのか分かりません。

リポジトリ管理されている場合、修正部分をずっとコメントで残す規約に、何かメリットがあったら教えてください。

・歴史的経緯で残っているだけで、現在ではメリットはない、と私は思っています。
・関係者は自由に前のバージョンをリポジトリで閲覧できる前提とします。
・管理者はcvsが使えないから……というなら、ソースはもっと読めないはずです。

なので「修正する時、修正前のプログラムを忘れるかも」「歴史的経緯だけで、メリットはないです」「管理者はCVSを使えないから」という回答にはポイントをおつけできません。よろしくお願いします。

回答の条件
  • 1人2回まで
  • 登録:
  • 終了:2009/02/15 22:09:32
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:hijk05 No.2

回答回数1307ベストアンサー獲得回数23

ポイント30pt

◆新規開発

開発段階を2つのフェーズに分けるとします

前半のフェーズでは、修正部分をコメントとして残す意味はないと思いますし、リファクタリングしずらいのでよくないと思います。後半に入って(結合?)テスト段階に入ったら、修正部分をコメントとして残すのは意味あることだと思いますし、自分自身に責任がないことを明確になるのでよいかなと思います。ソースレビューをするときにもソースを印刷するだけですみます。

◆追加開発

この場合は、どんなに醜いソースであっても、リファクタリングしないのが通例だと思います。また、前回の修正のソースのコメントが残っていても仕方がないことだと思います。

id:moons

追加開発時に過去のコードを残しておくのは、責任範囲からも保守としても当然の措置かも。

たしかに納得感があります。

2009/02/10 01:13:44

その他の回答5件)

id:hyo-suke No.1

回答回数43ベストアンサー獲得回数5

ポイント25pt

個人的に思っているのは、最新のソースに「そこが変更されたことがある」ということが書かれていないと、そもそも以前のバージョンの確認をしようと思わないからではないでしょうか?その結果、以前と同じミスを再度埋め込んでしまうかもしれない。

もちろん修正前に、その箇所が過去に何らかの修正を行ったかどうかを確認するというルールにすれば良いと思いますが、最近のバージョン管理ツールって、現在のソースの行数か何かを指定して、その部分の変更履歴を抽出する機能ってあるのですかね?(私が知らないだけ?)

id:moons

最初から通しでの変更履歴が一覧できること、過去の変更に気づけること。

というのはたしかにメリットを感じます。

2009/02/10 01:12:03
id:hijk05 No.2

回答回数1307ベストアンサー獲得回数23ここでベストアンサー

ポイント30pt

◆新規開発

開発段階を2つのフェーズに分けるとします

前半のフェーズでは、修正部分をコメントとして残す意味はないと思いますし、リファクタリングしずらいのでよくないと思います。後半に入って(結合?)テスト段階に入ったら、修正部分をコメントとして残すのは意味あることだと思いますし、自分自身に責任がないことを明確になるのでよいかなと思います。ソースレビューをするときにもソースを印刷するだけですみます。

◆追加開発

この場合は、どんなに醜いソースであっても、リファクタリングしないのが通例だと思います。また、前回の修正のソースのコメントが残っていても仕方がないことだと思います。

id:moons

追加開発時に過去のコードを残しておくのは、責任範囲からも保守としても当然の措置かも。

たしかに納得感があります。

2009/02/10 01:13:44
id:pkoiri No.3

回答回数82ベストアンサー獲得回数2

ポイント25pt

みんながみんな、ソース管理がキチっと出来ているわけじゃないっていうのが一番だと思います。

リポジトリ管理をしていない現場というのも(特に小規模なら)結構あります。


そんな状態なので、慣れているコメントでの管理の方が結果的に見やすくなる事が多いです。

例えば、コミットする際にコメントを残さなかったりする人間でも、コメントアウトする箇所には「○○の為コメントアウト」なんて書いていたり。


勿論これは悪い習慣ですが、なかなか全員の意識を変える事も出来ませんし、上の人間がそういう考えなら尚更…


私の経験での話なので、会社や現場の人員で相当左右されるとは思いますがね。

そういう環境での違いもあると思うんで、先輩やリーダーに一度聞いてみては?

id:moons

いやあ、どっちかというと、私は年齢柄、先輩だったりリーダーだったりするので、

コードレビューをする側なのですが、規約に「コメントアウトで残せ」と書いてあっても、

「残す理由」が自分には見つからない現場というのが散見されます。

ただ、自分の視野が狭いだけかもしれないので、今回の質問に至りました。

リポジトリで管理してないなら、たしかに履歴を残す必要性は強く感じます。

あと、リポジトリ管理ソフトに慣れてない人が多い現場でもそうですね。

2009/02/10 01:22:07
id:ttakao No.4

回答回数276ベストアンサー獲得回数31

ポイント10pt

アメリカの会社で某ソフトウェア開発の現場にたずさわったことがあります。大規模ながらオールアセンブラーだと思ってください。ご存知のようにアセンブラでは「なにをしたいのか?」という意図が極めてわかりずらいです。なので、数行おきにコメントが入ってきます。それも行の後ろではなく、真ん中に入れていきます。修正が入るとやはり、その経緯を書いて行きます。(それと修正した人のショートネーム)

だんだん、仕様書部分が増え、コード自体が占める割合が減ってきます。ソースコードといっても、アルゴリズムを読んでいる感じでした。イメージとしてはwikiをよってたかって書き直してる感じですかね。

修正は修正IDが右端に入り、それで検索すると修正箇所すべてが分かるという形でした。

subversionのような管理はサブチームでは、やっていました。が、いわゆる「正規ライブラリー」はひとつしかバージョンをもっていませんでした。テストチームはかってにビルドしてましたから。

当然、開発が終了し、サポートチームに渡されるのは、ファイナルカットされたソースコードでした。

おそらくコメントをメモ程度に書いているのでは、おっしゃるとおりで何の役にも立たない気がします。日本でソースにコメントを書いているのも見かけますが、ほとんどが「メモ」程度でとてもじゃないですが、意図は分からないと思います。

ただ、現在、時々自分でプログラムを書いていてもそうですが、考え方を先に書いて、その間にソースコードを書くほうがラクに感じています。javadocみたいなのが好みです。

なので、まったく役に立たない歴史的遺物とは感じてないです。

id:moons

えーと、コメントを書くこと残すこと自体は重大な意味があると思います。

また、履歴も「最終的に何を変更したいのか?」をコメントに書いてあるなら、

それを残すことは全然問題ないと思います。

私がもった疑問は、『古いコード自体』を、コメントアウトで残しておくことに、

どんなメリットがあるのか。ということです。

2009/02/10 01:35:12
id:kodomono-omocha No.5

回答回数406ベストアンサー獲得回数6

ポイント5pt

自分で書けない奴が、他からぱくってきたソースを切り貼りしてごまかしてるような場合に多いパターンです。

要するにあなたの経験してる現場にいるPGとSEがしょぼかっただけです。

普通ならコードレビューで教育的指導されるはずですが、それすらもしていないのでしょう。

まともな開発体制も制度も整ってない証拠です。

もっと程度の高いところに転職しましょう。

id:moons

いやー、違うと思いますが。

コメントアウトしてソースを残すことと、切り貼りすることは関係ないと思います。

また、多くの場合、「修正前のソースを残すこと」はプロジェクトのコーディング標準に定められており、

コードレビューを厳密に実施すればするほど、修正前のソースが残ることになります。

伺いたかったことは「修正前のソースを残すこと」に私は、メリットが特に感じられないのですが、

何かメリットがあるのかどうか、ということです。

2009/02/13 23:43:59
id:hogee No.6

回答回数5ベストアンサー獲得回数0

ポイント15pt

「修正部分をコメントで残す」というのは、コメントを書くということではなく、コメントアウト

しておくということなのですね。


私も基本的にはすべての修正部分を残すことにはあまり意味が無いと思います。

コードをコメントアウトして残す意味としては、デバッグやテスト用のコードなど

コメントを外しても動くことを確認している場合のみと思います。

これは修正部分ではなく、保守に必要な機能ですね。


ただ、過去の経験から修正部分をコメントアウトで残すパターンを思い出してみますと

インターフェースを維持するために関数を残していることがありました。

つまり元は何かの目的で作ったが、何らかの理由で使用しなくなった。

けれどもその関数をコールしているモジュールがたくさんあるので修正範囲を最小限にするために、

中身をコメントアウトしているという感じです。


その場合でも関係者には周知して、コードを残さずともコメントをしっかり書いてリポジトリ管理を

すれば良いとは思いますが、元々何をするつもりだったかを知らせるメリットはあるかもしれません。

いずれにせよ「修正部分」とルールでひとくくりするのではなく、使い分けが肝要と思います。


・・あまりメリットを書けていませんので、回答になってないと感じられたらポイントは結構です。

id:moons

読み取っていただいたです。質問の意味が取りづらく、申し訳ないです。

不要になったモジュールを直す場合に、中身をコメントにして呼び出しても何も動作しないものとし、

呼び出し元は変更しない……ああ、希にありますね。そういうのも。

「場合によって使い分け」というのは考え方としては正しいと思うのですが、

おそらくコーディングルールを定める側は恣意的な運用がされるのを避けるため、

一律で「修正部分を残して直せ」というのかもしれません。

だんだん、そんな気がしてきました。

2009/02/13 23:49:43
  • id:Mathusala
    サディア・ラボン 2009/02/09 06:39:34
    管理者が読めなくても、
    開発係りの人は、「前のバージョンはこんな欠点が有ったのでこんな改良をした」というのが分かった方がいいと思います。
    データがあるなら、昔のパソコンはメモリが足りなくて動かなかったのが、今のパソコンなら動かせるのを、復活させられます。
  • id:pkoiri
    一応ツッコミとして
    ・関係者は自由に前のバージョンをリポジトリで閲覧できる前提とします。
    という事なんで開発者もどういう改良したのかは分かる、という前提でしょう。
  • id:standard_one
    回答よりも先に率直な感想として「改善策があるなら自分から提案すればいいじゃん」と思いました。
  • id:ku__ra__ge
    ID:hyo-sukeさん
    「現在のソースの行数か何かを指定して、その部分の変更履歴を抽出する機能」というのはblameコマンドがそれに当たると思います。(svn blame filename とかいう感じで使うコマンド)
    TortoiseSVNに付いてる、GUIツールだとこんな感じですね。
    http://tortoisesvn.net/docs/release/TortoiseSVN_en/images/TortoiseBlame.png
  • id:moons
    あ、多くのコメントありがとうございます。
    質問自体不慣れなのですが、文字数制限で当初の質問をかなりグリグリ削りました。
    意図が通じにくくなっている部分については、申し訳ないです。

    >Mathusalaさんと pkoiriさん
    たぶん、連続したお話だと思うのですが、担当者は前に別の担当者がどんな修正をしたか、
    については調べれば分かる状態を前提としています。
    (お金がなくともCVSとかsubversionを導入すればいいだけなので、なんとでもなります)

    ただ、hyo-sukeさんからの回答にもあったとおり、そもそもコメントがなければ、
    その部分が修正されたかどうか分からないので、「改良前」の状態に戻してしまう
    可能性はあるような気がします。
    よく、「最初は単純な仕様で片付くと思ったけど、実は固有の場合にうまくいかなくて、
    一見遠回りだけど確実な仕様に変更した」ことがあります。

    >standard_oneさん

    いや、改善したいなあとはよく思ってますし、実際何度か変えたり、有名無実化しました。
    ただ、あまり理由がないように見える割には、どの現場にもある規約なので、
    ひょっとしたら何か自分に見えてないメリットがあるのかなあ、と質問に至りました。
  • id:degucho
    「調べれば分かる状態」の調べる1手間が面倒かもしれません。
    一律に残すのではなくて、将来のメンテナが履歴を漁る手間を省くというか
    日本語でコメント(たまに嘘付き)残すよりコードのほうが変遷を説明しやすい
    (動作履歴を知っておいてほしい)
    とか、将来参考にしてほしいとか復活しそうだな、という場合に残すのが
    いいと思っています(この判断が人によって違ってしまうので
    ルールとして一律に決めてしまうのだと思います)。

    あまりに増えてフローが追えなくなったり、ここで一旦stableという場合に
    「いろいろあったけどこれより前はリポジトリ参照」とだけコメントしてきれいな形にすると。
  • id:hyo-suke
    ku__ra__geさん

    なるほど、やっぱりありますよね^^;
    勉強になりました。ありがとうございます。
  • id:ttakao
    あー、古いコードを残すことですか。それは意味ないですよ。
    よく、自信のない人が「いつでも戻せるように」と残しておいて、ずーっと消さないからクズだらけになるってのはよくありますよね。自信のない人は消さないことで責任回避してるとしか思えないです。
    しかも、3度くらい修正が入るともう誰も古いコードは追わない。追えない。
    それは私も意味がないと思いますよ。
  • id:moons
    そろそろ終了しようかと思っているのですが、回答いただいたことから、私なりに考えたことなど。書きます。

    ・納品や結合テスト完了など、ある程度固まった時点のソースコードを残しておき、
     保守や仕様変更への対応時に、変更・追加した範囲を明確化した上でコードレビューをすることは、とっても重要。
     誰々が勝手に直してエンバグした、みたいな面倒くさい話になると本当に面倒くさい。

    ・新規開発のときには、ポジティブな意味はあまりない。
     ・あえてポジティブなものを挙げると、他人が修正した場所に気づけるようになる。こと。
     ・リポジトリ管理ソフトに不慣れな開発者も多い。コメントアウトなら、できない人はいない。
      「このソフトで、こんなことができるのか?」といった疑問に答えられる開発者はそう多くない。
     ・「適切な変更コメントを残すこと」や「場合ごとに考えて対応する」というのはルールとして運用しづらい。
      どう書くのが「分かりやすい」コメントなのか、というのはレビュアーに負う部分が大きい。
      → 一律、変更前の状態を残すこと。
        というルールなら、日本語の「コメント」(メモじゃなくて)を残すことに不慣れな開発者にも、
        何が変更されたのかを残すことができる。

    なので、新規開発時にはコメントを残さないで開発していって、
    どこかのタイミングで、これ以降は構成管理・コメント管理の対象に格上げして、
    以降はコメントアウトして修正前を残すように……ああ、これだと、いつもと同じです。
    「保守に入ったら 或いは 結合テストを越えたら、変更部分を明確にしないといけない」なら、
    途中でコードが汚く為るのは仕方ないのかなあ。と思ってきました。

    レアケースとして、以下のようなものがある。
    ・一度作った共通関数を無効にする場合、呼び元全てを直すのでなく、関数自体を無効にする場合

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません