アジャイルプラクティス：コードレビュー-レビューに失敗するか、問題を提起しますか？

2週間のスプリントの終わりに、タスクにコードレビューがあります。このレビューで、機能する、読み取り可能な関数を発見しましたが、非常に長く、コードの匂いがいくつかあります。簡単なリファクタリングジョブ。

それ以外の場合、タスクはdoneの定義に適合します。

2つの選択肢があります。

• このスプリントでチケットが閉じないようにコードレビューに失敗します。チケットを渡すことができないため、士気に少し打撃を与えます。
• リファクタリングは小さな作業であり、次のスプリント（または開始前）で小さなハーフポイントストーリーとして行われます。

私の質問は次のとおりです。レビューを失敗するのではなく、レビューの裏からチケットを上げることに固有の問題や考慮事項がありますか？

私が見つけることができ、詳細コードのレビューを読んだことがあるリソースは、通常、100％または何もありませんが、通常は現実的ではありません。

レビューに失敗するのではなく、レビューの裏からチケットを上げることに固有の問題や考慮事項がありますか？

本質的ではありません。たとえば、現在の変更の実装により、すでに存在していた問題が発見された可能性がありますが、これまで知られていなかった/見えていませんでした。チケットの失敗は、実際に説明されたタスクとは関係のない何かのために失敗するので不公平です。

レビューで機能を発見しました

ただし、ここでの機能は、現在の変更によって追加されたものであると推測されます。この場合、コードが匂いテストに合格しなかったため、チケットは失敗するはずです。

どこに線を引きますか？このコードが、現在の形式でコードベースにとどまるほどきれいだとは思わないことは明らかです。では、なぜチケットにパスを与えることを検討するのですか？

このスプリントでチケットが閉じないようにコードレビューに失敗します。チケットを渡すことができないため、士気に少し打撃を与えます。

コードベースの品質を高めるのではなく、チームの士気を高めるためにこのチケットにパスを与えようとしていると間接的に主張しているように思えます。

その場合は、優先順位がまちまちです。クリーンコードの標準は、チームを幸せにするという理由だけで変更すべきではありません。コードの正確さと清潔さは、チームの雰囲気に左右されません。

リファクタリングは小さな作業であり、次のスプリント（または開始前）で小さなハーフポイントストーリーとして行われます。

元のチケットの実装がコードのにおいを引き起こした場合、元のチケットで対処する必要があります。コードの匂いを元のチケットに直接帰属させることができない場合にのみ、新しいチケットを作成する必要があります（たとえば、「ラクダの背中を壊したストロー」シナリオ）。

私が見つけることができ、詳細コードのレビューを読んだことがあるリソースは、通常、100％または何もありませんが、通常は現実的ではありません。

合格/不合格は本質的にバイナリ状態であり、本質的にすべてまたはゼロです。

ここで言及しているのは、コードレビューを完璧なコードが必要であるか、そうでなければ失敗すると解釈することであり、そうではありません。

コードは真っ白ではなく、チーム/会社が採用している清潔の合理的な基準に単に準拠する必要があります。この標準の順守はバイナリの選択です。順守する（合格）またはしない（失敗する）。

問題の説明に基づいて、これが期待されるコード標準に準拠しているとは思わないことは明らかであり、したがって、チームの士気などの不当な理由で合格すべきではありません。

それ以外の場合、タスクはdoneの定義に適合します。

「仕事をやり遂げる」がコード品質の最高のベンチマークだった場合、クリーンコードの原則と最初から良いプラクティスを発明する必要はありませんでした。コンパイラとユニットテストはすでに自動レビュープロセスであり、コードレビューやスタイル引数は必要ありません。

2週間のスプリントの終わりに、タスクにコードレビューがあります[...]簡単なリファクタリングジョブ。

スプリントの最後にそれが表示されるのはなぜですか？コードのレビューは、コードが完了したと思われるとすぐに（またはその前に）行われる必要があります。完了した各ストーリーで完了の定義を確認する必要があります。

デモ/スプリントのレビューの直前にストーリーを完成させ、「小さな」タスクに適合できない場合は、作業の見積もりを改善する必要があります。はい、その話は終わりませんでした。コードレビューのためではなく、コードレビューからの変更を組み込む予定がないためです。これは、「テスト」をゼロ時間と見積もるようなものです。なぜなら、「正しくプログラミングすれば、正しく機能するでしょうか？」それはそれが動作する方法ではありません。テストではエラーが検出され、コードレビューでは変更すべきものが検出されます。そうでない場合、それは時間の大きな無駄になります。

