あなたの最高のプログラマーは、他の全員のコードをソース管理にチェックインする必要がありますか？

svnとgitの違いの 1つは、リポジトリへのアクセスを制御する機能です。変更をコミットすることを誰に許可するべきかについての観点の違いがあるため、2つを比較するのは困難です！

この質問は、どこかの会社のチームの中央リポジトリとしてgitを使用することに関するものです。チームのメンバーのスキルレベルはさまざまであり、ほとんどの企業と同じであると想定しています。

Gitは、あなたの最高の（最も生産的で、最も経験豊富な）プログラマーだけがコードのチェックインを信頼していると想定しているようです。その場合は、実際にコードを書くのに時間を割いて、他の人のコードを確認してチェックインすることになります。これで成果はありますか？この質問は、一般的なバージョン管理のベストプラクティスではなく、最高のプログラマーの時間を最大限に活用することに焦点を当てたいと思います。当然の結果として、自分の仕事の大部分が他の人のコードをレビューすることである場合、優秀なプログラマーは辞めますか？両方の質問が要約されると思います：レビューは生産性に見合う価値があるのでしょうか？

あなたの質問からは明らかではないので、ゲートキーパーのワークフローはgitでは必ずしも必要ではないことを指摘したいと思います。信頼されていない貢献者が多いため、オープンソースプロジェクトで人気がありますが、組織内ではあまり意味がありません。必要に応じて、全員にプッシュアクセスを許可するオプションがあります。

この分析で人々が無視しているのは、優秀なプログラマーが他のプログラマーの壊れたコードの処理に多くの時間を費やしているということです。誰もがプッシュアクセスを持っている場合、ビルドは壊れます。そして、最高のプログラマーは、物事が壊れたときに犯人を頻繁に統合し追跡するプログラマーになる傾向があります。

プッシュアクセスを持っているすべての人に関することは、何かが壊れたとき、問題のコミットが元に戻されるか修正されるまで、プルしたすべての人が壊れたビルドを取得することです。ゲートキーパーワークフローでは、ゲートキーパーのみが影響を受けます。言い換えれば、あなたは最高のプログラマー全員に影響を与えるのではなく、たった1人のプログラマーに影響を及ぼしています。

コードの品質はかなり高く、ゲートキーパーの費用対効果の比率はそれでも価値がないことが判明する可能性がありますが、使い慣れた費用を無視しないでください。生産性の低下に慣れているからといって、それが発生しないわけではありません。

また、ハイブリッドオプションを検討することを忘れないでください。gitを使用すると、誰でもプッシュできるリポジトリを簡単にセットアップし、上級開発者、テスター、自動化された継続的インテグレーションサーバーなどのゲートキーパーに、変更によって2番目のより安定したリポジトリになるかどうかを判断させることができます。そうすれば、両方の長所を最大限に活用できます。

チェックインがチームリードのみに制限されている（そしてチームリードが自分のコードをチェックインできなかった）仕事で働いてきました。これは、主にゲートチェックインや静的分析の周りでさえ、悪いコミットがコードベースに侵入する多くのインシデントのために、コードレビューを実施するためのメカニズムとして機能しました。

一方で、それは仕事をしました。コードベースに入る前に、いくつかの悪いコミットが見つかりました（誰かがつまずくまで1週間ほど忘れていました）。これにより、コードベースの中断が少なくなりました。加えて、フォーマットや構造に関するいくつかの技術を借金する前に、それらを押し戻すことができました。バグになる前にいくつかのバグをキャッチします。そして、それは私のチームが何をしていたかについて素晴らしい感触を与えてくれました。

一方、3行の変更がコミットするのに4時間かかったときに、別のリードを追跡してコミットさせる必要があるため、自発的に殺人の怒りに陥りました。ベストプラクティスよりもコミットの頻度をはるかに少なくしなければならず、それを行った開発者への変更を追跡しようとすると問題が発生することがありました。

最も必要な環境を除いて、一般的には推奨しません。レビューとコミットを行うことは実際にはそれほど悪くはありませんでした。私自身のプロセスが他人の気まぐれに依存しているのは腹立たしいものでした。開発者がコードをチェックインすることを信頼できない場合は、優れた開発者を獲得してください。

いいえ。誰でもコミットできるはずです。

バグのコミットに問題がある場合、それはソース管理ポリシーではありません。コミットしたものが機能することを確認できないのは開発者です。そのため、何をいつコミットするかについて明確なガイドラインを定義する必要があります。

別の素晴らしいことはユニットテストと呼ばれます;）

ただし、代替手段があります。

a）分散バージョン管理を使用する場合は、プルリクエストのみを行うことができるメインリポジトリを作成できます。このようにして、すべての開発者は、メインブランチを制御しながら、独自のコードのバージョン管理を取得できます。

