カツレツを別々に、別々に飛ぶ
多くの場合、タスクの一部としてコードを変更するとき、最初にこのコードをリファクタリングする必要があることを理解するようになります。 1つの検査にリファクタリングとタスクの実装を含める必要はありません。 これらは2つの異なる検査に分割する必要があります。 これは、インスペクターの寿命を単純化し、エラーを発見する機会を増やすために必要です。ある検査で、潜在的に危険な変更を伴うモジュールを、自動リファクタリングを使用して変更された別の100個のモジュール（クラスの名前を変更するなど）、つまり高い確率で組み合わせると、検査官が潜在的に危険な変更をスキップすること。
言い換えれば、異なるタスクのソリューションを1つの検査に結合する必要はありません。 リファクタリングは別のタスクの作業の結果として現れた場合でも、別のタスクです。
通信ボクシング
コード検査を自動化する多くのツールを使用すると、ソースコードと欠陥に関するコメントを残すことができます（たとえば、Code Collaborator）。 この場合、検査官が欠陥を開始するとしばしば議論が白熱し、著者はこれが実際には欠陥ではないことをコメントで説明し始めます。 その結果、聖なる戦争が始まり、それは永遠に続く可能性があります。 これを回避するのは非常に簡単です。検査中にコメントを残す必要はまったくありません。 この場合、検査プロセスは次のように進みます。
- インスペクターは欠陥を開始します。
- 著者が欠陥に同意した場合、著者はそれを修正し、その後、検査官は欠陥を閉じます。
- 著者が欠陥に同意しない場合、彼は口頭でこの欠陥について検査官と議論します。 欠陥にコメントは追加されません。
- 著者が検査官との合意に成功した場合、同意に応じて、著者が欠陥を修正するか、検査官が欠陥を削除します。
- どちらの側も負けたくない聖戦が始まった場合、仲裁人が助けを求めて呼ばれ、誰が検査官と著者を判断します。
ここで何をしているの？
検査を実施する前に、挿入されたコードによって解決される問題を正確に理解することが不可欠です。 証拠はありますが、実際には、検査官はしばしば機械的に作業を行い、タスクを掘り下げることなく、正式な文体的要件の順守を検討します。 コードは好きなだけ「美しく」、すべてのSOLID特性を持ち、起こりうるすべてのエラーを処理できますが、タスクを解決できない場合、このコードは次のインタビューでのデモンストレーションにのみ適しています。
これはあなたの魚の魚です！
検査を行う前に、目がぼやけていない間、タスクをどのように解決するかを考えてください。 突然、あなたの決定が検査のために提供されたものよりも有意に優れていることに気付いた場合、作者に報告することをheしないでください。 彼は今それを修正しますが、それほど高価ではなく、松葉杖はまだありません。
すべてのマーカーは味と色が異なります。
欠陥を導入するときは、自分自身を管理し続け、好みに合わせて滑らないでください。 味覚は対立につながり、聖戦で時間を失い、建設的ではありません。 それを回避するのは非常に簡単です。欠陥を開始する前に、なぜこの欠陥を修正する必要があるのか、説得力のある一連の議論を準備する必要があります。 「I like it it better」または「so prettier」などの引数は有効とは見なされません。 他の引数が残っていない場合、欠陥を開始する必要はありません。コードを別の方法で作成した場合でも、コードを「作成者」バージョンのままにしておきます。
そして、彼がポケットに手g弾を持っていたら？
別のシナリオを探してください。 多くの場合、プログラマーはプログラムのメインフローに集中し、代替案を正しく処理することを忘れます。 あなたは、タスクに没頭していない人として、そのようなパンクを交換する方が簡単です。
においの利点について
すべての欠陥には、それらを検出するのに役立つ独自の匂いがあります。 アーキテクチャ上の欠陥の匂いは、マーティンファウラーの著書「リファクタリング」に詳しく説明されています。この本は、コードインスペクターが読む必要があります。 しかし、アーキテクチャ上の欠陥だけでなく、アルゴリズム上の欠陥にも注意があります。 たとえば、ロック内のマルチスレッドコードが、コールバックを作成できる別のコードにアクセスする場合、またはいくつかの同期オブジェクトが使用される場合、デッドロックの臭いがします。 アルゴリズムの欠陥の匂いは、別の記事の良いトピックです。
PS：コメントでコード検査に関するコメントを共有するための非常に大きなリクエスト。 効果的な検査のために何をお勧めしますか？