あぶない現場でよく見る風景。
ソースのコメントの誤字くらい、さっさとコミットしろよ。
レビュー議事録に書いとくからさ。
そうして、新人君が閉じコメントを書き誤って、週末フルビルドが失敗して、月曜日に客から大目玉を食らうわけです。
そうかといって、ソースのコメントの誤字訂正のためだけに、
週末をつぶして
1万項目の再帰テスト
をやらされるテスターの皆様もまた不幸です。
しかし上記の例では、
コミット前のコンパイル確認
をするだけで防げる話なので、かなりの飛躍があるのです。
この手の話で、悪い意味でいい加減な連中がよく使う詭弁は以下のようなものです。
コンパイル確認しても
ビルド結果は保証されない。
というものです。実務ボケしたマネジャー諸氏は、それで煙にまかれてしまうわけですな。
さて、ビルド作業はビルドマシンや、リリースビルド環境にて実施するのが当たり前ですが、まともな現場[*1]ではコーダーが正式のリリース用ビルド環境と同じコピー環境を自ら整備して、ビルド確認するのは当然のルールとなっています。
そうなっていない現場はちょっと考えを改めた方が良いです。
あるいは、CIツールによって
コミットしたら
勝手にビルドしてエラーが出たら
メールで通知してくれる
という環境もあるかもしれません。それでも本物のコーダー[*1]は、手元でビルド環境を持っていて、そちらで確認したうえでコミットします。
誤字脱字なケアレスミスをコミット前に潰すのは当たり前だからです。
ただし、コミット先が、
内部リポジトリにコミットしてから
正式(リリース用)リポジトリにコミットする
というように複数に分かれている場合はちょっと事情が異なるかもしれません。
ケアレスミスや誤字脱字、コンパイルエラーも含めてリポジトリに記録として残す場合は、そのままコミットして良いからです。そのような管理志向の現場では逆に、
どんなタイミングでコミットするべきか
が明確にルール化されているはずで、それに従うべきです。
# 本物のコーダはこのルールに従わずトラブルの原因になったりします
さて、言い訳にはこういうものもあります。
ビルドに何時間もかかるからいちいちやってられない。
ソースツリーが肥大化した現場での言い訳の常套句ですね。
まともな現場では、バイナリ分割が実施されており、全ソースを全コンパイルしなくてもよい仕組みが導入されています。
問題は、上記のような言い訳を吐く連中は、ビルド手順を”口伝”で覚えているため、マニュアルも読まず、構成管理チームのメールもスルーしているため、この仕組みを”知らない”のです。
サボればサボるほど手が抜ける仕組みです。
ビルドマニュアルを読んでないから、
部分ビルドのやり方がわからない
→ビルド確認もせずにコミットして楽でいいよな全く
ビルド環境すら自分で整備できない作業者レベルのコーダに対しては、
お前らコーダー作業者は
作業マニュアルちゃんと読め
の姿勢で対応する必要があるでしょう。
[*1]
まともな現場というのは、プロジェクトが継続的に受注されていて、人材を使い捨てにせず、給与不払いもなく、客も外注も利益が出ている現場という意味です。
