字面は(E)ですね。
えらそうにソースコード品質を騙る阿呆は多いです。たとえばこのごみためのエントリもそのひとつかもしれません。
ごみためまんのコード品質に対する視点はシンプルです。
コーディングルールがあるか
コーディングルールは守られているか
これだけです。
コーディングルールの重箱の隅をつついて文句を言う輩もまたおおいわけですが、多くは、己の無知あるいは経験不足に由来するものですから、適当に聞き流しておくのがよろしい。
何しろニポーンでは、Javaしか経験がないのにCを書くコーダーや、C++のコンストラクタの意味すら知らないCの初級プログラマがSEをこなすのがデフォルトの国なのです。
そりゃ、発展途上国に仕事全部ぶっこ抜かれてもしかたがないですわな。あちらは専門教育をうけたエリートですから。
さて。多くの大部屋開発において実践されているコーディングルールに、修正コメントの書き方があります。それはこういうものです。
// No.XXXX 2012/07/15 ごみため商店 ごみためぞう [START]
blah, blah, blah, Braine, Brahms…
// No.XXXX 2012/07/15 ごみため商店 ごみためぞう [END]
つまり
コメントでサンドイッチすることによって、
修正箇所の責任の所在を明確にし、かつ、
diffを用いずに修正箇所のレビューを可能とする
チョーすばらしいルール（無感情・棒読み）
です。
で、大部屋開発に免疫のない方々が必ず噛み付くのがこのルールです。
いわく、
なんでdiffを使わないのか!
修正の修正がおそろしく見難くい!!
なんじゃこれわ!!!
diffを使わないのは複数会社が同じソースに相互乗り入れしているからです。大部屋でもソースのサブツリー単位で仕事を割り振りしている現場ではdiffを使います。
加えていえば、各会社の自社作業では自前のコードリポジトリで管理しています。
修正の修正が見難いといっている人たちは、歴史あるソースコードの類を呼んだことがなく経験不足なんでしょうね。
巷のオープンソースのソースコードも、歴史あるものは、そりゃもうハナモゲラですごいですよね。autoconf対応のヘッダの#ifdefに比べれば、修正コメントの３重や４重はたいしたことはないのです。
仕様書だって、長年改訂を重ねたものは、修正の修正でえらいことになるのが当然です。
なんじゃこれわと拒絶反応をする人は、オレオレコーディングをする人なんで、大部屋開発には向いてないでしょうね。こういう人は、
このコードは書き直したほうが良い！
と叫んで、風車に突進するタイプで非常に危険です。
大部屋における差分開発で必要なのは、ただただ慎重さだけなのですから。
さて、ソースコードのバージョン管理が大事なのは、中学生でも知っていることです。
なので、各種ツールを使わなくても、リリースしたソースの塊をディレクトリ単位で保存しておくくらいのことは誰でもやります。
大部屋開発でCVSやSVNを使う必要が沸いてくるのは、
調査が目的
なのです。
バグの原因
バグの影響範囲（水平展開）
バグの入り込んだバージョン(リビジョン)
（どこのどいつがバグ仕込んだ？）
などなど。
バグの影響範囲というのは、同じ根を持つどのソースツリーに同じバグが潜んでいるかを洗い出すことです。見つけたツリーすべてが水平展開対象になるわけですね。
#じつはこの際、上で書いた間抜けな修正コメントはその存在意義を発揮したりします。
まだまだ書きたいことはありますが、メンドウになってきたので端折ります。
SVNやCVSを使いこなしている連中でも、以下を知らない人が多いです。マニュアル読めばかいてあるんですけどね。
おのおのの行を最後に修正したのがいつで誰か、が分かるわけです。
svnやGitならblame、Mercurialならcvsと同じannotateです。
ちなみにごみためまんは、前任者から引き継いだ履歴スパンが20年くらいのソースツリーでcvs annotateすることによって、納得したことがあります。
前任者：「この部分は前任者の前任者のず～っとまえの時代からこのままです」
この手の話はよくあるわけですが、多くの場合に前任者(時には会社)の言い逃れだったりすることがあります。しかしすべての履歴が残っているツリーならば、cvs annotateで確認することが可能なのです。
ツリーのバージョンをず～～っと管理していないと、この情報は入手できません。
新しいプロジェクトや製品ラインを開始するたびに、あたらしいリポジトリを初期化して運用開始するような間抜けな現場では、無理だということです。
個人的には、リポジトリの運用というのは５年１０年の単位で継続しないと、投入費用を回収できない気がしています。ディスコンよけの電子部品とおなじですな。
GithubやBitbucketを見てください。数ヶ月間だけいじくったソースツリーの残骸であふれています。あの短い履歴が富を生むとは到底考えられません。
短期運用なら、冒頭で書いたサンドイッチコメントの方が１００万倍マシだということを控えめに指摘しておきます。
1週間前のソースとdiffを取れたからといって、そこに大事な情報は含まれていません。2～3年で消えるようなやりにげプロジェクトなら、リポジトリを導入する意義は、Excelの共有程度ということです。
＊＊＊
大部屋開発で残念なのは、マスターリポジトリへのコミットを開発者が行えない場合があることです。開発用ブランチとリリース管理用ブランチが別だったりして。その場合、annotateやblameに残るのは、ツリー管理者の名前ばかりになります。コミットログを見ればわかるのはコミットログにルールがあって、守られているときだけですね。
今後のバージョン管理ツールでは、ユーザ名のフィールドを増やすか、代理コミットの機能を付加してほしいものです。具体的には以下のようなものです。
# なんか、そういう機能のレビューの記憶の断片がこの記事を書かせているような
# そんなことを考えている自分にデジャヴュを感じるわたくし
“メンテナ”権限のあるユーザが代理コミットできる。
その際、ログには元の変更ユーザ名が残り、
メンテナのユーザ名も記録される。
分散バージョン管理ツールではプッシュやプルで履歴丸ごとやりとりできますから、こんな余計なことは考えないで済むはずですが、現実的なリリース管理(専任メンテナあり)になると途端にグダグダになります。
机上の空論的スマートな運用ルールなら話は簡単ですがね。
リンクル
GithubのBlameのサンプル
