同僚は、ソース管理システムからのコードをお互いに確認する必要がありますか？

これが私の話です。私の同僚の1人がすべてのコードをレビューするために使用し、リビジョンシステムにホストされています。私は彼が所属するパーツの変更の適切なレビューについて話しているのではありません。彼はコードファイルをファイルごとに、行ごとに監視します。すべての新しいファイルとすべての変更。私はスパイされているように感じます！

私の推測では、コードがすでに制御システムにホストされている場合は、少なくとも実行可能として信頼する必要があります。私の質問は、多分私は偏執狂的過ぎて、お互いのコードをレビューする練習は良いですか？

PS：私たちはたった3人の開発者からなるチームであり、私たちがもっと増えれば、同僚が私たちが書くすべてのコードをレビューする時間がないことを恐れています。

私は「はい」と言います！

そのための2つの簡単な理由：

1）コードが本番環境にある場合、それが正しいとは限りません。システムの他の場所に変更を加えると、バグが発生する可能性があります。コードを定期的にチェックすることが非常に重要だと思います。このようにして、リファクタリングは定期的に行われ、コードはきちんと「より」正確に保たれます（最新のものはおそらくより良いです）。

2）あなたがプログラマーになるつもりなら、コードを読めることは非常に重要なスキルです。そしてそれはスキルであり、あなたが取り組む必要があるものです。既存のコードベースで作業を開始するプログラマーにとって、他の人のコードを読むことに慣れていない場合、何が起こっているのかを最新にしようとする学習曲線が急になります。

私はあなたがスパイされていると感じるべきではないと思います。誰かがあなたに与えた批判を受け入れます（もちろんそれが有効な場合）。そして、他の人々に有効な批評を自由に与えてください。それは私たちが学ぶ方法です。学習をやめる（またはやめたい）と、大きな問題が生じます。

同僚が良い建設的なフィードバックを提供している場合、これは素晴らしいことであり、非常に感謝するべきです。

これはWILLあなたがそれを書くときに考えていなかったバグをキャッチ。これはWILLあなたは他の人がそれを見るだろうことを知っているので、あなたがより良いコードを書くことになります。

チーム全体が1人ではなくコードレビューを行うと、健全です。理想的には、誰もが完了後にコードをレビューするよう誰かを招待するでしょう。それを非公式に保ち（マネージャーを遠ざける）、レビュアーに彼/彼女の調査結果について話してもらうと役立ちます。理想的には、レビュー担当者はフィードバックのみを提供し、コードの変更は行わないでください。もちろん、少し組み合わせることができます。

ホワイトスペースとコードスタイルに関するレビューディスカッションを絶えず回避するために、コーディング標準を設けることは本当に役立ちます。ビルドマシンで静的コード分析を行うと、議論を進めるうえでも役立ちます。

時間の側面については、理論はそれがあなたの時間を節約するということです。後者の障害は、コストが高くなるほど発見され、原則が失敗します。ピアコードレビューはかなりの問題を捉えることができます。

あなたの同僚は勤勉な開発者のように聞こえます。彼の例に従うべきです。

私はバージョン管理システムも同じように見ています。私たちのコードベースは大きすぎてすべての行を見ることができませんが、ほとんどの変更について高レベルの感触を得ようとしています。また、副作用の可能性が最も高いチェックインを監視し、行ごとに確認します。私がこれを行うために費やす最小の時間に対して、見返りは莫大です。（また、この習慣を持つチームの開発者は私だけではありません。）

この種のレビューは、毎週バグをキャッチしたり、ディスカッションを呼び出したりする傾向があります。QAを行うときに時間を節約できます。ディスカッションは、ベストプラクティスからアルゴリズム設計などにまで及びます。この前線の鍵は、誰もがそれを建設的であると見なしていることです。

個人的には、私が定期的に触れないコードベースの他の部分で何が起こっているかについての理解を深めます。他の人が助けを必要とするとき、私はより速く飛び込むことができます。また、新しいアイデアが出てきたら、すぐに活用できます。

スパイされているように感じますか（！）？しかし、あなたの同僚の観点から、彼は彼のキャリア開発のために正しいことをしていると私は言うでしょう。他の人のコードを読んで、彼らがどのようにロジックを設計して実装するかを見つけてください、これはあなたに大きな利益をもたらします！

私見誰かがあなたのコードで何か間違ったことを指摘した場合、あなたはそれを受け入れ、彼らから良いコードを書く方法について学ぶ必要があります

6〜7か月間、私は同じことをしていました。スパイではなく、品質を管理するためです。中央リポジトリにコミットされた、アクティブに開発されたアプリケーションのコードの1行ごとに、2つの主要言語、いくつかの別の言語、4つのプラットフォーム用の巨大なメイクファイル。

とても悪い習慣です。いつの日か、堅牢性のためにすべてをキャプチャできないことがわかりました。これに対する別の議論は主観です-誰もが間違っているかもしれません。

開発者がお互いのコードをレビューし、最終的な決定を行い、方向を定義する経験豊富な誰かがいる場合は、より良いです。

チーム内でのコードレビュー（魚眼レンズ、るつぼ、またはその他のツールを使用）は、非常に重要で有用です。唯一良いのは、直接システムに入るコードがよく考えられ、複数の人の頭脳を通過したことを確認する直接ペアプログラミングです。

これは私のチームで一度起こりました。残念ながらそれは非難のゲームに終わりました。人々は他の人がコードをチェックインするのを絶えず待っていて、常にコードのどこかで問題を見つけようとし、常に非難ゲームをしていました。

より成熟したオーディエンスをお迎えいただければ幸いです。

これは業界では非常に標準的な方法です。私が働いた会社は非常に厳しいコードレビューガイドラインを持っています。コードをレビューしない限り、コミットを許可することさえできません。

怒ったり、見守られたりしないでください。それをセーフティネットと学習経験として考えてください。

以前の仕事では、上級開発者がすべてのチェックインを見てレビューしました。私は頻繁に優れたフィードバックを得て、より良い開発者になりました。

現在の仕事では、多くのチェックインを見ており、3日前にバグを発見して開発者に通知しました。

この方法を採用すれば、バグをキャッチし、チーム全体を改善することができます。