コードレビューは誰が行うべきですか?


12

私の会社では、主にアーキテクトがコードレビューを行っています。彼は非常に経験豊富で賢いソフトウェアの男なので、非常に得意です。開発者がコードレビューを行うとき、彼らは半分も行いません。開発者にさらにコードレビューを行わせるようにしましたが、コードレビューの品質は良くありませんでした。開発方法としてScrumを使用します。

ただし、現在のシステムには2つの問題があります。

  1. 建築家がボトルネックになる

  2. 開発者は、コードの品質とアーキテクチャ(すべての種類の問題につながる)に対して責任を負いません。

これらの問題にどのように対処できますか?コードレビューの担当者を変更する必要がありますか?



1
重複しているようには見えません。質問は関連していますが、可能性のある重複はわずかに異なる問題に焦点を当てています。
バートヴァンインゲンシェナウ14

「コードレビューの品質」とはどういう意味ですか?レビューの終わりに現れるコードの品質を意味しますか?あなたが唯一の私は、あなたがより大きな問題を抱えていると言うだろう。その場合には許容できる品質のコードを生成することができます1、開発者、...持っているように私にはサウンド
AakashM

回答:


15

開発者はコードレビューを行う必要があります。彼らは、コード、会社スタイルの標準および慣行を知っている必要があるため、コードレビューを行う必要があります。他の人にコードレビューを行わせることで、コードが企業の基準を満たしていることを確認するのは彼らの責任ではないと開発者に伝えます。

彼らがコードレビューを行うためのトレーニングが必要だと思うなら、彼らのためにそれを手に入れてください。あなたの現在の状況を考えると、開発者にコードレビューをしてもらい、それを建築家にコメントしてもらうことができます。


2
他の人にコードのレビューをしてもらうことで、開発者に、コードが会社の基準を満たしていることを確認する責任はないことを伝えています。」-はい、いいえ。また、「あなたのコードは(できれば)重要なピアレビューの対象となるので、最初に正しく行うことをお勧めします。」
JensG 14

@JensG:しかし、OPの状況でレビューを行うピアではありません。
jmoreno

3
それが私がそれを大胆にした理由です。
JensG 14

8

この状況では、この経験豊富な開発者の知識がチームの残りの成長を支援するために必要です。チームの質は、最高の開発者のスキルによって定義されません。最悪のスキルによって定義されます。次のようなものを試すことができます:

  • 共同レビュー。これは私の最後のチームで本当にうまくいきました。チーム全体をプロジェクターのある部屋に置き、いくつかのアイテムのレビューを開始しました。おそらく最初はアーキテクトがレビューをガイドする人ですが、数週間後(毎週金曜日に1〜2時間予約しました)、チーム全体が話し始め、現在アーキテクトだけが知っていると思われる重要な概念を理解します。

  • ペアプログラミング。私にとって、これはチームに知識を広めるための最良のツールです。


ペアプログラミングの場合は+1。実際、その質問に対する私の最初の質問は「全員」でしたが、ペアプログラミングはそれをより良くします。質の面だけでなく学習の源泉にすれば、最大限に活用できると思います。
JensG 14

3

システム/ソフトウェアアーキテクトにすべての変更/コミットを承認させることのポイントを見ることができますが、ソフトウェア開発者はアービトレーションを除き、アーキテクトを巻き込まずにレビューを行うことができるはずです。

私が推奨する[*]レビュー手順は次のとおりです。

  • 要件/問題ごとにグループを変更します。
  • レビューする要件/問題のすべての開発者、ソフトウェアアーキテクト、作成者を招待します。(すべてレビューを行う必要があるわけではありません。)
  • 次の場合にレビューが終了したと考えます。
    • 2人の開発者がレビューしました。
    • すべてのコメントが返信されます。(おそらく、ソフトウェアアーキテクトに決定を下してもらうことによって。)
    • 議論が行われずに1営業日が経過しました(または招待されたすべての関係者がレビューしました)。

したがって、あなたの質問に対する私の短い答えは、 開発者がレビューを変更する必要があるということです。

[*]残念ながら、これは私が参加するプロジェクトの運営方法とは限りません。


いつもですか、それともいつもではありませんか?
マルタイン

ご想像のとおり、「常にではない」。見つけてくれてありがとう。答えを修正しました。
ジェイコブスパーアンデルセン14

3

私はチーム全体のアーキテクトを含むチームコードレビューを時折実施するのが好きですが、チームの2人または3人のメンバーの間でコードレビューが大量に行われます。

それが本当にトリッキーなコードまたは機密コードである場合は、アーキテクトまたはチームのシニアメンバーを募集します。

正直なところ、アーキテクトにコードレビューをしてもらうのは馬鹿げているように思えます。専門知識を共有するために、彼は設計レビュー、または時折コードレビューを非公式に行う必要があります。エンジニアリングチームがコードを担当する必要があります。問題がある場合は、時間とともに改善されます。


2

私が同意するのは、たった一人の人がレビューをすれば、残りの人たちはおそらく「わからない、うまくいくように見えるが、その賢い人にそれが大丈夫かどうかを理解させて」と行くだろう。私は次のことを考えることができます:

  • コードを公開して、誰もが作業している内容を確認できるようにします。コードを含む各ファイルの先頭に名前を付けます。多分それらを印刷して、トイレに入れてください。
  • ペアプログラミング; あなたの隣に別の脳がある場合、変数に名前を付ける前によく考えますi
  • 管理人を引き取り、その継承がどのように機能するかを説明します(ああ、そうです、機能しません)。コードを他の人に説明すると役立ちます。コンパイルするかもしれませんし、正しいことをするかもしれませんが、その理由はよくわかりません。今がチャンスです
  • 一連のガイドラインを作成し、全員がそれに従うようにする。ガイドラインが何であれ、ガイドラインがないよりはましです
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.