アカウント名:
パスワード:
「変更する場合には、変更前のコードを全てコメントで残して日付・変更者を記載すること。」 バージョン管理システムを使おうよ…
使わなくなった関数が大量に丸ごと残ってるとかはさすがにアレなんで、 ある程度弾力的な運用は必要だとは思いますけど。
こういうことが言っていられるうちはまだ花で, 実際には1万行の関数(ソースじゃないよ)の8~9割が修正に伴うコメント化されたコードなんてことが往々にしてあります. こういう状況だと, 現在生きているコードがどの部分かをさがすだけでも大変な手間. 一般的なパターン一致じゃ該当する関数や変数・シンボルの位置を特定することもできず, コードを修正したと思っていたら実はコメントの中だったなんてこともよくあります.
しかも巨大プロジェクトとなるとコーダーの品質は最低レベルなので, こういった「コメントで残す」という規約を設けると, 全てのコードをコピペしてコメント化し, それに手を加えるといったことをしてくれやがります. すなわちコメントは差分ではなく, 一つのソースファイル内に複数のバージョンのソースファイルが含まれているような感じになります. そのためバージョン間の変更点を探すのに一般的な差分表示はほとんど役に立たちません. しかもこうしたコピペ型コメントには一定の法則性が無い, 例えばソース全体, ブロック, 行単位でのコピペコメントなどが混在しているので, ちょっとツールでも作って整形なんてことも無理. 結果, コードの品質はひとえに人力だよりで, 加速度的に劣化していきます.
優れたエディタや統合開発環境が結果として最悪のコードを生み出すというのは皮肉としか言い様がありません.
と言っても「規約を守る」という一点においてこのような行為は正当として評価され, 改善提案は却下されることが多いです. なぜなら過去にはそれでやってこれたから. 結果, 表面化しない限りにおいて, こうしたクソコード(もはやコードですらない)は温存され, 未来へのツケとして人々を苦しめつづけることになります.
暴論ではありますが, いっそのこと一切のコメントを禁止するような規約もありかと思うようになりました. そうすれば実際に動いている物のみがコードには残りますし, コメントとコードの不一致でどちらが正しいのか悩む必要も無くなる. コメント無しで読むことが難しいような記述(変なアルゴリズムや不適切なネーミングなど)も自然に避けると, いいことずくめのような.
バージョン管理使っているのに、バージョンごとにディレクトリを分けるプロジェクトに遭遇したことがあります。1.0, 1.1, 2.0 ってツリーが分かれてるの。いや、その Linuxカーネル的なそれじゃなくて。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
コメントで残す (スコア:5, おもしろおかしい)
「変更する場合には、変更前のコードを全てコメントで残して日付・変更者を記載すること。」
バージョン管理システムを使おうよ…
HIRATA Yasuyuki
Re:コメントで残す (スコア:2, おもしろおかしい)
なんのためにバージョン管理使ってるんだかわからなくなります・・・。
Re:コメントで残す (スコア:1)
「バージョン管理使ってるんだからコメント履歴止めましょう!」って何度かかけあったら廃止の方向に向かってくれた。
Re:コメントで残す (スコア:3, 興味深い)
ソース「そのもの」はバックアップするが、
バージョン管理のリポジトリはバックアップしない(するに値すると理解してない)
という恐れがあるので気をつけるべしh。
いちいちチェックアウトしたもの「を」バックアップするのね。まあなんというか、自動車を見て「手綱はどこだ」とか訊いたという古代人のようなもんだ。新しいツールの「根本」を理解してない。
それはそうと。自衛策として、
つまりもしリポジトリが飛んだら会社も困るが開発した自分らも(萎えるし仕事が増えるから)困るので、
私はそういう場合は自分で勝手にバックアップすることにしてる。
幸い最近は普通に安く買えて使えるローカルPCのHDDが余り気味であることが多いので、
自分のPCのその余力でもって、リポジトリをバックアップしとくのだ。
ついでにドキュメント"サーバ"のバックアップも同様に"クライアントPC"に取っておくのがお勧めだ。
奴らのバックアップなんて信頼できん。「過去1週間だけ残してあればいい」なんて平気で言う奴らだからな。(それって2週間前に人知れず起こったデータ破壊には無力じゃん!)
それにバックアップ自体が有ったとしても取りだしが容易ではない(手続きを要したりツールが煩雑だったり)可能性も警戒すべきだ。
だったら自分とこでバックアップを走らせればいいんだ。もちろん使い易いツールを自分で選んでね。
サーバとクライアントの関係が逆じゃないか!と思う人は頭が固い。使えるHDDなら猫のHDDだって使う。残存したファイルが官軍。それでいいんだ。
あとクライアントはたいてい複数あるから、
同じバックアップを複数のクライアントでやればそれだけで冗長性が確保できるぞ。
Re:コメントで残す (スコア:2, おもしろおかしい)
そのうちセキュリティー対策でローカルHDDとUSB端子のないPCになりますよ。
Re: (スコア:0)
そういう環境でFORTRAN実習やったことありますよ。
Re:コメントで残す (スコア:1, 興味深い)
一体どれだけの期間残せばいいんですか?
2週間分残しても3週間前に人知れず起こったデータ破壊には無力じゃん。
永遠に残せと?
実際にはケースバイケースだろうが1週間という期間があればその手の問題は解決していると考えるのはそうおかしくはない。
後これは老婆心だが、リポジトリの複製を個人で勝手に作るのは気をつけたほうが良い。
そういう管理が出来ない奴らはどんな難癖つけてくるかわからん。その時に「信用ならんから」なんて言い訳は通らんだろう。
実際、ソースの持ち出しは大抵は禁止だろうから持ち出す気だったと詰め寄られたら危険。
やるなら自分の担当範囲にとどめておいたほうがよい。
Re: (スコア:0)
プロジェクト当初から、が理想ですね。
少なくとも自分が参加したときから、が自分にとって行動可能な最大限です。
それ以前のことはそれ以前の人らが困ってどうにかしたことでしょう。(あるいはしなかったか)
>その時に「信用ならんから」なんて言い訳は通らんだろう。
とりあえず「最新の」ドキュメントのコピーをローカルPCに取ることを許してるプロジェクトなら、
「過去のも」取っていたことを責められる合理的な理由は無いはずです。
たとえば「昨日の」奴がローカルに残ってたらそれは何?ってことになるので。
それを禁止してるプロジェクト
Re: (スコア:0)
セキュリティリスクがありませんか?
「奴ら」もあなたもミスをする確率は0では無いはずですが。
Re: (スコア:0)
PCの持ち出しを一切禁止してる環境に限ると思います。
持ち出せる奴は絶対駄目。
#でも上司がノート(しかも営業で持ち出しもする)でやってるのを見たことが有るAC
それを満たすとすればですが、
実際ときどきデータが消えるような状況では、
リスクとメリットはトレードオフといったところでしょう。
あと、それ以前の問題として、
サーバから外に接続できちゃう設定の部屋も多いですしね。
それだと固定PCとサーバのセキュリティ的な区別をするだけ無駄。
#そういや某メーカの鯖部屋のDB鯖たちも平気で外にアクセスできてたな。いいのかあれ?(反語)
Re: (スコア:0)
Re: (スコア:0)
そもそもフタ昔くらい前の機械(内容も更新されてない)で、
そのぶんHDDの絶対量が全然足りない、
なんてなこともザラですorz
「古い」ファイルから順次消していったりするようです。
やってることによりまちまちでしょうけど、
私が経験したいくつかのプロジェクトはDOCの量がおおむね数GB、更新も月間10%くらいかな、って感じでした。
このサイズが微妙に曲者で、
今の数百GBなHDDだと差分バックアップするのに数年単位で楽勝なんですが、
少々前の数GBなHDDだと苦しいんです。
そういう意味では、ちょうど曲がり角なのかな、という気がしました。
あと、開発者用PCよりサーバのほうが、しばしばリプレース周期が遅かったりしますしね。
というか開発者用は新人くんがくるたびに新しい機械も入るんで、冗長化するのが楽です。
Re:コメントで残す (スコア:1)
でも仕事の性質上、コメント残ってないと今の仕事の手間がもう一段増えそうだなー。
仕事の方向性によっては、別に悪いことばかりではないと思う。
使わなくなった関数が大量に丸ごと残ってるとかはさすがにアレなんで、
ある程度弾力的な運用は必要だとは思いますけど。
Re:コメントで残す (スコア:1)
こういうことが言っていられるうちはまだ花で, 実際には1万行の関数(ソースじゃないよ)の8~9割が修正に伴うコメント化されたコードなんてことが往々にしてあります. こういう状況だと, 現在生きているコードがどの部分かをさがすだけでも大変な手間. 一般的なパターン一致じゃ該当する関数や変数・シンボルの位置を特定することもできず, コードを修正したと思っていたら実はコメントの中だったなんてこともよくあります.
しかも巨大プロジェクトとなるとコーダーの品質は最低レベルなので, こういった「コメントで残す」という規約を設けると, 全てのコードをコピペしてコメント化し, それに手を加えるといったことをしてくれやがります. すなわちコメントは差分ではなく, 一つのソースファイル内に複数のバージョンのソースファイルが含まれているような感じになります. そのためバージョン間の変更点を探すのに一般的な差分表示はほとんど役に立たちません. しかもこうしたコピペ型コメントには一定の法則性が無い, 例えばソース全体, ブロック, 行単位でのコピペコメントなどが混在しているので, ちょっとツールでも作って整形なんてことも無理. 結果, コードの品質はひとえに人力だよりで, 加速度的に劣化していきます.
優れたエディタや統合開発環境が結果として最悪のコードを生み出すというのは皮肉としか言い様がありません.
と言っても「規約を守る」という一点においてこのような行為は正当として評価され, 改善提案は却下されることが多いです. なぜなら過去にはそれでやってこれたから. 結果, 表面化しない限りにおいて, こうしたクソコード(もはやコードですらない)は温存され, 未来へのツケとして人々を苦しめつづけることになります.
暴論ではありますが, いっそのこと一切のコメントを禁止するような規約もありかと思うようになりました. そうすれば実際に動いている物のみがコードには残りますし, コメントとコードの不一致でどちらが正しいのか悩む必要も無くなる. コメント無しで読むことが難しいような記述(変なアルゴリズムや不適切なネーミングなど)も自然に避けると, いいことずくめのような.
Re: (スコア:0)
>優れたエディタや統合開発環境が結果として最悪のコードを生み出す
なのでしょうか?
単にこぴぺが楽なだけで、
察するにそれは「他のもっと高等な作業はちっとも楽じゃない」つまり駄目なツール、だったのじゃないでしょうか?
あるいはツールは立派でも使う人がその機能を「十分に」使わず、こぴぺという最悪の機能しか使わなかった、か。
>なぜなら過去にはそれでやってこれたから.
いつか破綻しますよね。
>いっそのこと一切のコメントを禁止するような規約もありかと思うようになりました
このほうが
Re:コメントで残す (スコア:1)
バージョン管理使っているのに、バージョンごとにディレクトリを分けるプロジェクトに遭遇したことがあります。1.0, 1.1, 2.0 ってツリーが分かれてるの。いや、その Linuxカーネル的なそれじゃなくて。
LIVE-GON(リベゴン)