アカウント名:
パスワード:
まあ仕方ないと思わなくもなくもなくもないけど(VCS使っていない事自体がダメすぎてとっとと逃げる算段を計るけど)、VCS使ってまでソースをゴミで埋めたがるんだからマジで何やってるのか意味分からない。# いちおうソースコードの管理について意見を出せる立場だったので反対してみたけどダメだった
私も昔は今回のストーリーのような話を聞いたときは鼻で笑ってたものなのですが…
今受けてるプロジェクトは、上の意向でSubversionで管理してるのですが、このストーリーのネタほどではないにしても、基本的に削除修正でも削除したことを示すコメントを半ば自主的に残してます。「仕様書では○○することになってる」ものを「口頭で△△にするように指示をうけ」たりしたときに、言質を取る意味が大きいですかね。あとで「動作が仕様通りの○○になってないんですけど」って言われたりするんだもん
1行単位の修正ごとにコミットしていけば、コード上は削除してしまってもいいんだろうけど、「テスト済のコードしかコミットしちゃダメ」っていうので、ある程度まとめてコミットするしかない状況で…ファイル単位でしかログが残せないというのは、コミットログの粒度が荒すぎます。(「△△のため、削除」したところもあれば「△△にするため、□□を追加」したところもあったりして、それぞれ個別にコメントを残したい)
まあ、別にいいんじゃないですかね。目的は「分かりやすくて運用しやすい」でしょうから、杓子定規にする必要はないと思います。とにかく全部残せ!は思考停止でナンセンスですが、とにかく残すな!も同様かと。
仕様書改版させるべき。たとえソースにメモしてても「言った言わない」の範疇だし、受け入れテスト担当はそんなことは知らんから。
で、コミットログだけど...diff取って該当部分に理由を書くとか、gitでやっといてsvnなブランチにマージするときcommitもコメントもまとめるとか...かなぁ...。
元コメのACですが、私もまさに
> 仕様書改版させるべき。
これが出来てないのが最大の元凶だと思ってます。他は些細な問題。先方もわかってるんだけど、さらに上から「至急△△してくれ」みたいな話が舞い込んだりして、改版してる暇がないとかって、口答指示で対応する羽目になってる感じで…
> gitでやっといてsvnなブランチにマージするときcommitもコメントもまとめるとか
これはいい感じかも。先方がSubversion指定してきたからといって、こっちが内部で別のバージョン管理システムを併用しちゃいけない理由はありませんし。ちょっと目から鱗です。
修正した項目ごとに、行番号とか関数とかをログに書けば良いのでは?
200行目の後に、この文書をコメントでつっこんでおいてね。あと、管理よろしくね。
200行以下の行番号ね
「テスト済のコードしかコミットしちゃダメ」
この運用自体がダメっぽいけど...
ベースライン化と普段のコミットを混同してたりしやせんか?
つ「Subversion」Subversionは集中リポジトリ型だから「コミット」と言ったら「公開リポジトリへのコミット」なのさ。分散リポジトリにするsvkっつーのはあるんだけど、あれはツールと言うよりハックだからgit使うほうがいいと思う。
意味不明。
UTのないコードなんてコミットしたら、自動ビルド/テスト/デプロイできないだろ?UT書いて、コード書いて、テストして、うまくいったら、ローカルのコード更新して、マージして、ビルド、テストしてからコミットだろ?
この話はコメントの話だが、コメントはまだ、実際に動くソースの近所に有るから、ソース修正時になにが関連しているか判るけど、UTだと1か所にまとめる訳でしょ。作った当時は良いかもしれないけど、svnで管理しないといけないなど、歴史をへたら、ソース修正時になにが関連しているか訳が分からなくなるのを心配します。(心配しないといけないような、本番で納得のいくUTの例は見た事ないのですので、今のところ杞憂でしか無いですが。。。)
UTにこそ、仕様なりテスト内容なりをしっかりコメントで残すべきでしょう。「何しているか」なんてコメントはくその役にもたたない。いずれコメントとソースが一致しなくなる。仕様に対して「何をしようとしているか」「どうしたいか」を理由を含めて示していないUTなんてゴミ。
>「何をしようとしているか」「どうしたいか」を理由を含めて示していない
その変わらない、変わりにくい部分をあげつらっては、古いだの言い出すのが次世代の人間で、あなたが永久にみそっかすなら良いかもしれませんが、そうでないなら、それを言い過ぎるのは危険だと思います。(次世代のcoboler候補)
要するにそういうきもの所を徹底的にピン留めしてしまうと、その場はよくても、後で大地震とかになりがちなのも事実です。
現在進行形で関わっているプロジェクトにて修正履歴をコメントとして残すことが、ルールとして決められています。
Linux環境での開発ですが、文字コードもEUCで指定されています。これって普通なのでしょうか?
> これって普通なのでしょうか?
文字コードがEUCについては、歴史のあるプロジェクトなら普通。今から始めるならUTF-8だろうけど。
修正履歴を残す方は普通じゃない。(さすがにバージョン管理システムは使ってるんだよね?)うちの場合は、コーディング規約で修正履歴を残すのを明示的に禁止しました。バージョン管理システムがなかった頃の習慣を、何も考えずに続けてる人があまりに多かったので。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
VCS使ってないなら (スコア:2, 興味深い)
まあ仕方ないと思わなくもなくもなくもないけど(VCS使っていない事自体がダメすぎてとっとと逃げる算段を計るけど)、VCS使ってまでソースをゴミで埋めたがるんだからマジで何やってるのか意味分からない。
# いちおうソースコードの管理について意見を出せる立場だったので反対してみたけどダメだった
Subversion使ってるけど (スコア:2, 興味深い)
私も昔は今回のストーリーのような話を聞いたときは鼻で笑ってたものなのですが…
今受けてるプロジェクトは、上の意向でSubversionで管理してるのですが、このストーリーのネタほどではないにしても、基本的に削除修正でも削除したことを示すコメントを半ば自主的に残してます。
「仕様書では○○することになってる」ものを「口頭で△△にするように指示をうけ」たりしたときに、言質を取る意味が大きいですかね。
あとで「動作が仕様通りの○○になってないんですけど」って言われたりするんだもん
1行単位の修正ごとにコミットしていけば、コード上は削除してしまってもいいんだろうけど、
「テスト済のコードしかコミットしちゃダメ」っていうので、ある程度まとめてコミットするしかない状況で…
ファイル単位でしかログが残せないというのは、コミットログの粒度が荒すぎます。
(「△△のため、削除」したところもあれば「△△にするため、□□を追加」したところもあったりして、それぞれ個別にコメントを残したい)
Re:Subversion使ってるけど (スコア:2, すばらしい洞察)
まあ、別にいいんじゃないですかね。
目的は「分かりやすくて運用しやすい」でしょうから、杓子定規にする必要はないと思います。
とにかく全部残せ!は思考停止でナンセンスですが、とにかく残すな!も同様かと。
Re:Subversion使ってるけど (スコア:2)
仕様書改版させるべき。
たとえソースにメモしてても「言った言わない」の範疇だし、受け入れテスト担当はそんなことは知らんから。
で、コミットログだけど...diff取って該当部分に理由を書くとか、gitでやっといてsvnなブランチにマージするときcommitもコメントもまとめるとか...かなぁ...。
Re: (スコア:0)
元コメのACですが、私もまさに
> 仕様書改版させるべき。
これが出来てないのが最大の元凶だと思ってます。他は些細な問題。
先方もわかってるんだけど、さらに上から「至急△△してくれ」みたいな話が舞い込んだりして、改版してる暇がないとかって、口答指示で対応する羽目になってる感じで…
> gitでやっといてsvnなブランチにマージするときcommitもコメントもまとめるとか
これはいい感じかも。
先方がSubversion指定してきたからといって、こっちが内部で別のバージョン管理システムを併用しちゃいけない理由はありませんし。ちょっと目から鱗です。
Re: (スコア:0)
修正した項目ごとに、行番号とか関数とかをログに書けば良いのでは?
Re: (スコア:0)
200行目の後に、この文書をコメントでつっこんでおいてね。
あと、管理よろしくね。
200行以下の行番号ね
Re: (スコア:0)
この運用自体がダメっぽいけど...
ベースライン化と普段のコミットを混同してたりしやせんか?
Re:Subversion使ってるけど (スコア:1)
つ「Subversion」
Subversionは集中リポジトリ型だから「コミット」と言ったら「公開リポジトリへのコミット」なのさ。
分散リポジトリにするsvkっつーのはあるんだけど、あれはツールと言うよりハックだからgit使うほうがいいと思う。
Re: (スコア:0)
意味不明。
UTのないコードなんてコミットしたら、自動ビルド/テスト/デプロイできないだろ?
UT書いて、コード書いて、テストして、うまくいったら、
ローカルのコード更新して、マージして、ビルド、テストしてからコミットだろ?
Re: (スコア:0)
この話はコメントの話だが、コメントはまだ、実際に動くソースの近所に有るから、ソース修正時になにが関連しているか判るけど、
UTだと1か所にまとめる訳でしょ。
作った当時は良いかもしれないけど、svnで管理しないといけないなど、歴史をへたら、ソース修正時になにが関連しているか
訳が分からなくなるのを心配します。
(心配しないといけないような、本番で納得のいくUTの例は見た事ないのですので、今のところ杞憂でしか無いですが。。。)
Re: (スコア:0)
UTにこそ、仕様なりテスト内容なりをしっかりコメントで残すべきでしょう。
「何しているか」なんてコメントはくその役にもたたない。いずれコメントとソースが一致しなくなる。
仕様に対して「何をしようとしているか」「どうしたいか」を理由を含めて示していないUTなんてゴミ。
Re: (スコア:0)
>「何をしようとしているか」「どうしたいか」を理由を含めて示していない
その変わらない、変わりにくい部分をあげつらっては、古いだの言い出すのが次世代の人間で、
あなたが永久にみそっかすなら良いかもしれませんが、そうでないなら、それを言い過ぎるのは
危険だと思います。(次世代のcoboler候補)
要するにそういうきもの所を徹底的にピン留めしてしまうと、その場はよくても、後で大地震とか
になりがちなのも事実です。
Re: (スコア:0)
現在進行形で関わっているプロジェクトにて
修正履歴をコメントとして残すことが、ルールとして決められています。
Linux環境での開発ですが、文字コードもEUCで指定されています。
これって普通なのでしょうか?
Re: (スコア:0)
> これって普通なのでしょうか?
文字コードがEUCについては、歴史のあるプロジェクトなら普通。
今から始めるならUTF-8だろうけど。
修正履歴を残す方は普通じゃない。(さすがにバージョン管理システムは使ってるんだよね?)
うちの場合は、コーディング規約で修正履歴を残すのを明示的に禁止しました。
バージョン管理システムがなかった頃の習慣を、何も考えずに続けてる人があまりに多かったので。