b）Subversionなどでは、各開発者がパッチを作成してメインブランチに入れるブランチを使用できます。

すべての開発者がコードを「レビュー」ブランチにプッシュできるGerritなどのプロジェクトを見てください。シニア/リード開発者がこれらの変更に満足したら、それらをマスター/リリースにプッシュできます。

満足していない場合は、コード行の隣にコメントを残したり、更新されたパッチを要求したりできます。

このようにして、保留中の変更を持っている人は準備ができ次第すぐにそれを入手でき、資格のある人（Gerritで適切な+2権限を持つ）のみがテスト用にコードをプッシュし、後で本番環境にプッシュできます。

いいえ、それはあなたの最高の才能の不十分な使用です。出版会社が最も成功した著者を採用し、編集を行わせることを想像してください。悪いアイデア。

コードレビューが必要ですが、それは常にジュニアがコードをチェックしているという意味ではありません。最終的には、チームの全員が最小限のガイダンスでコードを提供できるレベルに達することが期待されます。信頼の3つのレベルを通過します。

1. なし-チェックインする前にコードのすべての行を確認したい。
2. いくつか-あなたが何をしているのか教えてください。フィードバックをお送りします
3. ほとんど-あなたの仕事をして、必要なときにだけ助けを求めてください。

才能を解放する利点：

• デザインに焦点を当てる
• コーディング標準と施行戦略のセットアップへの関与（手動ですべてを行うことなく）
• 難しいコーディング問題に取り組む
• メンターシップを提供する（コードのすべての行を承認せずに）

管理パスに興味のある開発者がいて、1日中コーディングしない方がいいかもしれません。他の人は放っておきます。

レビューは生産性に見合うだけの価値がありますか？

チームの「バランス」とレビューの設定方法に依存します。どちらも管理とチームワークの問題であり、バージョン管理技術の魔法（集中型または分散型）がそれに大きな影響を与えることはありません。

間違って行われた場合、生産性の低下はもちろん、レビューのメリットをすべて失います。答えはレビューの考えを落とすのではなく、どうやってそれを正しくするかを見つけることです。

レビューに問題がないかどうかを確認する1つの方法は、問題追跡ツールを使用してレビューに費やした時間を追跡することです（一部のコードレビューツールでも可能です）。レビューにかなりの時間がかかっていることがわかった場合は、物事を改善する理由と方法を見つけるために努力を払ってください。また、コードレビューの潜在的な問題を発見するために、チームメンバーと定期的に1：1で連絡しても害はありません。

チーム内の「最高の」プログラマが、くだらないコーダーによって生成される不可解なゴミを掘り下げることに時間を費やす場合、解決策は、VCSテクノロジーに訴えるのではなく、がらくたメーカーを解雇することです。

• ^{過去のプロジェクトの1つで、テストをビルドして実行するのに1時間近くかかったコンポーネントで、永続的にパフォーマンスの低いチームメンバーによって行われたコード変更をレビューするように割り当てられました。diffの読み取りを開始し、コンパイルできない変更に気付いたとき、レビューを終了し、必要なコメントを投稿し、管理者にコードのコンパイルの確認が書面で確認されるように依頼しました。それ以来、「レビューリクエスト」はありませんでした。}

一方、チームのバランスが適切であれば、コードレビューは楽しくて教育的です。私の以前のプロジェクトでは、100％のコードレビューの要件があり、多くの時間も気を散らすこともありませんでした。レビューを通じて発見されたバグがあり、コーディングスタイルとデザインの選択について議論がありましたが、それはただ普通に感じられました。

「レビューのため」のテストのためにQAにアクセスしてから数日...コード変更がブロックされている場合、VCSのトリックについて研究することがこの問題を解決する可能性が最も低いでしょう。代わりに、レビュープロセスの編成方法で問題を見つけることに努力を集中することをお勧めします。

• <sup>-レビュー担当者が突然病気になったため、この変更の統合は大幅に遅れました。
  - こんにちは！Hell-lo-oo、あなたはそのようなケースに対処するためのバックアップレビューアを持つことを考えたことがありますか？</sup>

はい。ただし、分散ソース管理について話している場合のみ。一元化された-それは依存します。

プログラマが少ない場合は、時間がかかりません。後でバグや技術的負債を取り除くために必要な修正よりも確かに少ない。

非常に多くのプログラマーがいる場合、実際のコードレビューのタスクを中euに委任し、リード開発者に変更を（ほぼ）疑いなくプルさせることができます。Linuxカーネルで動作しますが、より大きなソフトウェアプロジェクトがあるとは思いません...

