社内SEの徒然なる日記

ソースに修正履歴を残したくないのだが Part3 修正履歴

ありがちな記載方法

前回までの経緯で、ソース自体にも修正履歴を残すことにしたのですが、どんな方法があるでしょうね?
ありがちなのが、追加はadd、更新はupd、削除はdelで囲むって方法でしょうか?
ちょっと、試して見ます。

まず、これをオリジナルとします。
	ArrayList list = new ArrayList();

list.add("100");
list.add("400");


"200"を追加します。
	ArrayList list = new ArrayList();

list.add("100");
// 2013.02.28 add start
list.add("200");
// 2013.02.28 add end

list.add("400");


"400"を"300"に更新します。更新前の"300"も確認できるように、コメント化して残しておきます。
	ArrayList list = new ArrayList();

list.add("100");
// 2013.02.28 add start
list.add("200");
// 2013.02.28 add end
// 2013.02.28 upd start
list.add("300");
//list.add("400");
// 2013.02.28 upd end

list.add("500");


"100"を削除します。
	ArrayList list = new ArrayList();
// 2013.02.28 del start
// list.add("100");
// 2013.02.28 del end

// 2013.02.28 add start
list.add("200");
// 2013.02.28 add end
// 2013.02.28 upd start
list.add("300");
//list.add("400");
// 2013.02.28 upd end


汚いですね

という風に、一連の作業を行うと、見事にゴミソースが出来上がりました。

...はい、前回の記事で「ソース自体に履歴を残す必要性がある」と書きましたが、正直に言うと、私自身も納得している訳じゃないんですよね。
こんな汚いソース、読みたくないですよ。

さらに酷いのは、修正された箇所がさらに修正された場合ですね。

では、"300"を"350"に書き換えてみます。
	ArrayList list = new ArrayList();
// 2013.02.28 del start
// list.add("100");
// 2013.02.28 del end
// 2013.02.28 add start

list.add("200");
// 2013.02.28 add end
// 2013.02.28 upd start
// 2013.03.01 upd start

list.add("350");
//list.add("300");
// 2013.03.01 upd end

//list.add("400");
// 2013.02.28 upd end


・・・もう、何が何やら分りませんね。
目的は、ソースの修正履歴が把握できることなんですから、こうなった時点で意味がありません。
そりゃ、よく読めば分りますけどね。

汚物は消滅させます

やり方はいろいろあるとは思いますが、私の場合は直感的に読めなくなってきた時点で、全てをコメントアウトして書き直しています。

先ほどの、"300"を"350"に書き換えるのであれば、こんな感じですかね。
	ArrayList list = new ArrayList();

// 2013.03.01 add 再作成
list.add("200");
list.add("300");


// 2013.03.01 del start
// // 2013.02.28 del start
// // list.add("100");
// // 2013.02.28 del end
// // 2013.02.28 add start
// list.add("200");
// // 2013.02.28 add end
// // 2013.02.28 upd start
// list.add("300");
// //list.add("400");
// // 2013.02.28 upd end
// 2013.03.01 del end


再作成したaddの部分は、add start ~ add endで囲むこともあれば、そのままの事もあります。
かなり無理やりですが、実際に動いているロジックの部分は読みやすくなりましたし、修正履歴も何とか読めます。

無い方が良いと思ってますよ

こんな感じでソース管理をしてはいますが、バージョン管理システムをキッチリ構築&維持できるのであれば、ソースに履歴を残す必要はないと思ってます。

...というか、ソースに汚いコメントなんか残したくないですよ。

オープンソースのバージョン管理システムを、自社でカスタマイズして使えるような力(技術力)があれば、こんな前時代的なことをしなくても済むのですけどね。

結局、開発者が私一人なので、頑張って環境を作っても、私が居なくなったら維持できないんです。あまり変なことをすると、後を引き継いだ人が地獄を見ますし。

自分がよければそれでよしってのは、あまりに無責任ですし。

後書き

私が文字の読み書きを覚えたのは、ド○えもんのマンガを読みたいがためだったりします。
この幼少期の体験が、頭の奥に残っているせいか、テンパると思わず「助けて、ド○えもん!」とか心の中で(稀に声にも出して)叫んじゃったりします。

...いや、可哀想な人を見るような目で見られた時の言い訳です。

それにしても「ド○えもん」、伏字にする必要ってあったかなぁ?

前回:ソースに修正履歴を残したくないのだが Part2 移行
投稿記事の一覧:目次

--- blog end --- スポンサードリンク

PageTop

コメント


管理者にだけ表示を許可する
 

同じような経験をした立場としてすごく同感しました。

私の場合は、バージョン管理ソフトの導入と同時に、曖昧だったコーディングルールを整えたのですが、なんとその時に修正履歴コメントを書く流れになりました。。。

おかげで、修正履歴コメントとコミットコメントがずれた時に調査するというとても面倒な作業が増えました。

| URL | 2015-09-17(Thu)15:24 [編集]


Re: タイトルなし

あらら、随分と面倒なことになってますね。その発想は何らかの管理の為のものだと思いますが、管理の本質ってミスや無駄を極小化して効率を上げることにあるのであって、管理作業に手間が掛かるのであれば意味が無いはずなんですが・・・

私は完成済みのソースを何年も保持する立場なので、なんだかんだ言っても修正履歴コメント(過去のソース)は残していますが、コミットコメントには、別に管理している変更管理番号を書くだけにしています。
前述の通り、本稼動後のシステム保守が主体なので、プログラムを修正する=変更案件がある=変更依頼表みたいなのがある、ってことで、プログラムを修正する目的や内容は、変更の起点になった依頼表(又は、プログラムの仕様書)の方に書くことにしています。

システムの変更内容の管理って、プログラムやバージョン管理システムのコメントではなく、大元の依頼書や仕様書で行う方がスマートだと思うのです。

> 同じような経験をした立場としてすごく同感しました。
>
> 私の場合は、バージョン管理ソフトの導入と同時に、曖昧だったコーディングルールを整えたのですが、なんとその時に修正履歴コメントを書く流れになりました。。。
>
> おかげで、修正履歴コメントとコミットコメントがずれた時に調査するというとても面倒な作業が増えました。

たかたかハリコフ | URL | 2015-09-17(Thu)20:36 [編集]