コードレビューでポジティブなものを見つける方法は？
昨年の深刻な品質問題の後に、私の会社は最近コードレビューを導入しました。コードレビュープロセスは、ガイドラインやチェックリストなしですぐに導入されました。 別の開発者と私は、システムに加えられたすべての変更を、トランクにマージする前に確認することにしました。 また、「テクニカルリード」に選ばれました。つまり、コードの品質には責任がありますが、プロセスの変更を実装したり、開発者を再割り当てしたり、プロジェクトを保留したりする権限はありません。 技術的には、マージを拒否して、開発に戻すことができます。現実には、これはほとんどの場合、上司が期限内に出荷することを要求することで終わります。 私たちのマネージャーは、今後のプロジェクトのスケジュールを作成することに主に関心があるMBAです。彼が試みている間、彼は私たちのソフトウェアがビジネスの観点から何をするのかほとんどわからず、開発者からの説明なしに最も基本的な顧客の要求さえ理解しようと努力しています。 現在、開発はSVNの開発ブランチで行われています。開発者は準備ができたと判断した後、チケットシステムのチケットをマネージャーに再割り当てします。マネージャーはそれを私たちに割り当てます。 コードレビューにより、チーム内でいくつかの緊張が生じています。特に、古いメンバーの一部は、変更に疑問を呈しています（つまり、「常にこのようにしていた」または「メソッドに意味のある名前が必要なのはなぜか、わかりますか？」）。 最初の数週間後、同僚が問題を起こさないように、同僚が物事を滑らせ始めました（バグ報告が顧客によって提出された後、彼女はバグを知っていたが、開発者はそれを指摘することに彼女に腹を立てます）。 一方、私は現在、コミットされたコードの問題を指摘するためのお尻であることで知られています。 私の基準が高すぎるとは思わない。 現時点での私のチェックリストは次のとおりです。 コードがコンパイルされます。 コードが機能する方法は少なくとも1つあります。 コードはほとんどの通常のケースで機能します。 コードはほとんどのエッジケースで動作します。 挿入されたデータが有効でない場合、コードは妥当な例外をスローします。 しかし、私はフィードバックを行う方法の責任を完全に受け入れます。私はすでに、何かを変更する理由を説明するアクション可能なポイントを既に与えています。悪いと思うときは、別の方法で開発していたと指摘します。 私が欠けているのは、「良い」と指摘するものを見つける能力です。悪いニュースを良いニュースに挟もうとするべきだと読みました。 しかし、私は良いものを見つけるのに苦労しています。「今度は、実際にあなたがしたことをすべてコミットした」というのは、すてきで助けになるというよりも、お世辞です。 サンプルコードレビュー こんにちはジョー、 Library \ ACME \ ExtractOrderMailクラスの変更について質問があります。 「TempFilesToDelete」を静的としてマークした理由がわかりませんでしたか？現時点では、「GetMails」への2回目の呼び出しは例外をスローします。これは、ファイルを追加したが、削除した後に削除しないためです。関数は実行ごとに1回だけ呼び出されることを知っていますが、将来的には変更される可能性があります。インスタンス変数にするだけで、複数のオブジェクトを並行して使用できます。 ...（機能しない他のポイント） マイナーポイント： 「GetErrorMailBody」がパラメーターとして例外を受け取るのはなぜですか？私は何か見落としてますか？例外をスローするのではなく、単に例外を渡して「ToString」を呼び出します。何故ですか？ SaveAndSendはMethodの適切な名前ではありません。このメソッドは、メールの処理が失敗した場合にエラーメールを送信します。名前を「SendErrorMail」などに変更できますか？ 古いコードをコメントするのではなく、完全に削除してください。まだ転覆中です。