ジュニア開発者にはコードレビューが必要ですか？

私は2つの会社で働いていましたが、コードレビューに関してはそれぞれが異なる方法論を持っていました。

最初の企業では、チームリーダーがコードレビューを実施し、すべてのモジュールの完了後に必要になりました。

ただし、2番目の会社では、チームリーダーはコードレビューを行う必要がなく、機能と設計の問題をチェックしました。

だから私は混乱しています。コードレビュープロセスは本当に必要ですか？もしそうなら、なぜですか？そうでない場合は、なぜですか？

個人的には、すべてのコードがコードレビューを通過する必要があると考えています。あなたがジュニアまたはシニアの開発者であるかどうかは関係ありません。

どうして？まず第一に、あなたの肩書きはあなたが開発する方法について何も述べておらず、上級開発者は後輩から何かを学ぶことができます。私たちの会社では、チームの他のメンバーの1人がコードをレビューするようにシフトしています。ほとんどの場合、「ジュニア」とシニアが一緒にチームを組んでいるため、日常的に言われないことはすべてフォローアップに巻き込まれた。シニアがジュニアコードが気に入らない場合は、ジュニアがやった理由に耳を傾け、それを見て、それが将来使用される可能性のある実行可能なソリューションかどうかを確認する必要があります...あなたは誰ですか。

コードレビューに関する重要なことの1つは、あまり良いことではありません。もしあなたがナイスガイであるなら、システム内でますます厄介なコードを進化させることができます。昨日と同じように、前職の若手開発者が書いた完全なアプリケーションと、彼が去る前にコードをレビューする必要があるかもしれないことを改めて作り始めました。

レビューを行うだけのチームリーダーである必要がある理由はわかりませんが、開発が不十分なコードを「戦う」ことを恐れない人が必要であり、コードのあり方を気にする人でなければなりませんあります。すべての企業が実際に自分の仕事に関心のある人を雇うわけではありません。悪い卵は、肩をすくめて悪いコードに「OK」と言うだけなので、コードレビューを行うことはできません。

基本的に、経験に関係なくすべてのプログラマーにコードレビューが必要です。これはソフトウェア開発の品質管理であり、オープンソースが非常に高品質である理由の1つです。

編集：その理由は、今日のコードレビューアが、後でメンテナーとまったく同じ役割を果たしているからです。もしコードが今日彼にとって意味をなさないなら、後でそれも意味をなさず、バグを修正するのにより高価になります。したがって、開発者がコードを覚えている間に、今日理解できるようにしてください。また、レビュー担当者は、開発者が見逃したバグや欠落を確認する場合があります。

残念ながら、それをしたい人はほとんどいませんが、ビジネスの観点から見ると、それは必須です。

現在、コードレビューが必須であるが、3年前ほどではなかった場所で働いています。これにより、コードが大幅に改善され、他の人が後でコードを維持できるようになりました。上級の経験豊富な開発者であっても、QAが発見する前に、または顧客が発見する前に悪化する前に、コードレビューで簡単かつ静かに修正できるミスを犯します。さらに、元の開発者以外の少なくとも1人がコードに精通しています。

多くの場合、組織がコードレビューで行ったように、何か新しいことを試みると、変更に対する抵抗が大きくなります。コードレビューでは、そのどれもほとんど見ませんでした（正式なQA部門を取得するのを楽しみにしていました）。値を確認するには、1〜2件のレビューだけで済みます。

他の人の作業のコードレビューを行ったり、コードをレビューしたりすることの両方で考慮していなかった新しい手法を見つけました。コードレビューを行うことで、さらに重要なことに、コードレビューへの応答方法により、新規採用者の能力の問題を比較的迅速に発見しました。メンテナンスが明確ではないセクションのプログラミングの厚さの中で、今完全に明確に見えるものは何かを学びました。これは非常に貴重です。必要なのは、何かが行われた理由に関するコメントだけである可能性があります。レポートが実際に正しい情報を持つように修正する必要があるデータベース設計に関するいくつかの基本的な誤解を発見しました。

多くの場合、コードレビューで私が見たのは、他の人に何かを説明するという行為によって、開発者は頭の中で電球をオンにし、レビュー担当者が見なかったバグがあることを認識するということです。

そして、少年はコードレビューを行い、標準に従わない、または義務付けられたツールを使用せず、他の誰によってもコードが維持できなくなるカウボーイプログラマを特定できます。そして、それは彼らにプログラムを手に入れるか、外に出させることもできます。

コードレビューに最も抵抗力があるのは、多くの場合、コードがコードレビューに合格できないことを心から知っているため、組織が最も取り除く必要がある人々です。

アジャイルの人は言う：「あなたはコードレビューを必要とせず、ペアプログラミングをして、良いテストを書くだけだ」:)

コードレビューは、チームを通じて知識と優れた実践を広める良い方法です。私の経験では、すべてのコードがレビューされることを確認し、誰がどのコードをレビューするかを変えることをお勧めします。

