その練習から来たときに、新しい場所でコードレビューなしに対処する方法は？

私の新しい会社のチームにはコードレビュープロセスがありません。

私はコードレビューが必須の文化である企業から来ているので、誰かにレビューしてもらうことなくコードをコミットすることに不安を感じています。

私は、コードレビューは潜在的な問題を早期に発見するため、コードレビューは品質を改善し時間を節約する方法であると固く信じています（ペアプログラミングについては話していないことに注意してください）。

• コードレビューが時間の無駄ではなく時間の節約になることをどのように示すことができますか？
• 単体テストがある場合、コードレビューをスキップできますか？

単体テストがある場合、コードレビューをスキップできますか？

しかし、なぜ？

査読の主な役割は、バグを発見することではありません。

はい、あなたは、いくつかの潜在的なバグや疑わしい、バグが発生しやすいコードを識別することができる、これはしばしば起こるが、時折、いくつかの失策をスポッティングすることはピアレビューは、信頼性の高い方法であることを意味するものではありません除外バグの存在を。それからはほど遠い。実装の機能の正確性を検証するのに適切なツールではありません。

ただし、コードレビューはコードの保守性を強化します。コードが実稼働に入る前に、コードが（作成者だけでなく）クリーンで理解可能であることを求めます。

単体テストの存在は、それに完全に直交しています。100％のコードカバレッジと、完全に理解できないコードのすべてのテストに合格することができます。

コードレビューは、他の開発者があなたの仕事に慣れることで、何が何であるかを把握し、休暇中などにバグレポートを処理できるようにもなります。コードベースの一貫性を保つ（アプリ全体で同様のパターンと規則を守る）か、コードの重複を避けます。

より広範なスキームでは、開発者として他の人のコードを読むことから学び、成長します。

単体テストは、そのいずれの代替にもなり得ません。はい、それらがよく書かれていれば、ドキュメントのように読むので、私たちはこのために努力する必要があります。しかし、これはピアレビューの実行と相互に排他的ではありません、まったく逆です-ピアレビューのすべての利点はまだ当てはまります。冗長ではなく。

コードレビューが時間の無駄ではなく時間の節約になることを示す研究や統計はありますか？

知りません。あなたが持っているのタスク2つのチーム必要があると思いますので、このような研究を行うことも難しい等しいと現実的な 1は、コードレビューを使用し、もう一方にはない達成するために複雑さを、。おそらく、彼らに同じ問題を解決してもらう必要があります。つまり、多くのお金を窓から投げ出しています。そして、統計的関連性を得るのに十分な頻度で実験を繰り返す必要があります。これにより、投じられるお金が桁違いに増えます。

コードレビューを使用していない企業に対してコードレビューを使用して企業の効率を測定するだけでは、効率の測定方法だけでなく、実際の原因も不明です。コードレビューは、より大きな文化の一部です。どの部分が実際にチームをより効率的にするかを判断するのは困難です（そして、チームまたはプロジェクトの性質に大きく依存する可能性があります）。または、この文化が存在するということは、単に会社が小規模または若く、それぞれが多くの効果を持っていることを意味する場合があります。または、コードレビューに提出する意欲があなたのエゴへの健全な距離を排除または助長するというだけかもしれません;）

しかし、忘れないでください：あなたは自分の経験を引き出します。それは彼らがあなたを雇った理由の一部です。そのため、効率を高めることができると本当に信じている場合（そして、実際にチームが不足している場合）、それを明確に伝えてください。

単体テストがある場合、コードレビューをスキップできますか？

いや。テストの重要性を信じるなら、実際にあなたのテストが最初にレビューされるべきです。ナンセンスだとしたらどうでしょう？または、カバレッジがお粗末な場合は？または、動作ではなく実装をテストする場合は？

私が見つけたいくつかのランダムなスライドから取られましたが、ハードデータはSteve McConnellのCode Complete本から来ています。

コードレビューは有用ですか？

