アカウント名:
パスワード:
まあ仕方ないと思わなくもなくもなくもないけど(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だろうけど。
修正履歴を残す方は普通じゃない。(さすがにバージョン管理システムは使ってるんだよね?)うちの場合は、コーディング規約で修正履歴を残すのを明示的に禁止しました。バージョン管理システムがなかった頃の習慣を、何も考えずに続けてる人があまりに多かったので。
VCSありかつコードのコメントアウト禁止というルールで開発をやってたことがありますが、どうしてもやってしまう人がいました。
削除し忘れたと言うんですが、そもそもなんでコメントアウトしておくのかと聞いてみると、適当に修正してテストしてOKだったらcommitするというやり方をしているそうです。要するに原因を突き止めて対策を練ってから修正するのではなくて、行き当たりばったりなんですね。とりあえず、そういうやり方ならコードのコメントアウトは便利だと納得はしました。
コメントの意味も含めてコードレビューをすれば、最終的にはコードのコメントアウトを削除できるはずです。このコードには意味があってとってあると言われたら、検証済みか/検証手順は整備されているか聞けば良いでしょう。レビューしないような環境なら好きなようにやらせてあげようよ。
ウチである案件なら、コメントアウトされている理由の殆どは、「仕様が確定していないから」だったりする。だからコメントに「もし客が○○と言い出したら…」なんてコメントアウトされている予備のコードがバラバラと、下手すれば有効なコードより多かったり。コードレビューなんてさせてくれれば相当にマシ。検収試験中に思いつきで変更を指示し、即日対応を求める所も珍しい話じゃない。いや、それを断れなくする為にわざと仕様を曖昧なままにする会社すら有る。
それこそソース管理でやるべきでは複数のソースを一個においとくとか可読性が下がるだけですうまく使いましょう
つか、本当に仕様変更への対応予備コードとして準備しているのであれば、#ifdef~#endifなんかでコンパイルオプションにすればいいだけ。
「予備だから事前に充分検証しない」って危険性があるのであれば適当に#warn とか #error とか織り交ぜて防護壁張っとけばいいわけだし。
とかコードレビューで突っ込んだらコメントアウトする代わりに#if 0 ~ #endif使うバカがいた...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
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だろうけど。
修正履歴を残す方は普通じゃない。(さすがにバージョン管理システムは使ってるんだよね?)
うちの場合は、コーディング規約で修正履歴を残すのを明示的に禁止しました。
バージョン管理システムがなかった頃の習慣を、何も考えずに続けてる人があまりに多かったので。
Re:VCS使ってないなら (スコア:1)
VCSありかつコードのコメントアウト禁止というルールで開発をやってたことがありますが、
どうしてもやってしまう人がいました。
削除し忘れたと言うんですが、そもそもなんでコメントアウトしておくのかと聞いてみると、
適当に修正してテストしてOKだったらcommitするというやり方をしているそうです。
要するに原因を突き止めて対策を練ってから修正するのではなくて、行き当たりばったりなんですね。
とりあえず、そういうやり方ならコードのコメントアウトは便利だと納得はしました。
コメントの意味も含めてコードレビューをすれば、最終的にはコードのコメントアウトを削除できるはずです。
このコードには意味があってとってあると言われたら、検証済みか/検証手順は整備されているか聞けば良いでしょう。
レビューしないような環境なら好きなようにやらせてあげようよ。
Re: (スコア:0)
ウチである案件なら、コメントアウトされている理由の殆どは、
「仕様が確定していないから」
だったりする。
だからコメントに
「もし客が○○と言い出したら…」
なんてコメントアウトされている予備のコードがバラバラと、下手すれば有効なコードより多かったり。
コードレビューなんてさせてくれれば相当にマシ。
検収試験中に思いつきで変更を指示し、即日対応を求める所も珍しい話じゃない。
いや、それを断れなくする為にわざと仕様を曖昧なままにする会社すら有る。
Re: (スコア:0)
それこそソース管理でやるべきでは
複数のソースを一個においとくとか可読性が下がるだけです
うまく使いましょう
Re: (スコア:0)
つか、本当に仕様変更への対応予備コードとして準備しているのであれば、
#ifdef~#endifなんかでコンパイルオプションにすればいいだけ。
「予備だから事前に充分検証しない」って危険性があるのであれば
適当に#warn とか #error とか織り交ぜて防護壁張っとけばいいわけだし。
とかコードレビューで突っ込んだらコメントアウトする代わりに
#if 0 ~ #endif
使うバカがいた...