どうもお久しぶり。今市一郎です。
RCS、VSS、CVS、SVN、共有フォルダ、いずれを利用しても、イマイチな風景が見られます。
イマイチなところ：
リポジトリ(または共有フォルダ)へのコミット(またはチェックインなど)を行う際に、
『ソースレビュー、ウォークスルーあるいは実装検討会を経たものに限る』
といようなルールがある場合です。
複数人数、それもコミット者が何十人も百数十人もいるような場合、リポジトリにバグのあるソースがコミットされてしまうと、他のコミット者が困ります。
え？何が困るか分からない？
独立自存のソースというのはほとんどないわけで、コミットされたソースに依存するモジュールの開発者は、自分のソースを一行も変更していないのに、ある日突然どこかの馬鹿野郎がコミットしやがったバグのせいで自分のモジュールで障害や不具合が発生するようになって困ってしまうからです。
で、みんなで共有するリポジトリに、いい加減なソースをコミットしたらイカンという理由よくは分かるんですが、たいていの場合単体テストを通過するくらいまで、コミットさせてもらえません。
この運用のよくないな～と思うところは以下のようなところです。
- その間、リポジトリの管理外でソースの修正が繰り返され、履歴が残らない
- その間、実装状況や実装内容が隠蔽され、根本的な問題の指摘が遅れる
総じて、何のためにバージョン管理を使っているかよくわからない状況になります。
で、全体を統括する皆さんとしては、バージョン管理の目的が、
- ユーザや他部署へのリリース物の履歴が残ればよい
という視野狭窄を起こしていることが多いようです。
ビジネスサイドから見れば、それこそが目的なわけですが。
んが、開発サイドから見ると、
実装が固まるまでコミットできねぇんなら、zipで固めて送るから誰かかってにコミットしてくれよ
ということになってしまいます。もちろん開発者も過去のリリース間の差分を見たりコミットログで他モジュールの変遷などを見たりすることはできるので、バージョン管理の利益はある程度享受することができるわけですが。
で、リリース対象物しかコミットできない対策としてローカルにローカルなリポジトリを置いて、運用するとこれまた2重管理になります。
これが進むとどうなるかというと、ローカルから共有のリポジトリへのマージ作業でミスが頻発したりしていき、やがてさらに間抜けな状況が生じます。
そうです。
ローカルリポジトリには、チームリーダーのレビューを経てからコミットすること
というルールの創設です。
このように、現場では無駄に無駄を積み重ねる無駄な努力がおこなわれます。
雲の上のほうの人は、まさかそこまで無駄なことをしているとは考えませんが、共有リポジトリにバグバグのソースがコミットしまくられて混乱するよりはマシだということで黙認します。
このように一般に指摘されるのとは微妙に違う間抜けが原因で、規模の大きな開発の、それもバージョン管理という要因だけで、現場の生産性はジャンジャカ落ちてしまいます。
この程度の問題については先人がいくらでも解を見つけて実践しているので、興味のある人は探して欲しいです。
間違っても、「自分で素晴らしい解を見つけよう」とは思わないでください。その再発明が混乱を生むのです。
SVNならローカルでコミットしたものをまとめてリポジトリにコミットできるじゃないかとか、Gitならスマートに解決できるじゃんとかいうツッコミはウンザリです。開発者がいつでもコミットできて、それを工数ほぼゼロでリリース物に取り込んでくれる仕組みがないなら、何があっても生産性を下げるだけなのですから。