要約すると、はい、DoDはバイナリです。合格または不合格。コードレビューはバイナリではなく、進行中のタスクに似ている必要があります。失敗することはできません。それはプロセスであり、最終的には完了です。しかし、適切に計画しないと、その「完了」段階に間に合わず、スプリント終了時に「未完了」の領域にとどまります。それは士気にとっては良くありませんが、計画ではそれを考慮する必要があります。

シンプル：変更を確認します。それ以外の場合は、プログラムの状態を確認しません。3,000行の関数のバグを修正する場合、私の変更がバグを修正することを確認し、それだけです。そして、私の変更がバグを修正した場合、あなたはその変更を受け入れます。

関数が長すぎると思う場合は、変更要求を入れて、私の変更が受け入れられた後、関数を短くするか、分割して、その変更要求をその重要度に従って優先順位付けすることができます。チームがより重要なことを行うという決定が下された場合、後で処理されます。

コードのレビュー中に開発の優先順位を決定できれば、それはばかげているでしょう。そのため、私の変更を拒否することは、開発の優先順位を決定する試みです。

要約すると、コードの変更を受け入れ、変更を確認するときに見たものに基づいてすぐにチケットを発行することは絶対に受け入れられます。場合によっては、変更自体が問題を引き起こした場合にこれを行うこともあります。問題を修正するよりも、今すぐ変更を行うことが重要である場合。たとえば、変更を待っている他のユーザーがブロックされた場合、コードを改善できる間、それらのブロックを解除する必要があります。

このスプリントでチケットが閉じないようにコードレビューに失敗します。チケットを渡すことができないため、士気に少し打撃を与えます。

これが問題のようです。
理論的には、あなたは何をすべきかを知っていますが、締め切りに近いので、あなたがすべきと知っていることをしたくありません。

答えは簡単です。スプリントの初日にコードレビュー用に同じコードを取得した場合は、何でもするようにしてください。受け入れられる場合は、今すぐにすべきです。そうでなければ、今はそうではありません。

プロセスの巨大な部分はどのような決定され行わ手段をしてあなたの銃にこだわります。また、テストが機能的に完了していることをテストで確認できるように、過度にコミットせずにピアレビューを時間内に完了させることも意味します。

コードレビューの問題に関しては、それを処理する方法がいくつかあり、正しい選択はいくつかの要因に依存します。

• あなただけのことができ、自分自身アップコードをきれいにし、人はあなたが何をしたか知ってみましょう。いくつかの指導の機会を提供しますが、これは数分で実行できるかなり単純なものでなければなりません。
• 何が間違っているかについてのコメントでそれを蹴飛ばすことができます。エラー処理が不十分な場合、または開発者が同じ間違いを繰り返し続ける場合は、これを保証できます。
• チケットを作成して、技術的な負債を負うことができます。チケットは、後で支払うためにあります。あなたはタイムクランチであり、変更をレビューする過程で、変更に直接関係しない大きな問題を見るかもしれません。

要するに、仕事を終えたら仕事を終える必要があるということです。開発者が取り組んだものよりも大きな問題がある場合は、フラグを立てて先に進みます。しかし、スプリントが終了するまでに数時間かかるような立場にいてはいけません。あなたは今、ピアレビューを始めています。それは、リソースを過剰にコミットしたり、ピアレビューを先延ばしにしたりするような匂いがします。（プロセス臭）。

コードレビューの問題の優先順位を下げることには固有の問題はありませんが、チームとして同意する必要がある主な問題は次のように聞こえます。

1. コードレビューの目的は何ですか？
2. コードレビューの結果は、ワークアイテムの完了の定義とどのように関連していますか？
3. コードレビューがゲーティングテストとして適用される場合、どの問題が「ブロッカー」と見なされますか？

これはすべて、Doneの定義としてチームが同意したことに帰着します。ゼロアイテムでコードレビューに合格することがワークアイテムの完了の定義である場合、この要件を満たしていないアイテムを閉じることはできません。

単体テスト中に単体テストが失敗した場合と同じです。単体テストに合格することが要件である場合、単体テストを無視するのではなく、バグを修正します。

チームが完了の定義であるコードレビューに同意していない場合、コードレビューはワークアイテムのゲーティング受け入れテストではありません。これらは、必要な追加作業を探すためのバックログプロセスの一部であるチームアクティビティです。その場合、発見した問題は元の作業項目の要件とは無関係であり、チームが優先順位を付けるための新しい作業項目です。

