アカウント名:
パスワード:
コミットが遅れると、自分と重複するコードを書いていた奴とコンフリクトするから書き直しになる可能性がある、と。遅れを取らないようにコードを早く書き上げるようになるので開発速度が上がると。
上手く他人と調和するコード書いていけるうちはいいかもしれないが衝突が嫌なやつが他人と被らないようにコードを書いていくことになって、同じ機能がいろんな部分に分散する危険性もあるんじゃないかな、と。
自チームの開発に必須のコードがあって、そのコードの単体テストが甘い場合は、単体テストで明確になってない振る舞いが変更される可能性が高く、コンフリクトのリスクとコストが発生しやすい。自動マージだと、なおさら不安になるし、泥をかぶるのは自チームになる。（今までなら、チーム間のコンフリクトを解消するためのコストは普通は両チームが払う）
他チームの開発によってコードの振る舞いを変えられる可能性を減らすため、仕様として甘かった箇所を単体テストに追加する作業を、コーディングより先に行って「ここは変えるなよ」という牽制を、単体テストで宣言するという面白いスタイルになりそう。
コンフリクトの回避＆単体テストの補強により仕様が明確化がされるというオマケ付き。
修正が重複しないように設計、開発管理するとかシステムが修正を認識しやすいコード規約とか。
もうちょっと贅沢言えば、ソースそのものではなく一旦論理的単位でバラしてcommitするような仕組みとかね。indent通してからcommitするのの拡張みたいな。
結局
＞マージ時に発生する問題を避けるために同時に開発する機能に制限を加えざるを得なくなり
を大声にするか小声にするだけかのような感じですかね
コンフリクトした後の修正がいやだから、別のフォルダ（管理外）で作業して、最新のソース取得してそれに上書き後、コミットしてたやつがいて大変だった※彼はコンフリクトしない方法としてあみだしと自慢してた
コミット時にテストが走る方式だとコンフリクトするはずだった機能のテストがコケるからバレるよ。
そういう奴には今回の仕組みは有効に働くかな。ただコンフリクトが起きなきゃいいんじゃなくて、コンフリクトはまずは正しく回避して、それができずに発生したら正しく解決しましょう、と。
それはgitのブランチ分け+rebaseと違うの?「大変だった」というには、いろいろ問題があったのだろうし、rebaseもコンフリクトを完全に排除する訳じゃないけど。
...まさか「上書き」の際に、元ソースの本来ぶつかる部分を戻しちゃってたとか?
君は元コメを理解するには恵まれすぎているようだな。てかrebaseはマージしたものの管理方法が違うだけで普通にマージだよ。
そのまさかでしょう。
それは即時ビルドブレークを発生させ、最終コミット者として彼が周りからの袋叩きに合うと思うのだが違うのか？
実はそれに必要なのが、参加全員の立場の均等化。均等化が成されていれば、自然と事前の情報の共有の必要性は認識される。最初は難しくとも、問題が出る度に考えれば、そのうちは何とかなる。
均等化が成されて居なければ、そりゃ無理言う奴の弊害を周りが被るって良くある光景になるだけ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
つまり早い者勝ち？ (スコア:1)
コミットが遅れると、自分と重複するコードを書いていた奴とコンフリクトするから
書き直しになる可能性がある、と。
遅れを取らないようにコードを早く書き上げるようになるので
開発速度が上がると。
上手く他人と調和するコード書いていけるうちはいいかもしれないが
衝突が嫌なやつが他人と被らないようにコードを書いていくことになって、
同じ機能がいろんな部分に分散する危険性もあるんじゃないかな、と。
Re:つまり早い者勝ち？ (スコア:3)
自チームの開発に必須のコードがあって、そのコードの単体テストが甘い場合は、
単体テストで明確になってない振る舞いが変更される可能性が高く、
コンフリクトのリスクとコストが発生しやすい。
自動マージだと、なおさら不安になるし、泥をかぶるのは自チームになる。
（今までなら、チーム間のコンフリクトを解消するためのコストは普通は両チームが払う）
他チームの開発によってコードの振る舞いを変えられる可能性を減らすため、
仕様として甘かった箇所を単体テストに追加する作業を、コーディングより先に行って
「ここは変えるなよ」という牽制を、単体テストで宣言するという面白いスタイルになりそう。
コンフリクトの回避＆単体テストの補強により仕様が明確化がされるというオマケ付き。
早いもの勝ちは別として... (スコア:1)
修正が重複しないように設計、開発管理するとかシステムが修正を認識しやすいコード規約とか。
もうちょっと贅沢言えば、ソースそのものではなく一旦論理的単位でバラしてcommitするような仕組みとかね。
indent通してからcommitするのの拡張みたいな。
Re: (スコア:0)
結局
＞マージ時に発生する問題を避けるために同時に開発する機能に制限を加えざるを得なくなり
を大声にするか小声にするだけかのような感じですかね
Re: (スコア:0)
コンフリクトした後の修正がいやだから、別のフォルダ（管理外）で作業して、
最新のソース取得してそれに上書き後、コミットしてたやつがいて大変だった
※彼はコンフリクトしない方法としてあみだしと自慢してた
Re:つまり早い者勝ち？ (スコア:1)
コミット時にテストが走る方式だとコンフリクトするはずだった機能の
テストがコケるからバレるよ。
そういう奴には今回の仕組みは有効に働くかな。
ただコンフリクトが起きなきゃいいんじゃなくて、コンフリクトは
まずは正しく回避して、それができずに発生したら正しく解決しましょう、と。
Re: (スコア:0)
それはgitのブランチ分け+rebaseと違うの?
「大変だった」というには、いろいろ問題があったのだろうし、rebaseもコンフリクトを完全に排除する訳じゃないけど。
...まさか「上書き」の際に、元ソースの本来ぶつかる部分を戻しちゃってたとか?
Re:つまり早い者勝ち？ (スコア:1)
君は元コメを理解するには恵まれすぎているようだな。
てかrebaseはマージしたものの管理方法が違うだけで普通にマージだよ。
Re: (スコア:0)
そのまさかでしょう。
Re: (スコア:0)
それは即時ビルドブレークを発生させ、最終コミット者として彼が周りからの袋叩きに合うと思うのだが違うのか？
Re: (スコア:0)
実はそれに必要なのが、参加全員の立場の均等化。
均等化が成されていれば、自然と事前の情報の共有の必要性は認識される。
最初は難しくとも、問題が出る度に考えれば、そのうちは何とかなる。
均等化が成されて居なければ、そりゃ無理言う奴の弊害を周りが被るって良くある光景になるだけ。