「ピアコードレビューは、コードを改善するためにできる最大のことだと思います」

Coding HorrorのJeff Atwood（ http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html）

---

「通常、個々の検査で約60％の欠陥を検出します。これは、プロトタイピングと大量ベータテストを除く他の手法よりも高いです。」

Steve McConnell、Code Complete 2nd Edition、485ページ

その60％の数字はShullら2002年までにIEEE紙から来ている私たちは、欠陥の戦いについて学んだというセクションが含まれています。

「ピアレビューは60％の欠陥をキャッチします」

免責事項：この答えは私の個人的な経験です:)

私たちが管理しているコードのコードレビューで非常に悪い経験をしました。通常、ライナーは1つ程度しかなく、レビューすることはあまりないためです。

しかし、実際のプロジェクトでは良い経験をしました。試験時間にトレーナーが定期的にコードをレビューし、頻繁に犯すミスを見つけるのに大いに役立ちました。

ですから、あなたが何をしているのか、あなたが何人いるのかなどに大きく依存していると思います

また、コードレビューが戦争で終わるリスクは過小評価されません。

おそらくトレーニングの一環として、コードレビューが正常に行われていなくても、チームリーダーや同僚にコードのピアレビューを依頼することができます。

レビューの前に、コードが適切に作成され、テストされていることを確認してください。

私がチームリーダーであったとき、私は新しい従業員のコードレビューを自分で行っていましたが、（しばらくして）バグやその他のコードで批判する何かを見つけるのをやめ、そのポイントでコードレビューをやめます。それは次の場合に起こります：

• 彼らは彼らがインターフェースするシステムを学び、それについての私の説明を必要としませんでした
• 私が見た前にバグがなくなるまで、彼らはコードを設計および/またはテストすることを学びました
• 彼らは私のコーディングスタイルガイドラインについて十分に学んだので、コードを保守可能と考えます

コードレビューにはいくつかの目的があります。

• コードの欠陥を見つける
• チームメンバー間の知識の伝達

チームが経験豊富なチームメンバーの間でコードレビューをスキップすることを選択した場合でも、新しい従業員のコードレビューを行うことは問題ないと思います。

開発されたソフトウェアでコードレビューを行うための経験則はありません...それはすべて、アプリケーションの範囲、クライアントのサイズ、会社のサイズに依存します。たとえば、今後バージョンが実装されない可能性のある単純なアプリケーションを将来構築するアプリケーションを構築する場合、単体テストで十分です。ただし、アプリケーションのパフォーマンスについて話すと、コードのレビューが行われます。コードのレビューは、パフォーマンスの向上を促進するためのより良い方法で行われた可能性のある短いコードのレビューを行う必要があります。

通常、コードレビューは、2人以上の開発者のチームと、技術リーダーがアプリケーションの品質を保証し、将来の機能強化に合わせてアプリケーションをスケーリングし、異なるバージョンにアップグレードするためにコード標準に従うことを望む技術リーダーがいる場所で行われます今後のバージョン。

たとえば、現在多くのCMSオープンソースプラットフォームがあり、これらのプラットフォームはプラットフォーム機能を強化するために時々アップグレードをリリースし、これらのプラットフォームのいずれかを使用し、コアファイルのハードコーディング、アプリケーションの作成などのコード標準に従っていない開発者を想像してくださいテンプレートファイル内のコード、およびこのコードが実稼働環境に移行し、その後クライアントがプラットフォームを新しいバージョンにアップグレードする必要がある場合、そのプラットフォームのコード標準に従ってコーディングをやり直さない限りアップグレードされません。ここでは、コードのレビューを行わずにコードを本番環境にリリースするための深刻な問題になります。

したがって、リリース前にコードレビューを行うことは、プロのソフトウェア企業にとって必須であり、例外は、開発者が非常に熟練したプログラマーであり、彼と経験を積んでいる個人/非常に小規模なアプリケーションにのみ当てはまります。

