あなたの最高のプログラマーは、他の全員のコードをソース管理にチェックインする必要がありますか？
svnとgitの違い の1つは、リポジトリへのアクセスを制御する機能です。誰が変更をコミットすることを許可されるべきかについての見方が異なるため、2つを比較するのは難しいです！
この質問は、どこかの会社のチームの中央リポジトリとしてgitを使用することに関するものです。チームのメンバーは、ほとんどの会社と同じように、さまざまなスキルレベルを持っていると想定します。
Gitは、あなたの最高の（最も生産的で、最も経験豊富な）プログラマーだけがコードのチェックインを信頼されていると想定しているようです。その場合は、実際にコードを書くのではなく、他の人のコードを確認してチェックインすることになります。これは報われますか？私は本当にこの質問に焦点を当てたいと思います 一般的なバージョン管理のベストプラクティス ではなく、あなたの最高のプログラマーの時間の最善の使い方は何ですか？当然のことながら、彼らの仕事のかなりの部分が他の人のコードをレビューすることである場合、優れたプログラマーは辞めますか？私は両方の質問を要約すると思います：レビューは生産性ヒットの価値がありますか？
あなたの質問からははっきりしないので、ゲートキーパーのワークフローは決してgitでは必要ないことを指摘しておきます。信頼できない寄稿者が多数いるため、オープンソースプロジェクトで人気がありますが、組織内ではそれほど意味がありません。必要に応じて、全員にプッシュアクセスを許可するオプションがあります。
人々がこの分析で無視しているのは、優れたプログラマーがとにかく他のプログラマーの壊れたコードを扱うのに多くの時間を費やすということです。誰もがプッシュアクセスを持っている場合、ビルドは失敗します、そして最高のプログラマーは、物事が壊れたときに犯人を頻繁に統合して追跡するものである傾向があります。
プッシュアクセスを持っているすべての人についての事は、何かが壊れたとき、引っ張った人は、問題のあるコミットが元に戻されるか修正されるまで壊れたビルドを取得することです。ゲートキーパーワークフローでは、ゲートキーパーのみが影響を受けます。言い換えれば、あなたはすべてのプログラマーではなく、最高のプログラマーの1人だけに影響を与えています。
コードの品質はかなり高く、ゲートキーパーの費用対効果の比率はまだ価値がないことがわかるかもしれませんが、おなじみの費用を無視しないでください。生産性の低下に慣れているからといって、生産性が低下しないわけではありません。
また、ハイブリッドオプションを検討することを忘れないでください。誰でもプッシュできるリポジトリをgitで設定するのは非常に簡単です。次に、上級開発者、テスター、または自動継続的統合サーバーなどのゲートキーパーに、変更が2番目のより安定したリポジトリに変更されるかどうか、いつ作成されるかを決定させます。そうすれば、両方の利点を最大限に活用できます。
私は、チェックインがチームリードのみに制限されていた（そしてチームリードが自分のコードをチェックインできなかった）仕事をしてきました。これは、主にゲートチェックインと静的分析の周りでさえ、不正なコミットがコードベースに侵入した多くのインシデントのために、コードレビューを実施するためのメカニズムとして機能しました。
一方で、それは仕事でした。それらがコードベースに入る前に（そして誰かがそれらに偶然出会うまで一週間かそこらすぐに忘れられて）多くの悪いコミットが見つかりました。これにより、コードベースの中断が少なくなりました。加えて、私はフォーマットや構造化を技術的な負債になる前に押し戻すことができました。彼らはバグになる前にいくつかのバグをキャッチします。そして、それは私のチームがやっていることに素晴らしい感触を与えてくれました。
一方、別のリードを追跡してコミットさせる必要があるため、3行の変更がコミットするのに4時間かかったとき、それは自発的に殺人の怒りに陥りました。これにより、ベストプラクティスよりもはるかに少ない頻度でコミットするようになり、コミットを行った開発者への変更を追跡しようとする問題が発生する場合がありました。
最も必要な環境を除いて、私は一般にそれをお勧めしません。レビューとコミットを行うことは実際にはそれほど悪くはありませんでした。私自身のプロセスが他人の気まぐれに依存していることは腹立たしかったです。開発者がコードをチェックインするのを信頼できない場合は、より優れた開発者を取得してください。
いいえ。誰でもコミットできるはずです。
バグのコミットに問題がある場合、それはソース管理ポリシーではなく、間違っています。彼/彼女がコミットしたものが機能することを確認するのに失敗するのは開発者です。したがって、何をいつコミットするかについて明確なガイドラインを定義する必要があります。
もう1つの優れた点は、単体テストと呼ばれるものです;）
ただし、代替手段があります。
a）分散バージョン管理を使用する場合は、プルリクエストのみを実行できるメインリポジトリを作成できます。このようにして、メインブランチを制御しながら、すべての開発者が独自のコードのバージョン管理を取得できます。
b）Subversionなどでは、各開発者がパッチを作成してメインブランチに入れるブランチを使用できます。
Gerrit などのプロジェクトを見て、すべての開発者がコードを「review」ブランチに1回プッシュできるようにする必要があります。あなたのシニア/リード開発者は、彼らがマスター/リリースにプッシュできるこれらの変更に満足しています。
満足していない場合は、コード行の横にコメントを残したり、更新されたパッチを要求したりできます。
このように、変更が保留されている人は準備ができてすぐにそれを入手でき、資格のある人（Gerritで適切な+2特権を持っている人）だけがそのコードをプッシュしてテストし、後で本番環境に置くことができます。
いいえ、それはあなたの最高の才能の不十分な使用です。出版会社が最も成功した著者を選び、編集を行わせると想像してみてください。悪いアイデア。
コードレビューがあるはずですが、それは常にシニアがジュニアのコードをチェックしているという意味ではありません。最終的には、チームの全員が最小限のガイダンスでコードを提供できるレベルに到達することが期待されます。彼らは3つの信頼レベルを通過します：
- なし-チェックインする前にコードのすべての行を確認します。
- 一部-何をしているのか教えてください。フィードバックを提供します
- ほとんど-仕事に取り掛かり、必要なときだけ助けを求めます。
才能を解放する利点：
- デザインに焦点を当てる
- コーディング標準と実施戦略の設定への関与（手動ですべてを行うことなく）
- 難しいコーディング問題に取り組む
- メンターシップを提供する（コードのすべての行を承認する必要はありません）
1日中コーディングすることを好まない可能性がある管理パスに関心のある開発者がいます。他の人を放っておいてください。
レビューは生産性に見合う価値がありますか？
それはチームの「バランス」とレビューの設定方法に依存します。どちらも管理とチームワークの問題であり、バージョン管理の技術的な魔法（集中型または分散型）がこれに大きな影響を与えることはありません。
間違って行った場合、生産性のヒットはもちろんレビューの利点をすべて殺します。答えはレビューのアイデアを落とすのではなく、正しい方法を見つけることです。
レビューに問題がないかどうかを確認する方法の1つは、レビューに費やした時間を追跡するために issue tracking tool を使用することです（一部のコードレビューツールでも可能です）。レビューにかなりの時間がかかっていることがわかった場合は、何かを改善するための理由と方法を見つけるために少し努力してください。また、コードレビューで潜在的な問題を発見するためにチームメンバーと 通常の1：1s を使用しても問題ありません。
チームの「最高の」プログラマーが、くだらないコーダーによって生成された理解できないごみを掘り起こすのに何時間も費やすことを余儀なくされている場合、解決策は、VCSテクノロジーにアピールするのではなく、がらくたメーカーを攻撃することです。
- 過去のプロジェクトの1つで、テストをビルドして実行するだけで1時間近くかかったコンポーネントで、永続的にパフォーマンスが低いチームメンバーによって行われたコード変更をレビューするよう割り当てられました。私は差分を読み始め、コンパイル不可能な変更に気付いたとき、レビューを終了し、必要なコメントを投稿し、コードがコンパイルされたことの書面による確認とともに追加のレビューリクエストが確実に送信されるように経営陣に依頼しました。その男が去って以来、「レビューリクエスト」はありませんでした。
一方、チームのバランスが合理的である場合、コードレビューは楽しく教育的です。私の以前のプロジェクトでは、100％のコードレビューの要件があり、それほど時間もかからず、気が散ることもありませんでした。レビューを通じて発見されたバグがあり、コーディングスタイルとデザインの選択についての議論がありましたが、それは...normalだと感じました。
「レビューのため」のテストのためにQAに到達してから数週間、コードの変更がブロックされている場合、VCSのトリックについて調査することは、この問題を解決する可能性が最も低い方法です。代わりに、レビュープロセスがどのように編成されているかで問題を見つけることに、彼らの努力をより集中させることができます。
- -レビューアが突然病気になったため、この変更の統合が大幅に遅れました。
- こんにちは！ Hell-lo-o-o、そのような場合に対処するためにbackupレビュー担当者を雇うことを考えたことがありますか？
はい。ただし、分散ソース管理について話している場合のみです。一元化された-それは依存します。
プログラマが少ない場合は、ほとんど時間がかかりません。確かに、後でバグや技術的負債を取り除くために必要な修正よりも少ないです。
非常に多くのプログラマーがいる場合、実際のコードレビューのタスクを代理人に委任し、主な開発者に疑いもなく（ほぼ）変更をプルさせることができます。これはLinuxカーネルで機能します。もっと大きなソフトウェアプロジェクトがあるとは思いません...
繰り返しになりますが、プロジェクトが小規模な場合、リードは誰が優れたコードを提供し、誰が悪いコードを生成したかをすばやく確認します。 J.Randomがアーキテクチャの決定をチェックするだけで十分なコードを書いているのに対し、インターンはマージする前に1行ずつ確認する必要のある悪いコードを書いていることがすぐにわかります。このようにして生成されたフィードバックにより、メンテナンスの負担が軽減され、インターンが実際に学習し、社内で維持する必要のあるすべてのものを直接体験できます。他のgitリポジトリからのブランチのプルとマージには、文字どおり数十秒かかります。通常、コミットメッセージのタイトルの読み取りには時間がかかるため、他の人のコードをマージする優れたコードを書くのに信頼できる人を知った後問題ではありません。
コードレビューは、あなたの最高のプログラマーだけの注意を必ずしも必要としません。 IMO、それは非公式なものであるべきです。新人ではないコードが本番環境にチェックインされる前の、セカンドオピニオンまたはセカンドペアの目。それは、主要な見落としを軽減するのに役立つと同時に、人々が他の開発者の見方に触れることにより、クラフトとしてのコーディングをより良くするのに役立ちます。
それほど不快ではないペアプログラミングライト。つまり、時間がかからず、誰かを何時間も待つ必要はありません。開発プロセスにおいて、物事を待つ人々が関わることはすべて、お金の浪費であり、IMOの勢い/士気に障害があります。
コードレビューが最初からバグの99.5％を阻止することを意図していた場合、それらがコードベースに入る前に、洗練されたバージョン管理に真の意味はありません。とは言っても、最初はgitは威圧的ですが、基本的な一般的な使用はそれほど複雑ではなく、高度に設定可能です。使用方法をすべての人に教えるには、数時間停止する必要があります。誰もがコミットします。初心者以外の新人は、何かの専門知識を発揮するまでレビューを行います。
提出される変更が「最高のプログラマ」によってレビューされている限り、誰でもコードの提出を許可されるべきです。リポジトリの制御を実施できる必要があるのは、リリースエンジニア（存在する場合）だけです。
個人的には、他の人のコードをチェックインしなければならないとしたら、腹が立つでしょう。
編集に関するいくつかの入力：いいえ、そうすべきではありません。レビューは必要な悪であり、彼らは害よりも良いことを行い、優れたプログラマーはこれを高く評価するでしょう。彼らがコードを批判する「より少ないプログラマー」の考えを好まないので、レビューに参加することに抵抗があるかもしれません。それはあまりにも悪いです。コードラインが常にバギーであり、代わりに他の人の半分焼き尽くされた投稿のクリーンアップに時間を費やす場合、彼らははるかに可能性が高いでしょう。
はい、レビューは価値があります。次の理由でレビュープロセスが比例している場合、生産性に打撃があるかどうかはわかりません。
- それはプログラマーを正直に保ちます-あなたがそれがレビューされることを知っているなら、人々はより少ないショートカットを取るでしょう
- 新しいプログラマーがより経験豊富なプログラマーから学ぶのを助けます
- ドメイン固有の知識を移転するのに役立ちます
- レビューは、バグや潜在的な問題を見つけて修正できるもう1つのゲートです
すべてのプログラマがソース管理を使用できないようにすることで、変更を追跡したり、間違いを元に戻したり、合理的な変更履歴を確認したりできなくなります。自分の「最高の」プログラマーだけがgitにチェックインできるようにしたいと思うかどうかはわかりません。
そうは言っても、リリースブランチなど、特定の主要なブランチを担当する人がいるのは理にかなっていると思います。この場合、誰もがgitリポジトリを使用できると思いますが、リリースブランチにマージするのは特定の人だけです。これをgitで強制する方法があるかどうかはわかりませんが、プロセスによって実行でき、他の誰もチェックインしていないことを確認するだけで可能です。
リリースブランチへのマージは、「最高の」プログラマーによって行われるか、十分なレビューが行われた後に有能な人々によって行われる可能性が高くなります。