たとえば、チームが変数名「myObkect」を見ることを本当に嫌っていても、提供されたビジネス機能に影響を与えないため、一部の変数名のタイプミスの修正を優先することは完全に受け入れられます。

ここでの上位の回答は非常に優れています。これはリファクタリングの角度に対応しています。

ほとんどの場合、リファクタリング時の作業の大部分は既存のコードを理解することです。その後の変更は、一般的に次の2つの理由のいずれかにより、作業の小さな部分です。

1. コードをより明確かつ/または簡潔にするだけであれば、必要な変更は明白です。多くの場合、よりきれいに見える変更を実際に動作させ、実際の動作を確認したり、より複雑なコードの微妙な点を見逃したりして、コードを理解しました。

2. 新しい機能を簡単に構築するために必要な特定の設計または構造をすでに念頭に置いています。その場合、そのデザインを開発する作業は、その必要性を生み出したストーリーの一部でした。その設計に到達するためにリファクタリングを行う必要はありません。

既存のコードを学習して理解することは、非永続的な利益のためにかなりの量の作業です（その1か月間、コードを読み続けたり操作したりしなければコードについて多くの人が忘れてしまう可能性があります）。問題を引き起こしているコード領域、または近い将来に変更を予定しているコード領域を除き、これを行うことは意味がありません。次に、これがリファクタリングの主な作業であるため、現在問題が発生しているか、近い将来コードを変更する予定がない限り、コードのリファクタリングを行わないでください。

ただし、例外が1つあります。現在、誰かがコードを十分に理解しており、時間の経過とともに流出する場合、その理解を使用してコードをより明確にし、後ですばやく理解することは良い投資になる可能性があります。それが、ストーリーの開発を終えたばかりの人がいる状況です。

リファクタリングは小さな作業であり、次のスプリント（または開始前）で小さなハーフポイントストーリーとして行われます。

この場合、リファクタリング用に別のストーリーを作成することを考えているのは、いくつかの面での警告サインです。

1. リファクタリングをコーディングの一部としてではなく、個別の操作として考えているため、プレッシャーがかかってドロップする可能性が高くなります。

2. 誰かが次に作業する必要があるときに理解するためにより多くの作業が必要なコードを開発しているため、ストーリーが長くなります。

3. あなたは多くの利益を得られないものを時間とエネルギーのリファクタリングに浪費しているかもしれません。（後から変更が発生した場合、誰かがコードを再理解する必要があります。それはリファクタリングジョブとより効率的に組み合わされます。変更が後で発生しない場合、リファクタリングは機能しませんでしたおそらく審美的なものを除いて、まったく目的。

したがって、ここでの答えは、アイテムを失敗させて、プロセス内の何かが失敗したことを明確にすることです（この場合、開発者またはチームはレビューのための時間を割り当てず、レビュー外の変更を実装します）。アイテムに。

次のイテレーションの見積もりに行くときは、レビューに合格して次のイテレーションに追加するために残っていると思われる作業量として既存のストーリーを再見積もりしますが、前のイテレーションからの見積もりを保持します。次の反復の最後にストーリーが完了したら、作業の合計履歴を1番目と2番目の推定値の合計に設定して、推定作業量が実際にどれだけ投入されたかを確認します。これは、プロセスの現在の状態で、将来の同様のストーリーのより正確な推定値を生成するのに役立ちます。（つまり、見かけ上の過小評価が二度と起こらないと仮定しないでください。同じようなストーリーをより少ない作業で完了するまで、二度と起こらないと思います。）

私は個人的には馴染みのある概念ではないため、コードレビューの「失敗」という概念に対する回答とコメントに応答がないことに驚いています。また、その概念や、その用語を使用しているチームのメンバーに満足することもありません。

あなたの質問は「アジャイルプラクティス」を明示的に要求しているので、アジャイルマニフェスト（エンファシス鉱山）をもう一度見てみましょう。

私たちは、ソフトウェアを開発し、他の人がそれを行うのを支援することにより、ソフトウェアを開発するより良い方法を発見しています。この作業を通して、私たちは次のことを大切にしました。

• プロセスとツールを介した個人と相互作用
• 包括的なドキュメントよりも機能するソフトウェア
• 契約交渉を介した顧客コラボレーション
• 計画に従うことによる変化への対応

つまり、右側の項目に価値がある一方で、左側の項目をより重視します。

