人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

最近、気になる事ですが、自分が経験したどの開発現場でも、修正部分をコメントで残せ!
というルールがあって、だいたいどこでも最初のバージョンからずっと残ってて、
非常に読みづらい状態になっています。

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

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

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

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

●質問者: つきしま
●カテゴリ:ビジネス・経営 コンピュータ
✍キーワード:CVS VSS コメント コーディング ソース
○ 状態 :終了
└ 回答数 : 6/6件

▽最新の回答へ

1 ● hyo-suke
●25ポイント

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

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

◎質問者からの返答

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

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


2 ● hijk05
●30ポイント ベストアンサー

◆新規開発

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

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

◆追加開発

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

◎質問者からの返答

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

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


3 ● pkoiri
●25ポイント

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

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


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

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


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


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

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

◎質問者からの返答

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

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

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

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

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

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


4 ● RON
●10ポイント

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

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

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

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

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

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

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

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

◎質問者からの返答

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

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

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

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

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


5 ● kodomono-omocha
●5ポイント

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

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

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

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

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

◎質問者からの返答

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

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

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

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

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

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


1-5件表示/6件
4.前の5件|次5件6.
関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