- PR -

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

«前のページへ 1|2
投稿者投稿内容
一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2009-04-02 11:28
ナシです。

ソース管理ツールで差分を見づらくなります。
ソースそのものも見づらくなります。

初めの数回は「可読性が損なわれない範囲」でいけるかもしれませんが…
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2009-04-02 11:41
引用:

Jittaさんの書き込み (2009-04-01 20:21) より:

但し、何故（修正して）今のコードになったのかというコメントは、おおいに入れるべきだと考えています。

小規模ならともかく、それもソース管理ツールのお仕事にしていますね。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
indigo-x
大ベテラン
会議室デビュー日: 2008/02/21
投稿数: 207
お住まい・勤務地: 太陽の塔近く
投稿日時: 2009-04-02 17:43
私はリファクタリングできるフェーズまではコメント無しで修正
します。（当たり前。。。？！）

で、システム試験、運用試験レベルからは

古いソースも残して修正します。＜＜＜　これはなるべく小手先で修正したい！！

ドラスティックな修正が入った場合は難しいです。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2009-04-07 21:52
引用:

じゃんぬねっとさんの書き込み (2009-04-02 11:41) より:
小規模ならともかく、それもソース管理ツールのお仕事にしていますね。

ええ、小規模の改造です。改造じゃなく、「障害修正」。

改造の場合、管理ツールにも「バージョン X への改修」としか入力しません。コード上にも、「バージョン X による変更」程度。仕様書が作ってあるはずだから。
障害修正の場合、管理ツールのコメントには「障害番号 Y の修正」として、コードの直したところに「（簡単な修正理由）」と入れます。障害の理由や対応方法は、障害管理票に載っているはずだから。
Gio
ぬし
会議室デビュー日: 2003/11/28
投稿数: 350
お住まい・勤務地: 都内から横浜の間に少量発生中
投稿日時: 2009-04-10 00:47
アンチパターンの一種に lava flow（参照されていないクラスやメソッドが大量に残っていて読解性を損なう）というものがありますが、古いコードをコメントアウトして残すというのはこれの亜種ではないかと思います。

障害修正の場合の対応方法もプロジェクト毎ですが、私の意見が通るプロジェクトでは以下の方法を提案させていただきました。Jitta さんが書かれたものとほぼ同じですが。


  • 構成管理ツールでのコミットコメントは「IT不具合No.XXX に対応」程度で簡単に記入
  • ソースファイルの先頭に近いところに
    コード:
    // 00001 IT不具合No.XXX に対応 by Gio

    と記入
  • ソースファイルの修正箇所は
    コード:
    // 00001 2009/4/10 modify start by Gio
// データ規模が増大した場合のパフォーマンス劣化を修正
...（修正後コード）
// 00001 2009/4/10 modify end

    といった感じで修正範囲を明示
  • 不具合管理表に事象（システムダウン、出力の誤り、性能問題等）、理由、分析結果、対応方法、対応者、対応日時を記入


ドラスティックな変更（アルゴリズムを別のものに変更した等）を加えた時は修正前のコードをコメントアウトして残す場合もありますが、それでも次のリビジョンではばっさり削除して「古いコードを見たい場合はリビジョン 1.10 以前を参照」程度の 1 行コメントに置き換えてしまいます。


修正とは別に、やや複雑なアルゴリズムを実装する場合などは、どうしてその方法を採ったか、代替アルゴリズム（将来仕様変更が入った場合に再度検討する候補として残しておく）、利用時の注意事項（事前に別のメソッドが実行済みでなければならないとか、マルチスレッド対応は不要なのでこの方法にしたが対応要の場合は synchronize しろとか）などを、詳細設計ドキュメントにも書きますが、ソースにも書くようにしています。
この辺りの状況は他の皆様と若干異なるかもしれません。
（フリーランスで 1 プロジェクトあたり 6 か月程度の参画が続いており、常に引継ぎを考えてコードを書くようにしているためです。）
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）