チームに話しかけます。問題のコードについて話し合います。コストとメリットを評価し、専門家のまとまりのあるグループとして、このコードを今すぐリファクタリングするか、後でリファクタリングするか、またはまったくリファクタリングしないかを決定します。

共同作業を開始します。失敗したコードレビューを停止します。

レビューで、機能し、読み取り可能な関数を発見しましたが、非常に長く、いくつかのコードのにおいがあります...

レビューに失敗するのではなく、レビューの裏側でチケットを上げることに固有の問題や考慮事項はありますか？

何の問題もありません（私のチームでは）。コードは、チケットに記載されている受け入れ基準を満たしている（つまり機能している）と想定しています。バックログアイテムを作成して、長さとコードの匂いに対処し、他のチケットと同じように優先順位を付けます。本当に小さい場合は、次のスプリントのために優先順位を高くします。

私たちが言っていることの1つは、「延期された完全性よりも進歩的な改善を選択すること」です。

非常に流動的なプロセスがあり、かなりの数の「概念実証」機能（スプリントごとに1つまたは2つ）を構築します。これらは開発とテストを通過しますが、内部の利害関係者のレビューを過ぎません（代わりにこれを行うことができます） ？）、アルファ、またはベータ...一部は存続し、一部は存続しません。

現在のプロジェクトでは、特定の機能を何回構築し、利害関係者の手に渡ったのか、スプリントが1、2回後、製品の方向が変わった、または要件が原因で完全に削除された回数を失いました機能の実装方法の完全な再キャスト。削除された機能の残りの「洗練」タスク、または新しい要件に適合しないタスクは、バックロググルーミングの一部と同様に削除されます。

私の意見では、この問題を見るには2つの方法があります。

1. アカデミックな方法
2. 現実世界の方法

学問的に言えば、ほとんどのコードレビュープロセスは、コード品質基準が満たされていない場合にPBI（製品バックログアイテム）の展開に失敗するために存在します。

ただし、実際の世界では誰もTにアジャイルに従うことはできません（多くの理由のうちの1つ）。業界ごとに要件が異なります。そのため、今すぐコードを修正するか、技術的負債を負う（新しいPBIを作成する可能性が高い）場合は、ケースごとに決定する必要があります。スプリントやリリースを危険にさらしたり、不当な量のリスクをもたらしたりする場合は、ビジネスの利害関係者が決定に関与する必要があります。

どちらでもない。コードレビューに失敗すると、タスクは実行されません。しかし、あなたは個人的な意見でコードレビューに失敗することはできません。コードはパスします。次のタスクに進みます。

それは簡単な呼び出しである必要があり、それがコードレビューのための十分に書き留められたルールを持っていないことを示唆していないという事実。

1. 「機能は非常に長い」。書き留めてください：関数はX行よりも短くなければなりません（関数の長さに関する規則が良いことであることを示唆していません）。

2. 「いくつかのコードの匂いがあります」。書き留めてください：パブリック関数には、機能とパフォーマンスのユニットテストが必要です。CPUとメモリの使用量は両方とも制限xおよびy未満でなければなりません。

コードレビューを渡すためのルールを定量化できない場合、基本的に「好きではないコード」であるこれらのケースを取得します。

「気に入らないコード」に失敗するべきですか？私はノーと言うでしょう。当然、コード以外の側面に基づいて合格/不合格になります：あなたはその人が好きですか？彼らは自分の主張について強く主張しているのか、それとも言われた通りに主張しているのか？彼らはあなたをレビューするときにあなたのコードを渡しますか？

また、定量化できないステップを推定プロセスに追加します。プログラムの作成方法に基づいてタスクを見積もりますが、最後にコーディングスタイルを変更する必要があります。

それはどのくらい追加されますか？同じレビュアーがその後のコードレビューを行い、最初のレビュアーに同意するか、または追加の変更を見つけますか？セカンドオピニオンを探したり、ケースを主張したりしながら、変更に同意せずに変更を延期した場合はどうなりますか？

タスクを迅速に実行する場合は、できるだけ具体的にする必要があります。あいまいな品質ゲートを追加しても、生産性は向上しません。

Re：ルールを書き留めることは不可能です!!

それほど難しくありません。あなたは本当に「私は「良い」コードによって私が意味することを表現できない」と意味します。それを認識したら、誰かの仕事がスクラッチではないと言ったら、明らかに人事の問題であることがわかりますが、その理由はわかりません。

できるルールを書き留め、コードを「良い」ものにする理由についてビールについて議論します。