ワルツのリズムで
検査はすぐに終了するはずです。 完了した検査とは、メッセージが検査され、検出されたすべての欠陥が修正され、検査者が修正内容をチェックすることです。 検査に時間がかかる場合、次の問題が発生します。
- 誰が何をするのか理解するのは難しいです。
- 開発者は焦点が合っていません。つまり、作業中にいくつかの検査とタスクが同時に行われるため、生産性が低下します。
- 検査は無関係になります。つまり、検査のために1つのコードが発行されましたが、実際にはバージョン管理システムではすでに異なっています。
- 検査の焦点がずれます。 検査に時間がかかるほど、コードがより多くの修正を受け取ることになり、検査の実施が難しくなります。
検査が3日以上続く場合、何か問題があります。誰かが遅れているか、広大さを把握しようとしています。
抱きしめる
検査官は、この種のタスクがすでに繰り返し解決されていることを確認することがあり、リファクタリングが行われれば、同様のタスクをはるかに安価に解決できます。 その結果、インスペクターはジレンマに直面します。リファクタリングは時間のかかる計画外の作業になる可能性があるため、検査内でリファクタリングを実行するかどうかのリマークを書きます。
リファクタリングの必要性を理解することは検査官の作業の有益な結果であり、保存する必要があるため、一方で、発言を記録する必要があります。 さらに、リファクタリングを行わない場合、別の同様のタスクを実行するときに引き続き努力を無駄にします。 一方、検査官がそのような欠陥を作成すると、別の問題が発生します-非常に長い検査。 状況から抜け出す方法は、この検査の範囲外で新しいリファクタリングタスクを作成することです。 つまり、重大な欠陥を個別のタスクとして開始し、個別の検査を作成する方が適切です。 「重大な欠陥」とは何かを大まかに推定すると、修正に2時間以上かかる欠陥です。
一度聞いた方が良い
ライブコミュニケーションに代わるものはありません。 複雑なソリューションを持つ客観的に複雑なタスクがあります。 この場合、検査を行う前に、作成者は、指、IDE、紙、またはフェルトペン付きのボードを使用して、検査員にソリューションをライブで伝え、表示することができます。 さらに、理想的なケースでは、作成者はソリューションを実装する前にこれを行いますが、決して遅らせることはできません。 しかし、危険があります-口頭での説明で悪い読めないコードを説明しようとしないでください。 すべてが詳細に伝えられたとしても、コードは悪いままです。
ところで、テスターをそのようなストーリーに招待することが役立つ場合があります。 実装の詳細を知ることは、彼らがより効率的にテストし、重要なエラーを見つけるのに役立ちます。
視覚化する
コード検査は、開発とテストに加えて、タスクライフサイクルの重要なフェーズです。 スクラムボードまたはカンバンボードを使用している場合は、「開発中」列と「テスト準備完了」列の間の検査段階で別の列を選択するのが理にかなっています。 この場合、ボードは実際の状況をより正確に反映します。