コードレビューには、レビュープロセス自体に起因するものではない利点があります。高品質でありながら短時間で作成されるコードを取得するには、常にジレンマがあります。コードのレビューがなければ、あなたは独力で作業するため、短時間でコードを実行するための品質が犠牲になる可能性があります。コードレビューでは、低品質のコードを手放せないレビュアーがいます。これはまさにあなたが望んでいることであり、そもそもあなたが望んでいる高品質のコードを取得するために時間を費やさなければなりません。より良いコードの作成に費やされる時間はデバッグに2時間（またはそれ以上）節約されるため、時間の節約になります。

コードレビューがなければ、あなたは自分でいるので、高いコード品質を維持するのはあなた次第です。簡単な解決策は、自分で行ったすべての変更を確認し、品質基準に達していないものを修正することです。

これにより、コードレビューがエゴの衝突につながるという恐ろしい状況も回避されます-プログラマーAがメソッドXを使用し、BがメソッドYを使用するため、AがメソッドXを使用するコードを記述する場合、レビュアーBはメソッドYを主張しますAはメソッドYを使用してコードを書き換えますが、Bがコードを作成し、Aがそれをレビューした場合、まったく逆のことが起こります。

あなたがコードレビューの支持者であるなら、私は本当の代用品がないと思う。不幸でステレオタイプなケースは、（A）彼らが実践に詳しくない、および/または（B）コードレビューを得るために時間と労力を費やしたくないため、コードレビューを行わない職場です所定のシステム。

基本的に、ここで欲しいものを手に入れるには、職場の文化を変える必要があります-それは決して簡単でも簡単でもありません。職場でコードレビューが優れており、採用することを100％説得されたとしても、実際に新しい作業方法に移行するには、時間、エネルギー、生産性の多大な投資が必要になることを忘れないでください。この投資はそれ自体を返済する必要があります-しかし、あなたは投資のためだけでなく、投資のために賛同を得る必要があります。Roy Osheroveのビデオ「Unit Testing and TDD-How To Make It Happen」を参照してください -コードレビューの採用の課題は、単体テストの採用の課題と非常によく似ています。

それまでの間は、できる限りのことをしてください。

• コードレビューの価値を理解している他の開発者がいる場合は、非公式にでも相互にレビューしてみてください。
• トレーニングを担当するメンターまたは開発者がいる場合は、コードレビューに表示される価値について説明し、少なくともコードをレビューする意思があるかどうかを尋ねます。
• システムをよりよく理解するのに役立つので、他の人のコードをレビューしたいとマネージャーに伝えてください。
• ある時点でチームリーダーになった場合、チームだけのためにローカルでコードレビューを宣言できます。

これらのいずれかの大きな利点は、長期間にわたってそれらを維持できる場合、周囲の開発者がコードレビューに気付くようになることです。コードレビューを既存のカルチャに統合する方法を効果的にデモンストレーションします。これにより、カルチャが変化し始めます。コードレビューが役立つので、小規模でそれを実証できれば、他の人、そして文化全体があなたの例に従う道を開くでしょう。

心配する必要はありません-新しい雇用主はコードレビューを気にしません。自分が書いたコードをチェックインしてもよいと他人に言われることなく、自分の能力にある程度自信を持つことを学びます。他の人のコードをレビューするという面倒な退屈なプロセスなしで生活することをすぐに学ぶでしょう。

他のすべての人が使用するスタイルガイドライン（または単にスタイル）に従ってください。経験に基づいて、コメントが必要なもの、使用する命名規則などを決定します。

次に、チェックインする前にすべてをテストします。最も重要なことは、正しく機能することです。

新しい雇用主がコードレビューのアイデアを好まない場合は、旧式のコマンドおよび制御型の方法論と否定的な関連性があり、より近代的で機敏な型のプラクティスセットを目指しているためである可能性があります。この場合、彼らはペアプログラミングの考え方にもっと開かれている可能性があり、それは同じ利点の多くを提供し、より動的で現代的な慣行として広くみなされています。