繰り返しますが、プロジェクトが小さい場合、リードはすぐに誰が良いコードを提供し、誰が悪いコードを生成するかを確認します。彼は、J.Randomがアーキテクチャの決定をチェックするだけで良いコードを書いているのに対し、インターンはマージする前に行ごとにレビューする必要がある悪いコードを書いていることをすぐに見るでしょう。このようにして生成されたフィードバックは、メンテナンスの負担を軽減し、インターンが実際に学習し、社内で保持する必要があるものを直接体験できます。他のgitリポジトリからブランチをプルしてマージするには、文字通り（カップル）数十秒かかります。通常、コミットメッセージのタイトルの読み取りには時間がかかります。そのため、他の人のコードをマージするのに信頼できる人を誰が知っているかは問題ではありません。

コードレビューでは、必ずしもあなたの最高のプログラマーだけが注意を払う必要はありません。IMO、それは非公式のものであるべきです。プロダクションにチェックインする前に、ルーキーでない人からのコードの一部についてのセカンドオピニオンまたはセカンドペア。それは主要な見落としを軽減するのに役立ち、他の開発者の視点にさらされることで人々が工芸としてのコーディングをより良くするのにも役立ちます。

それほど不快ではないペアプログラミングライトのようなもの。つまり、時間がかからず、何時間も誰かを待つ必要はありません。開発プロセスで物事を待っている人が関与することは、お金の無駄であり、IMOである勢いや士気を損なうものです。

そもそもコードベースに侵入する前に、コードレビューがバグの99.5％を阻止することを意図していた場合、洗練されたバージョン管理の本当の意味はありません。とは言っても、gitは最初は威圧的ですが、基本的な一般的な使用はそれほど複雑ではなく、高度な設定が可能です。数時間停止して、みんなにそれを使用する方法を教えることができるはずです。みんなコミットします。最も熱心な新人を除くすべてが、何かの専門知識を示すまでレビューします。

提出された変更が「最高のプログラマー」によってレビューされている限り、誰でもコードの提出を許可されるべきです。リポジトリの制御を実施する権限を持つ必要があるのは、リリースエンジニアのみです（その人がいる場合）。

個人的には、他の人のコードをチェックインしなければならなかった場合、私はうんざりするでしょう。

編集に関する入力：いいえ、できません。レビューは必要な悪であり、彼らは害よりも良いことをし、優れたプログラマーはこれを高く評価するでしょう。レビューに参加することをためらうのは、「より少ないプログラマー」がコードを批判するという考えを好まないからかもしれません。それはただ残念です。コードラインが常にバグであり、代わりに他の人の半ば提出された後のクリーンアップに時間を費やす場合、彼らは終了する可能性がはるかに高くなります。

はい、レビューは価値があります。レビュープロセスが次の理由で比例する場合、生産性が低下するかどうかわかりません。

• それはプログラマーを正直に保ちます-あなたがそれがレビューされることを知っているなら、人々はより少ないショートカットを取ります
• 新しいプログラマーが経験豊富なプログラマーから学ぶのに役立ちます
• ドメイン固有の知識を伝達するのに役立ちます
• レビューは、バグや潜在的な問題を見つけて修正できる別のゲートです

すべてのプログラマーにソース管理の使用を許可しないことにより、変更を追跡したり、ミスを取り消したり、変更の合理的な履歴を確認したりできなくなります。「最高の」プログラマだけがgitにチェックインできるようにしたいと思うかどうかはわかりません。

そうは言っても、リリースブランチなど、特定の重要なブランチを担当している人がいるのは合理的だと思います。この場合、誰でもgitリポジトリを使用できるが、特定の人だけがリリースブランチにマージできると想像します。gitでこれを強制する方法があるかどうかはわかりませんが、プロセスごとに実行でき、他のユーザーがチェックインしていないことを確認するだけです。

リリースブランチへのマージは、「最高の」プログラマーによって行われる可能性がありますが、十分なレビューが行われた後、有能な人々によって行われる可能性が高くなります。

仕事の大部分が他の人のコードをレビューすることである場合、優秀なプログラマーは辞めますか？

彼らが仕事を楽しんでおらず、この活動を行うことを余儀なくされている場合、はい。起こりそうです。優れた開発者にとって次の興味深い仕事を見つけることは、今日では大きな課題ではありません。

あなたの最高のプログラマーは、他の全員のコードをソース管理にチェックインする必要がありますか？

絶対にNO。それはにする必要がありますいくつかの重要なロジックを除いて、自分の時間の確か廃棄物である岩の固体。

ただし、若手または経験の浅い開発者は、少なくとも安全のために、少なくとも自分自身をコミットする特権を得る前の数週間は、チームの開発ガイドラインに従うように、コード品質の保護期間にすべきです。