私の現在のチームでは、全員のコードが同等にレビューされており、プログラマーとレビュアーの両方がコードをリリースする前に満足する必要があります。これは、より多くのジュニア開発者、他のレビューを行っているジュニア開発者、または互いにレビューしている他のシニア開発者によってレビューされているシニア開発者にも当てはまります。レビュー担当者が経験の浅い、または特定のコードをレビューすることに不安を感じている場合は、グループとしてレビューを行うために別の開発者（および元の開発者）とチームを組みます。

私は20年以上ビジネスに携わっており、ソフトウェア会社やさまざまなビジネスで働いていますが、これらの場所にはコードレビュープロセスがありませんでした。ただし、持っていることの利点を理解し、感謝することができます。基本的に、私がそれらを理解しているように、それらは標準を順守するために使用されるべきであり、他の人が将来より簡単にコードを維持できるようにするために従うべきです。コードの可読性もレビュープロセスでチェックされる場合があります。これにより、メンテナンスがコードで効果的に機能することが保証されます。

現在、私は独身の開発者である小さな店で働いています。時折、受注残を支援するために請負業者を連れてきました。それらの請負業者の少なくとも1人または2人は、必ずしも私のものや企業の基準を満たしていないコードを書いていますが、うまく機能し、少なくともある程度理解できました。この問題を経営者に指摘したとき、彼らは気にしませんでした。彼らは私たちが彼らに支払ったことをしたかどうかを知りたいだけでした。ですから、それは会社次第で、きれいで保守しやすいコードが望ましい製品なのか、それともお金のためにうまく機能するものが欲しいだけなのかによって決まると思います。

明らかに開発者として、そしてコードを維持しなければならない人として、ある種の標準に従うクリーンなコードで作業したいと思いますが、私はいつもその贅沢を持っているわけではないので、私はそれを最大限に活用し、私が持っているものに対処します、それは時々自分の標準でいくつかのコードを書き直す必要があることを意味します。

コードレビューは、問題の修正が簡単（かつ安価）な場合に、ソフトウェアライフサイクルの早い段階で欠陥を特定できます。SmartBearでは、ピアコードレビューツールを開発し、コードレビューを効果的にする方法について多くの調査も行っています。お客様からのデータに基づいて、コードレビューで見つかった欠陥は、QAで見つかった欠陥よりも8〜12倍安価に検索して修正できます。コスト削減だけでも、コードレビューは価値がありますが、それ以上の価値があります。コードレビューは、チームの全員がソフトウェア開発者として学び、改善するための優れた方法です。

コードレビューの効果が低下する可能性のあるトラップがいくつかあり、組織がそれらの1つに巻き込まれているようです。人々ではなく、コードについてコードをレビューします。コードレビューではタイトルは何も意味しません。権威へのアピール（私はチームリーダーであるため、自分のやり方で行う必要があります）は、善よりも害をもたらします。代わりに教えてください。上級エンジニアは、それを要求するだけでなく、なぜ自分のやり方で行うべきかを説明する必要があります。コンセプトを説明するのに苦労しているなら、それはあなたにとっても学習経験です。二人ともあなたが費やした努力により良い開発者になるでしょう。

すべてのコードをレビューするコードはやり過ぎだと思います。すべてのコードをレビューするのにかかる時間は、他の場所で費やすほうがよいでしょう。Alterntivley重要なコードや、特に複雑な部分にはコードレビューが必要ですが、すべてのコード行が必要というわけではないと思います。

私の意見では、会社で使用されるコードは、ジュニアまたはシニア開発者のどちらによって作成されたものであっても、常にレビューする必要があります。どうして？コードにいくつかのバグがあった場合はどうでしょうか？そして、このコードが使用されている間にプログラムがクラッシュした場合はどうなりますか？これらのことを防ぐには、使用する前にすべてのコードを確認する必要があります。

しかし、コードをレビューしない企業はどうでしょうか？彼らはおそらく、多くの技術的な問題と、消費者に「クラッシュ」と言うように、多くの問題を抱えている企業でしょう;-)。

それで、あなたの質問のすべてに答えさせてください：

• はい、レビュープロセスが必要です。
• どうして？上記の理由から。

コードレビュー：コードレビュープロセスはすべての人にとって不可欠なものである必要があります。コードレビューの実施によって誰が利益を得ているのか、また彼らが得ている利益は何かを説明します。

1. コードレビューの実施により会社が得られる利点：コードレビューを頻繁に行うと、会社はより良い最適化された方法で最終製品を入手でき、市場でブランド名を獲得し、会社が現在のCMMIレベルを取得または改善します。

2.コードレビューの実施によるチームリーダーへの利点： 教師は間違いを簡単に特定できます。なぜなら生徒は生徒の回答をより頻繁にレビューしているためです。間違ったことのために可能です。同様に、チームリーダーも、この分野で何がうまくいかないかを知っています。どうすればそれらを修正できますか？また、チームリーダーがジュニア開発者からもニュースのアイデアをつかむのを助けてください。

