ジュニア開発者はコードレビューが必要ですか？
私は2つの会社で働いていましたが、コードレビューに関してはそれぞれ方法論が異なりました。
最初の会社では、コードレビューがチームリーダーによって行われ、すべてのモジュールの完了後に必要でした。
ただし、2番目の会社では、チームリーダーはコードレビューを実施する必要がなく、機能と設計の問題をチェックするだけでした。
だから私は混乱しています。コードレビュープロセスは本当に必要ですか？もしそうなら、なぜですか？そうでない場合は、なぜですか？
コードレビュー：コードレビュープロセスはすべてバイタルである必要があります。コードレビューの実施により誰がメリットを得られるのか、またどのようなメリットがあるのかを説明します彼らは得ています。
1。コードレビューの実施により会社が得られるメリット：コードレビューが頻繁に行われる場合、会社はブランド名を取得するのに役立つはるかに最適化された方法で最終製品を入手できます。彼らの市場はまた、会社が現在の[〜＃〜] cmmi [〜＃〜]レベルを取得または改善するのに役立ちます。
2。コードレビューの実施によるチームリーダーのメリット：生徒は生徒の回答をより頻繁に確認しているため、教師は間違いを簡単に特定できます。アイデア、間違ったことが起こり得る領域。同様に、チームリーダーは、この領域で問題が発生している状況を把握しています。どうすればそれらを修正できますか？また、チームリーダーがジュニアデベロッパーからのニュースのアイデアを入手するのも支援します。
3。コードレビューの実施によるジュニア開発者へのメリット：ジュニア開発者はコードレビュープロセスに関するアイデアを簡単につかむことができます。また、コーディング標準とは何かを取得することもできます。たとえば：適切な方法でAPIを作成すると、彼らはコーディングの標準化を学び、将来、特に高レベルのポストになったときに彼らを助けることができます。
私の結論は、コードレビューはすべての人にとって非常に重要なプロセスです（チームメンバーにとっても）。コードレビューは私たちのコードの不注意な間違いを修正するのに役立ちます。コードで不注意なミスをする。
私は個人的に、すべてのコードがコードレビューを受ける必要があると思います。あなたがジュニアまたはシニアの開発者であるかどうかは関係ありません。
どうして？手始めに、あなたのタイトルはあなたがどのように開発するかについて何も述べておらず、上級開発者はジュニアから何かを学ぶことができました。私たちの会社では、チームの他のメンバーの1人があなたのコードをレビューするようにシフトします...ほとんどの場合、私たちは「ジュニア」とシニアを一緒にチーム化しているので、日常的に言われないすべてのものはフォローアップに巻き込まれました。シニアがジュニアコードが気に入らない場合、ジュニアが彼がしたようにジュニアがなぜそうしたのかを聞いて、それを見て、それが将来使用される可能性のある実行可能なソリューションであるかどうかを確認する必要があります...あなたは誰ですか。
コードレビューについての重要なことの1つは、あまりにもナイスではないということです。ナイスガイである場合、システムでますます厄介なコードを進化させることができます。昨日と同じように、私は以前雇用されていたジュニア開発者が書いた完全なアプリケーションの作り直しを始めました。そして、コードが彼が去る前にレビューが必要であったかもしれないという私の神。
チームリーダーがレビューのみを行うべき理由はわかりませんが、開発が不十分なコードに対する「戦い」を選択することに恐れを感じない人が必要であり、コードがどのようにすべきかを気にする人でなければなりません。あります。すべての企業が実際に何をすべきかを気にする人々を雇うわけではありません。それらの悪い卵は、肩をすくめて悪いコードに「OK」と言う可能性が高いため、IMOがコードレビューを行うことは許可されません。
基本的に、コードレビューは経験に関係なくすべてのプログラマーに必要です。これはソフトウェア開発の品質管理であり、オープンソースが非常に高品質である理由の1つです。
編集：その理由は、今日のコードレビューアは、後でメンテナとまったく同じ役割を担っているからです。コードが彼にとって今日意味をなさない場合、それも後で意味をなさなくなり、バグの修正にコストがかかります。したがって、開発者がコードを覚えている間に、今日それを理解可能にします。また、レビューアは、開発者が見逃したバグや脱落を目にすることがあります。
残念ながら、そのようなことを望んでいる人はほとんどいませんが、ビジネスの観点から見ると、それは必須です。
私はコードレビューが必要になった場所で働いていますが、3年前ほどではありませんでした。これにより、コードが大幅に改善され、他のユーザーが後でコードを保守できるようになりました。上級の経験豊富な開発者でさえ間違いを犯し、QAが発見する前にコードレビューで簡単かつ静かに修正できます。さらに、元の開発者以外の少なくとも1人がコードに精通しています。
多くの場合、コードレビューで行ったように、組織が何か新しいことを試みると、変更に対する抵抗が大きくなります。私はコードレビューでほとんどそれを見たことがありませんでした（正式なQA部門を取得するために私たちは熱心でした）。値を確認するのに1、2回のレビューしか必要ありません。
他の誰かの作業のコードレビューを行うとき、または私のコードをレビューさせるときに、私が考慮していなかった新しいテクニックを見つけました。コードレビューを行うことで、新入社員の能力の問題を比較的迅速に発見しました。さらに重要なのは、コードレビューへの対応の仕方です。私たちは、メンテナンスの段階で明確にならないであろうそのセクションのプログラミングの厚さの中で、現在完全に明確に見えるものを学びました。これは非常に貴重です。必要なのは、なぜ何かが行われたのかに関するコメントだけなのかもしれません。実際に正しい情報を得るためにレポートを修正する必要があるデータベース設計について、いくつかの根本的な誤解を発見しました。
多くの場合、コードレビューで見たのは、誰かに何かを説明するという行為そのものによって、開発者は頭の中で電球を点灯させ、レビュー担当者が見なかったバグがあることに気づくということです。
そして少年はコードレビューを行い、標準に従わなかったり、必須のツールを使用したり、他の誰も保守できないコードに近づくカウボーイプログラマーを特定できます。そして、それは彼らにプログラムを手に入れるか、あまりにも外に出るよう強制することができます。
多くの場合、コードレビューに最も抵抗する人々は、コードがコードレビューに合格できないことを心から知っているため、組織が最も取り除く必要がある人々です。
アジャイルな人は言うでしょう：「コードレビューは必要ありません。ペアプログラミングをして、良いテストを書いてください」:)
コードレビューは、チーム全体に知識と実践を広めるための良い方法です。私の経験では、すべてのコードがレビューされることを確認し、誰がどのコードをレビューするかを変えることをお勧めします。
私の現在のチームでは、全員のコードが等しくレビューされており、プログラマーとレビューアーの両方がコードをリリースする前に満足させる必要があります。これは、より多くのジュニア開発者によってレビューされているシニア開発者、別のレビューを行うジュニア開発者、またはお互いをレビューしている他のシニア開発者にも同様に当てはまります。レビュー担当者が経験の浅い場合、または特定のコードをレビューすることに抵抗がある場合は、別の開発者（および場合によっては元の開発者）と協力して、グループとしてレビューを行います。
私はビジネスに20年以上携わっており、ソフトウェア会社やさまざまな企業で働いています。これらの場所にはコードレビュープロセスがありませんでした。しかし、私はそれを持っていることの利点を理解して感謝することができます。基本的に、私はそれらを理解しているため、標準を確実に順守するために使用する必要があります。これは、他の人が将来のコードをより簡単に保守できるようにするために従う必要があります。コードの可読性もレビュープロセスでチェックされる可能性があります。これにより、メンテナンスによってコードを効果的に操作できるようになります。
現在、私は単一の開発者である小さな店で働いています。時折、私たちはバックログを手伝うために請負業者を連れてきました。それらの請負業者のうち少なくとも1人または2人が、必ずしも自分や会社の基準を満たしていないコードを記述しましたが、うまく機能し、少なくともある程度は理解できました。私がこの問題を経営陣に指摘したとき、彼らは気にしませんでした、彼らが私たちに彼らが支払ったことをしたかどうか知りたいだけでした。したがって、それは会社に依存し、クリーンで保守が容易なコードが望ましい製品であるかどうか、または彼らがお金のためにうまく機能する何かを望んでいるかどうかに関係ないと思います。
明らかに、開発者として、そしてコードを保守する必要がある人として、私はある基準に準拠したクリーンなコードで作業したいのですが、常にそのような贅沢はありません。 、たとえそれが時々私自身の標準でいくつかのコードを書き直さなければならないことを意味するとしても。
コードレビューでは、問題の修正が容易（かつ安価）な場合に、ソフトウェアライフサイクルの早い段階で欠陥を特定できます。 SmartBear で ピアコードレビューツール を開発し、コードレビューを効果的にする方法について多くの調査を行いました。お客様からのデータに基づくと、コードレビューで発見された欠陥は、QAで発見された欠陥よりも8〜12倍安価に発見および修正できます。コスト削減だけでも、コードレビューは価値がありますが、それだけではありません。コードレビューは、チームの全員がソフトウェア開発者として学び、改善するための優れた方法です。
コードレビューの効果が低下する可能性のあるいくつかのトラップがあり、組織がその1つに巻き込まれているようです。人ではなく、コードについてコードレビューを行います。タイトルは、コードレビューでは何も意味しません。権威に訴える（私はチームリーダーなので自分のやり方でやらなければならない）善よりも害を及ぼす。代わりに教える。上級エンジニアは、なぜそれが彼らのやり方で行われるべきかを説明する必要があります。コンセプトを説明するのに苦労している場合、それはあなたにとっても学習経験です。どちらもあなたが投入した努力に対してより優れた開発者になります。
ALL CODEをレビューするコードはやり過ぎだと思います。すべてのコードを確認するのにかかる時間は、他の場所で費やすほうがよいでしょう。 Alterntivley重要なコードや特に複雑な部分にはコードのレビューが必要だと思いますが、コードのすべての行が必要なわけではありません。
私の意見では、企業が使用するコードは、ジュニア開発者であれシニア開発者であれ、常にレビューする必要があります。どうして？コードにいくつかのバグがある場合はどうなりますか？そして、このコードが使用されている間にプログラムがクラッシュした場合はどうなりますか？これらのことを防ぐには、使用前にすべてのコードを確認する必要があります。
しかし、コードをレビューしない会社についてはどうでしょうか？彼らはおそらく、多くの技術的な問題を抱えている企業であり、消費者に言っているように、「クラッシュ」です;-)。
だから私はあなたの質問のすべてに答えましょう：
- はい、レビュープロセスが必要です。
- どうして？上記の理由により。
コードをチェックインする前（レビュー）に、または後でバグが原因でアイデアを妨げたり、理解しすぎたり理解しづらくなったり、受け入れられている標準的なプラクティスに従っていないことの違いは何ですか？それはあなたの自我ですか？
コードレビューやその他のメリットを軽視することはできません。それは、尊重しない資格のないチームメンバーがコードレビューを十分に実装していないからです。コードレビューは、ごく少数のスーパープログラマーが把握できるほど複雑なプロセスではありません。自分で編集することができる、または時間のあるプログラマーやプロのライターがたくさんいるとは思いません。
数か月後にコード行に戻って、私が何を考えていたのか疑問に思ったことはありませんか？コードレビューでそれをキャッチする可能性が高くなります。あなたはそれを捕まえただけで、あなたは少し前のプログラマーより少しだけ優れています-私は願っています。
IMOコードレビューは、すべての開発者にとって不可欠であるはずですbutレビューを行う人々が自分自身に有能である場合のみ。以前、私はレビューでコードが拒否されたことがあります。私はSOLIDをフォローし、依存性注入を行い、コードを論理設計に従って名前空間とフォルダーに編成し、コードを検証する単体テストの小さなスイート。コードは「複雑すぎる」として拒否され、会社がコードを記述した方法ではないため、すべてをまとめて1つのクラスを使用し、テストを削除するように言われました。
そのようなコードレビューは価値がありませんが、有能なチームによるコードレビューは、設計について何かを明らかにしたり（たとえば、XとYを行う必要があるがZを行わない理由）、実際の欠陥を示すことができます（たとえば、Xを実行するとYが失敗する原因になります）不正な理由による）。
もちろん、Code Reviewは必要ではありません。さらに、テスト、継続的インテグレーション、ソース管理、顧客の関与、プロファイリング、静的分析、まともなハードウェア、ワンクリックビルド、バグ追跡など、いずれもリストには含まれていません。
上記のコードレビューに加えて、ソフトウェアの品質を保証するのに役立つツールについても触れています。スキル、運、時間、決意の組み合わせで。あなたできますこのようなものを一切使わずに高品質のソフトウェアを提供しますが、あなたはできないである可能性が高くなります。
あなたのシナリオでは、混乱することは何もありません。すべての組織がすべてのベストプラクティスを取り入れているわけではありません。彼らはそれに同意しないかもしれませんし、実装する別のベストプラクティスと競合するかもしれません。または、現時点でそれを実装するオーバーヘッドが大きすぎると考えるかもしれません。彼らの状況に応じて、彼らはそうすることで正しいかもしれませんし、彼らは偽の経済を作っているかもしれません。一部のツール（ソースコントロールなど）では、投資回収/努力の比率が非常に優れているため、それを使用するのは簡単です。他の人にとってはあまり明確ではありません。
コードレビューがかなりのオーバーヘッドをもたらす慣行であることは間違いありません。このため、組織は、オーバーヘッドを最小限に抑えるように、まったく行わないか、特定の状況でのみ（たとえば、ジュニアチームメンバーの場合や、特に変更が多い場合）行います。それがコストよりも（バグの発見、技術的負債の削減、または知識の共有において）より多くを返すことは常に明白ではありません。その回収の大部分は数量化が困難ですが、組織がレビューに費やす工数を数えるのは非常に簡単です。数量化するのに最も簡単なビット（バグカウントの削減）は、他の要因に帰することが簡単です（たとえば、「もちろん、バグが少なく、成熟しています」）。