アカウント名:
パスワード:
コミットが遅れると、自分と重複するコードを書いていた奴とコンフリクトするから書き直しになる可能性がある、と。遅れを取らないようにコードを早く書き上げるようになるので開発速度が上がると。
上手く他人と調和するコード書いていけるうちはいいかもしれないが衝突が嫌なやつが他人と被らないようにコードを書いていくことになって、同じ機能がいろんな部分に分散する危険性もあるんじゃないかな、と。
自チームの開発に必須のコードがあって、そのコードの単体テストが甘い場合は、単体テストで明確になってない振る舞いが変更される可能性が高く、コンフリクトのリスクとコストが発生しやすい。自動マージだと、なおさら不安になるし、泥をかぶるのは自チームになる。（今までなら、チーム間のコンフリクトを解消するためのコストは普通は両チームが払う）
他チームの開発によってコードの振る舞いを変えられる可能性を減らすため、仕様として甘かった箇所を単体テストに追加する作業を、コーディングより先に行って「ここは変えるなよ」という牽制を、単体テストで宣言するという面白いスタイルになりそう。
コンフリクトの回避＆単体テストの補強により仕様が明確化がされるというオマケ付き。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
つまり早い者勝ち？ (スコア:1)
コミットが遅れると、自分と重複するコードを書いていた奴とコンフリクトするから
書き直しになる可能性がある、と。
遅れを取らないようにコードを早く書き上げるようになるので
開発速度が上がると。
上手く他人と調和するコード書いていけるうちはいいかもしれないが
衝突が嫌なやつが他人と被らないようにコードを書いていくことになって、
同じ機能がいろんな部分に分散する危険性もあるんじゃないかな、と。
Re:つまり早い者勝ち？ (スコア:3)
自チームの開発に必須のコードがあって、そのコードの単体テストが甘い場合は、
単体テストで明確になってない振る舞いが変更される可能性が高く、
コンフリクトのリスクとコストが発生しやすい。
自動マージだと、なおさら不安になるし、泥をかぶるのは自チームになる。
（今までなら、チーム間のコンフリクトを解消するためのコストは普通は両チームが払う）
他チームの開発によってコードの振る舞いを変えられる可能性を減らすため、
仕様として甘かった箇所を単体テストに追加する作業を、コーディングより先に行って
「ここは変えるなよ」という牽制を、単体テストで宣言するという面白いスタイルになりそう。
コンフリクトの回避＆単体テストの補強により仕様が明確化がされるというオマケ付き。