アジャイルプラクティス：コードレビュー-レビューに失敗するか、問題を提起しますか？
2週間のスプリントの最後に、タスクにコードレビューがあります。このレビューで、機能し、読み取り可能な機能が見つかりましたが、非常に長く、コードの匂いがいくつかあります。簡単なリファクタリングジョブ。
それ以外の場合、タスクは完了の定義に適合します。
2つの選択肢があります。
- コードレビューに失敗し、チケットがこのスプリントで閉じないようにします。チケットを渡すことができないため、士気に少し当たります。
- リファクタリングは小さな作業であり、次のスプリントで（または開始前であっても）小さなハーフポイントストーリーとして行われます。
私の質問は次のとおりですレビューの失敗からではなく、レビューの裏側からチケットを上げることに固有の問題や考慮事項はありますか？
私が見つけて詳細コードレビューを読んだことがあるリソースは、通常100％または何もありませんが、それは通常現実的ではありません。
失敗するのではなく、レビューの裏側からチケットを上げることに固有の問題や考慮事項はありますか？
本質的にはありません。たとえば、現在の変更の実装によって、すでにそこに存在していたが、今まで知られていない/明らかではなかった問題が発掘された可能性があります。チケットの失敗は、実際に説明されているタスクとは無関係の何かが原因で失敗するため、不公平です。
レビューで私たちは機能を発見します
ただ、ここの機能は今回の変更で追加されたものだと思います。この場合、コードが臭いテストに合格しなかったため、チケットは失敗するはずです。
すでに線を引いていない場合は、どこに線を引きますか？このコードは、現在の形式でコードベースにとどまるのに十分クリーンであるとは明らかに思わないでしょう。では、なぜチケットにパスを与えることを検討するのでしょうか。
コードレビューに失敗し、チケットがこのスプリントで閉じないようにします。チケットを渡すことができないため、士気に少し当たります。
コードベースの品質を向上させるのではなく、チームの士気を高めるためにこのチケットを渡すことを試みていると間接的に主張しているように思えます。
その場合、優先順位はさまざまです。クリーンなコードの標準は、チームをより幸せにするという理由だけで変更すべきではありません。コードの正確さと清潔さは、チームの気分に左右されません。
リファクタリングは小さな作業であり、次のスプリントで（または開始前であっても）小さなハーフポイントストーリーとして行われます。
元のチケットの実装によってコードの臭いが発生した場合は、元のチケットで対処する必要があります。コードの匂いを元のチケットに直接起因させることができない場合にのみ、新しいチケットを作成する必要があります（たとえば、「ラクダの背中を壊したストロー」シナリオ）。
私が見つけて詳細コードレビューを読んだことがあるリソースは、通常100％または何もありませんが、それは通常現実的ではありません。
合格/不合格は本質的にバイナリ状態であり、本質的にすべてまたは何もありません。
ここであなたが言及しているのは、コードレビューをperfectコードが必要であると解釈するか、そうでなければそれを失敗させると解釈する以上のものであり、それは場合。
コードは完全なものである必要はありません。コードは、チーム/会社が採用している清潔さの合理的な基準に単純に準拠している必要があります。その標準の順守は、バイナリの選択です。それは、順守する（合格）か、しない（失敗）かです。
問題の説明に基づいて、これが予想されるコード標準に準拠しているとは思わないことは明らかです。そのため、チームの士気などの根本的な理由でそれを渡すべきではありません。
それ以外の場合、タスクは完了の定義に適合します。
「仕事が完了する」ことがコード品質の最高のベンチマークである場合、クリーンなコードの原則と最初から適切なプラクティスを考案する必要はなかったでしょう。コンパイラとユニットテストはすでに自動化されたレビュープロセスであり、コードレビューやスタイル引数は必要ありません。
2週間のスプリントの最後に、タスクにコードレビューがあります[...]簡単なリファクタリングジョブ。
なぜそれがスプリントの最後にポップアップするのですか？コードのレビューが行われるはずですコードが完了したと思ったらすぐに（またはその前でも）。完成したストーリーごとに完了の定義を確認する必要があります。
デモやスプリントのレビューの少し前にストーリーを仕上げすぎて「小さな」タスクに当てはまらない場合は、作業の見積もりをよくする必要があります。はい、その話は終わっていませんでした。コードレビューのためではなく、コードレビューからの変更を組み込む予定がなかったためです。これは、「テスト」にかかる時間がゼロであると見積もるようなものです。なぜなら、「正しくプログラミングすれば、機能するでしょう」。それはそれが機能する方法ではありません。テストではエラーが見つかり、コードレビューでは変更点が見つかります。そうでない場合、それは時間の大きな無駄になります。
つまり、要約すると、DoDはバイナリです。合格または不合格。コードレビューはバイナリではなく、継続的なタスクのようなものでなければなりません。 失敗することはできません。これはプロセスであり、最終的には完了です。しかし、適切に計画しないと、時間内にその「完了」ステージに到達できず、スプリント終了時に「未完了」領域で立ち往生します。それは士気には良くありませんが、計画ではそれを考慮する必要があります。
シンプル：changeを確認します。それ以外の場合は、プログラムの状態を確認しません。 3,000行の関数のバグを修正した場合、私の変更がバグを修正したことを確認してください。そして、私の変更でバグが修正された場合は、変更を受け入れます。
関数が長すぎると思われる場合は、変更要求を入力して関数を短くするか、分割してくださいafter私の変更が受け入れられ、その変更要求に次の優先順位を付けることができますその重要性。チームにもっと重要なことがあると決定された場合は、後で処理されます。
コードレビュー中に開発の優先順位を決定できるとしたらばかげているでしょう。その理由で私の変更を拒否することは、開発の優先順位を決定しようとする試みになるでしょう。
要約すると、コードの変更を受け入れ、変更を確認したときに見たものに基づいてすぐにチケットを発行することは絶対に許容されます。場合によっては、変更自体が問題を引き起こした場合にもこれを実行します。問題を修正するよりも、変更を加えることが重要な場合今です。たとえば、他の人がブロックされ、変更を待っている場合、コードを改善できる間、それらのブロックを解除したいとします。
コードレビューに失敗し、チケットがこのスプリントで閉じないようにします。チケットを渡すことができないため、士気に少し当たります。
これが問題のようです。
理論的には何をすべきかはわかっていますが、締め切りが迫っているので、やるべきことをしたくないのです。
答えは簡単です。スプリントの初日にコードレビュー用に同じコードを入手した場合は、何をしてもいいです。それが許容可能であれば、今はそれをすべきです。そうでない場合、それは今ではありません。
プロセスの大部分は、doneが何を意味するかを決定し、銃に固執することです。また、テストが作業を機能的に完了していることを確認できるように、過度のコミットを行わず、ピアレビューを時間内に完了させることも意味します。
コードレビューの問題に関しては、いくつかの対処方法があり、適切な選択はいくつかの要因に依存します。
- あなたは自分でコードを整理するして、その人にあなたが何をしたかを知らせることができます。メンタリングの機会を提供しますが、これは数分で実行できるかなり単純なものでなければなりません。
- キックバックして、何が問題なのかに関するコメントを追加できます。エラー処理が十分に行われていない場合、または開発者が同じ間違いを繰り返し続けている場合、これは保証されます。
- チケットを作成して、技術的負債を負うことができます。チケットは後で支払うことを確認するためにあります。あなたは時間の危機に瀕していて、変更をレビューしている最中に、変更に直接関係のないより大きな問題を目にしているかもしれません。
結論としては、仕事が終わったら、それで終わらせる必要があります。開発者が取り組んだ問題よりも大きな問題がある場合は、フラグを立てて次に進みます。しかし、スプリントが終了するまでに何時間もかかるような立場にあるべきではなく、今やピアレビューを行うところです。これは、リソースを過度にコミットしたり、ピアレビューに先延ばししたりするようなにおいがします。 （プロセスのにおい）。
コードレビューの優先順位を下げることには固有の問題はありませんが、チームとして同意する必要がある主な問題は次のとおりです。
- コードレビューの目的は何ですか？
- コードレビューの結果は、作業項目の完了の定義とどのように関連していますか？
- コードレビューがゲーティングテストとして適用される場合、どの問題が「ブロッカー」と見なされますか？
これはすべて、チームが完了の定義として合意したことに帰着します。ゼロの問題でコードレビューを渡すことがワークアイテムの完了の定義である場合、この要件を満たさないアイテムを閉じることはできません。
単体テスト中に単体テストが失敗した場合と同じです。ユニットテストに合格することが要件である場合は、ユニットテストを無視するのではなく、バグを修正します。
チームがコードレビューが完了の定義であることに同意していない場合、コードレビューはワークアイテムのゲーティング受け入れテストではありません。これらは、必要になる可能性のある追加の作業を探すためのバックログプロセスの一部であるチームアクティビティです。その場合、発見した問題は、元の作業項目の要件とは無関係であり、チームが優先する新しい作業項目です。
たとえば、チームが変数名「myObkect」を実際に見たくないとしても、提供されたビジネス機能に影響を与えないため、一部の変数名のタイプミスを優先的に修正することをチームが完全に許容できる場合があります。
ここで投票数の多い回答は非常に優れています。これはリファクタリングの角度を扱います。
ほとんどの場合、リファクタリング時の作業の大部分は既存のコードを理解することです。その後の変更は、次の2つの理由のいずれかにより、通常、作業の小さな部分です。
コードをより明確かつ/または簡潔にするだけの場合、必要な変更は明白です。多くの場合、よりクリーンに見える変更を試して、実際に機能するかどうか、またはより複雑なコードで微妙な部分を見落としたかどうかを確認することで、コードの理解を深めました。
新しい機能を簡単に構築するために必要な特定の設計または構造をすでに考えています。その場合、そのデザインを開発する作業は、それを必要とするストーリーの一部でした。その設計に到達するためにリファクタリングを行う必要があるかどうかは関係ありません。
既存のコードを学習して理解することは、非永続的な利益のためにかなりの量の作業です（その期間にわたってコードの読み取りや操作を継続しないと、誰かが1か月後にコードについて多くのことを忘れてしまう可能性があります）。問題を引き起こしているコードの領域、または近いうちに変更する予定がある場合を除いて、これを行うのは意味がありません。次に、これがリファクタリングの主な作業であるため、現在問題が発生しているか、近い将来に変更する予定がない限り、コードのリファクタリングは行わないでください。
ただし、例外が1つあります。誰かが現在、時間の経過とともにリークするコードを十分に理解している場合、その理解を使用してコードをより明確かつ迅速に理解することは、良い投資になる可能性があります。それが、ストーリーの作成を終えたばかりの誰かがいる状況です。
リファクタリングは小さな作業であり、次のスプリントで（または開始前であっても）小さなハーフポイントストーリーとして行われます。
この場合、リファクタリングのために別のストーリーを作ることを考えているのは、いくつかの面での警告サインです。
あなたはリファクタリングをコーディングの一部としてではなく、個別の操作として考えているため、プレッシャーにさらされる可能性があります。
あなたは、誰かが次にそれを使って作業する必要があるときに理解するためにより多くの作業を必要とするコードを開発しているため、ストーリーが長くなります。
あなたは多くの利益を得られないものを時間とエネルギーのリファクタリングに浪費しているかもしれません。 （変更がずっと後で発生した場合でも、とにかく誰かがコードを再理解する必要があります。それはリファクタリングジョブとより効率的に組み合わされます。変更が後で発生しない場合、リファクタリングは何も提供しませんでしたおそらく美的目的を除いて、目的はまったくありません。）
したがって、ここでの答えは、アイテムを失敗させて、プロセス内の何かが失敗したことを明確にし（この場合は、開発者またはチームがレビューに時間を割り当てず、レビューから出た変更を実装しないことです）、開発者に直ちに作業を継続させることです。アイテムに。
次のイテレーションの見積もりに行くときは、既存のストーリーを再見積もりします。レビューに合格し、次のイテレーションに追加するために残された作業量がいくらか残っているようですが、前の反復。ストーリーが次の反復の終わりに完了したら、過去の総作業量を最初と2番目の見積もりの合計に設定して、見積もり作業が実際にどれだけ投入されたかがわかるようにします。これにより、将来のプロセスの現在の状態で、類似ストーリーのより正確な見積もりを作成できます。 （つまり、明らかな過小評価が再び起こらないとは思わないでください。少ない労力で同様のストーリーを無事に完了するまで、再び起こると思います。）
コードレビューを「失敗させる」という概念に対する回答とコメントでの応答の欠如に驚いています。それは、私が個人的に知っている概念ではないためです。また、私はその概念や、その用語を使用しているチーム内の誰にでも慣れません。
あなたの質問は「アジャイルの実践」を明確に要求しているので、アジャイルのマニフェストをもう一度見てみましょう（強調は私のものです）：
私たちは、ソフトウェアを開発し、他の人がそれを行うのを助けることにより、ソフトウェアを開発するより良い方法を発見しています。この作業を通して、私たちは価値を見出しました：
- 個人と相互作用プロセスとツール
- 包括的なドキュメントを介して動作するソフトウェア
- 顧客とのコラボレーション契約交渉
- 計画に従った変更への対応
つまり、右側の項目には価値がありますが、左側の項目にはさらに価値があります。
チームに相談してください。問題のコードについて話し合います。コストとメリットを評価し、専門家のまとまったグループとして、このコードを今すぐリファクタリングするか、後でリファクタリングするか、しないかを決定します。
コラボレーションを開始します。コードレビューの失敗を停止します。
私の意見では、この問題を調べる方法は2つあります。
- 学術的な方法
- 現実世界の方法
学問的に言えば、コード品質基準が満たされていない場合、ほとんどのコードレビュープロセスはPBI（製品バックログ項目）の展開に失敗するために存在します。
ただし、現実世界の誰もがTにアジャイルに追随することはありません。理由の1つはさまざまですが、業界によって要件は異なります。これにより、コードを今すぐ修正するか、または 技術的な負債 （おそらく新しいPBIを作成する可能性があります）を引き受けるかは、ケースごとに決定する必要があります。スプリントやリリースを危険にさらしたり、不当なリスクをもたらしたりする場合は、ビジネスの利害関係者が決定に関与する必要があります。
レビューで、機能し、読みやすい機能を発見しましたが、非常に長く、コードの匂いがいくつかあります...
失敗するのではなく、レビューの裏側からチケットを上げることに固有の問題や考慮事項はありますか？
まったく問題ありません（私のチームの意見では）。コードがチケットに記載されている承認基準を満たしていると想定しています（つまり、機能します）。長さやコードの臭いに対処するバックログアイテムを作成し、他のチケットと同じように優先順位を付けます。本当に小さい場合は、次のスプリントのために高い優先順位を付けます。
私たちが持っていることわざの一つは「延期された完璧さよりも漸進的な改善を選ぶ」です。
私たちは非常に流動的なプロセスを持っており、かなりの数の「概念実証」機能（スプリントごとに1つまたは2つ）を構築します。これらの機能は、開発とテストを通じて実現しますが、内部の利害関係者のレビューを通過することはありません（うーん、代わりにこれを行うことはできますか？ ？）、アルファ、またはベータ...一部は存続し、一部は存続しません。
現在のプロジェクトでは、特定の機能を何回構築し、それを関係者の手に渡したか、そして1つか2つ後のスプリントでは、製品の方向性が変更されたか、要件が原因で完全に削除されました。機能の実装方法の完全なリキャスト。削除された機能の残りの「調整」タスク、または新しい要件に適合しないタスクは、バックロググルーミングの一部と同様に削除されます。