3.コードレビューの実施によるジュニア開発者への利点： ジュニア開発者はコードレビュープロセスに関するアイデアを簡単につかむことができ、また、コーディング標準とは何かを取得することができます。たとえば、適切な方法でAPIを作成し、彼らはコーディングの標準化を学び、将来的に彼らがより高いレベルのポストになったときに彼らを助けるかもしれません。

私の結論は、コードレビューはすべての人にとって非常に非常に重要なプロセスです（チームメンバーにとっても）、コードレビューはコードの不注意な誤りを修正するのに役立つからです。なぜなら、私たちはすべて人間であり、コードで不注意なミスをします。

コードをチェックインする前に（レビュー）、またはバグのためにアイデアに干渉したり、あまりにも賢く/理解しづらくなったり、受け入れられている標準的な慣行に従わなかったりすることとの違いは何ですか？それはあなたの自我ですか？

あなたが尊敬していない資格の低いチームメンバーによって実装が不十分であるという理由だけで、コードレビューやその他のメリットを軽視することはできません。コードレビューは、ごく少数のスーパープログラマが把握できるほど複雑なプロセスではありません。自己編集ができる、または時間を割くことができるプログラマーやプロのライターが多いかどうかはわかりません。

数か月後にコード行に戻り、私が何を考えていたのか疑問に思ったことはありませんか？コードレビューでそれをキャッチする可能性が高くなります。あなたはそれを捕まえたばかりで、あなたは少し前にいたプログラマーよりほんの少しだけ良くなっているだけです。

IMOコードレビューは、すべての開発者にとって不可欠ですが、レビューを行う人が有能である場合に限ります。過去にレビューでコードが却下されたのは、あなたが子供を従わず、SOLIDいくつかの依存性注入を行い、コードを論理設計に従って名前空間とフォルダに整理し、ユニットテストの小さなスイートを含めたためですコードを確認してください。コードは「複雑すぎる」として拒否され、会社がコードを書いた方法ではなかったため、すべてをまとめてテストを削除する1つのクラスを使用するように言われました。

そのようなコードレビューは価値がありませんが、有能なチームとのコードレビューは多くの場合、設計について何かを明らかにするか（例：ZではなくXとYを行うべき理由）、または実際の欠陥を示すことができます（例：Xを実行するとYが失敗します）間違った理由で）。

もちろんコードレビューは必要ありません。また、テスト、継続的インテグレーション、ソース管理、顧客関与、プロファイリング、静的分析、まともなハードウェア、ワンクリックビルド、バグトラッキングもリストに載っています。

コードレビューに加えて、上記で言及したことは、ソフトウェアの品質を確保するのに役立つツールです。スキル、運、時間、決意の組み合わせ。このようなものがなくても高品質のソフトウェアを提供できますが、提供しない可能性が高くなります。

あなたのシナリオでは、混乱するものは何もありません。すべての組織がすべてのベストプラクティスに満足しているわけではありません。彼らはそれに反対するかもしれませんし、実装する別のベストプラクティスと衝突するかもしれませんし、この時点で実装するオーバーヘッドが彼らにとって大きすぎると考えるかもしれません。彼らの状況に応じて、彼らはそうすることで正しいかもしれません、または彼らは誤った経済を作っているかもしれません。一部のツール（ソース管理など）では、投資回収/労力の比率が非常に優れているため、簡単に使用できます。他の人にとってはあまり明確ではありません。

コードのレビューは、かなりのオーバーヘッドをもたらすプラクティスであることは間違いありません。このため、組織は、オーバーヘッドを最小限に抑えるように努めます。まったく行わないか、特定の状況（たとえば、ジュニアチームメンバー、または特に毛深い変化）でのみ行います。コストよりも（バグをキャッチし、技術的負債を減らし、知識を共有することで）返済することは必ずしも明白ではありません。その見返りの大部分は定量化が困難ですが、組織がレビューに費やす工数を数えるのは非常に簡単です。定量化するのが最も簡単な（バグの数を減らす）ことは、他の要因に起因するのは簡単です（たとえば、「もちろんバグが少なく、成熟している」）。

私たちはトルコでオンラインのサッカーゲームを作っています。多くのユーザーとゲームマスターが機能性を助けてくれます。また、必要な機能に関するコメントを提供します。そのため、ユーザーが多い場合は、バッジを支援または取得するための機能テストを実行できます。開発者、ゲームマスター、ユーザーとフォーラム、サポートチーム、およびプライベートテスト環境の連携により、ソーシャルプロジェクトが作成されます。

確かにコードレビューと開発チーム間での経験の共有が必要ですが、それが重要でない場合、あなたはあなた自身を強制する必要はありません。

サードパーティの検査がどの程度冗長であるかは、ライフサイクル、より機敏であるか、プロセスのウォーターフォールに依存していると思います。高レベルの設計/検査、およびより詳細なレベルの設計検査を行うことは合理的だと思います。チームの複数のメンバーが検査に参加することも良いと思います。

彼らはほとんど経験がないので絶対に必要です。