コードレビューが非常に難しい場合はどうしますか？

わかりましたので、多くのコードレビューはかなり日常的です。しかし、時折、既存の複雑で脆弱なコードに広く影響を与える変更があります。この状況では、変更の安全性、リグレッションの欠如などを検証するのにかかる時間は過剰です。おそらく、開発自体を行うのにかかった時間を超えることさえあります。

この状況で何をすべきか？マージして何も抜けないことを望みますか？（それを提唱しない！）最善の方法は、明らかな欠陥を見つけることだけが可能です（おそらく、これがコードレビューよりも目的とするべきものでしょうか？）

これは、コードレビューの一環としてテストを行う必要があるかどうかという問題ではありません。これは、特に差し迫った締め切り、利用可能な単体テストの包括的なスイートがない、または変更された断片化されたコードに対して実行できない単体テストで、説明されている状況で最良のオプションが何であるかを尋ねる質問です。

編集：私はこれまでの回答/コメントのいくつかが私のフレーズ「広範に影響する」に気づいており、おそらくそれが変更が多数のコード行を含むことを意味すると考えていました。私はこれが解釈であることを理解できますが、それは本当に私の意図ではありませんでした。「大幅な影響」とは、たとえば、コードベースの相互接続性またはノックオン効果の範囲のために、回帰の可能性が高いことを意味します。変更自体が必ずしも大きなものではありません。たとえば、開発者は、多くの低レベルルーチンへの呼び出しをカスケードする既存の高レベルルーチンを呼び出すことにより、1行でバグを修正する方法を見つけるかもしれません。バグ修正が機能したことをテストおよび検証するのは簡単です。すべてのノックオン効果の影響を（コードレビューを介して）手動で検証することは、はるかに困難です。

率直に言って、質問の前提は驚くべきものです。脆弱で複雑なコードに大きな変更があり、適切にレビューするのに十分な時間がないと仮定します。これは非常にある最後のあなたが費やすべきコード以下の見直しに時間を！この質問は、コード自体だけでなく、変更を管理する方法論にも構造的な問題があることを示しています。

それでは、この状況にどう対処するのでしょうか？そもそも入らないことから始めましょう：

• 複雑さの原因を特定し、慎重に、徹底的にレビューされた正しいリファクタリングを適用して、抽象化のレベルを上げます。このコードは、あなたのビジネスドメインについて何かを知っている新入生の新しい従業員が理解できるものでなければなりません。

• 脆弱性の原因を特定します。これは、コード自体のレビュー、コードのバグ修正の履歴の調査などによって行われます。どのサブシステムが壊れやすいかを判断し、より堅牢にします。デバッグロジックを追加します。アサーションを追加します。同じアルゴリズムの遅いが明らかに正しい実装を作成し、デバッグビルドで両方を実行し、それらが一致することを確認します。デバッグビルドでは、まれな状況をより頻繁に発生させます。（たとえば、再割り当て時に常にブロックを移動する、または常にページの最後にブロックを割り当てるメモリアロケーターなどを作成します。）コンテキストが変更されても、コードを堅牢にします。これで、脆弱なコードはもうありません。これで、バグを引き起こすのではなく、バグを見つけるコードができました。

• 自動テストのスイートを作成します。明らかに。

• 大幅な変更を加えないでください。一連の小さなターゲットを絞った変更を行います。それぞれの変更は正しいことがわかります。

しかし基本的に、あなたのシナリオは「技術的負債の穴に自分自身を掘り下げており、レビューされていない複雑な変更がそれぞれ深く掘り下げています。何をすべきか」です。その穴に自分を見つけたらどうしますか？ 掘削を停止します。借金が多すぎて、お互いのコードを確認するなどの基本的なタスクを実行できない場合、借金を増やすのをやめて、それを返済するために時間を費やす必要があります。

コードレビューの主な目標の1つは、品質を向上させ、堅牢なコードを提供することです。通常、4つの目は2よりも多くの問題を発見するため、堅牢です。また、追加のコードを書いていない校閲者は、（潜在的に間違っている）仮定に挑戦する可能性が高くなります。

ピアレビューを回避することは、コードの脆弱性を高めることにのみ貢献します。もちろん、確実で再現性のあるテストスイートでテストを強化すると、確かに品質が向上する可能性があります。しかし、それはピアレビューを補完するものであり、代替ではありません。

複雑さを理解して習得する必要があると思います。完全な査読は知識を共有し、これを達成する機会です。脆弱なコードの長所と短所をより多くの人に理解してもらうための投資は、時間の経過とともにコードを改善するのに役立ちます。

結論への引用：

「早く行きたいなら一人で行きましょう。遠くまで行きたいなら一緒に行きましょう」

レガシーソフトウェア開発の世界へようこそ。

数十万、数百万、数千万行のコードがあります。

これらのコード行は、収益の流れを生み出し、それらを置き換えることが不可能であるという点で価値があります。

あなたのビジネスモデルは、そのコードベースを活用することに基づいています。したがって、チームは小さく、コードベースは大きくなります。ユーザーに新しいバージョンのコードを購入してもらうため、または既存の顧客を満足させるために、機能を追加する必要があります。

完璧な世界では、あなたの巨大なコードベースはワズーでユニットテストされます。あなたは完璧な世界に住んでいません。

あまり完璧ではない世界では、技術的な負債を修正する予算があります。コードを単体テスト可能な部分に分解し、大規模な統合テストを行い、繰り返します。

ただし、これは新しい機能を作成せずに借金を返済しています。「アップグレードのインセンティブを生成するために既存のコードを変更しながら、既存のコードから利益を得る」というビジネスケースとは一致しません。

巨大なコードの塊を取り、より最新の技術を使用して書き換えることができます。しかし、既存のコードを操作するすべての場所で、可能性のあるブレークポイントを公開します。あなたが書き換えなかったサブシステムの癖を実際に補ったシステムのハック。常に。

できることは慎重に行動することです。実際に理解しているコードの一部を見つけることができ、その動作とシステムの他の部分との相互作用がよく理解されています。それを最新化して、単体テストを追加し、その動作をさらに明確にすることができます。

次に、主にアプリと対話するアプリの残りの部分を見つけ、それらを一度に1つずつ攻撃します。

そうすることで、顧客が喜んで支払う機能を追加して、サブシステムを改善できます。

要するに、これは可能性の技術です。ビジネスケースを提供するものを壊すことなく変更を加えることができます。

しかし、これはあなたの質問ではありません。あなたの質問は、「私は巨大で、何かを壊す可能性が高いことをしているので、ベストプラクティスに従うにはどうすればよいですか？」です。

巨大なことをするとき、それを確実にやりたいなら、書くよりもバグを追跡して修正するのに多くの努力を費やすことになります。これはソフトウェア開発の一般的なルールです。物を書くのは簡単で、完璧に動作させるのは難しいです。

おそらく、この大規模な変更が行われることを一部の利害関係者に約束したビジネスケースが頭にかかっているでしょう。いいね"。

権限と予算がある場合は、実際に変更が機能するという自信を生み出す努力を費やすか、単に変更を拒否します。これは、親切ではなく程度の問題になります。

あなたがそれほど多くのパワーを持っていないが、まだいくらか持っているなら、新しいシステムがユニットテスト可能であると主張するようにしてください。一部のサブシステムを書き換える場合、新しいサブシステムは、適切に指定された動作とそれらの周りの単体テストを備えた小さなパーツで構成されると主張します。

その後、最悪のケースがあります。あなたは借金に深く入ります。脆弱なコードを増やし、バグを増やして機能を今すぐ活用し、その結果を気にすることで、プログラムの未来を借ります。スイープベースのQAを実行して最悪の問題を見つけ、残りは無視します。これは現在、最も安価であるため、ビジネスの観点から実際に正しい答えになる場合があります。特に破産による債務の清算（コードの放棄）がテーブルにある場合、利益を生み出すために債務に行くことは有効なビジネス戦略です。

大きな問題は、会社のオーナーのインセンティブが意思決定者やプログラマーと一致しないことです。「届ける」ことには多くのプレッシャーがかかる傾向があり、ほとんど目に見えない（上司に）技術的負債を発生させることでそれを行うことは、非常に短く、時には中期的な戦略です。たとえ上司/利害関係者がすべての借金を作成しないことで最善を尽くされたとしても。

コードレビューが困難になりすぎる大きな問題を解決します。

私がこれまでに見つけたもの：

1. 単体テストスイートなし
2. より賢明なコード構造とコーディング義務の委任によって回避できる複雑なコードのマージ
3. 初歩的なアーキテクチャの明らかな欠如

1. コードレビューを送り返し、開発者に、それをより小さな増分の変更セットに分割し、より小さなコードレビューを送信するように伝えることができます。

2. コードのすべての詳細を必ずしも確認することなく、コードの匂い、パターンとアンチパターン、コードのフォーマット標準、SOLID原則などを確認できます。

3. 変更セット全体の全体的な意図を必ずしも理解しなくても、適切な入力検証、ロック/スレッド管理、未処理の例外などの詳細なレベルで戦術的なコード検査を実行できます。

4. コードの影響を受ける可能性があることがわかっているリスク領域全体の評価を提供し、開発者にこれらのリスク領域が単体テストされていることを確認するように依頼するか、自動化された単体テストを作成し、レビュー用に提出するよう依頼することもできます）。

この状況では、変更の安全性、リグレッションの欠如などを検証するのにかかる時間は過剰です。

コードレビューは、主に正確性を目的とするべきではありません。彼らは、コードの可読性、保守性、およびチーム標準への準拠を改善するためにここにいます。

コードレビュー中に正確性のバグを見つけることはそれらを行うことの良い副産物ですが、開発者はレビューのために提出する前にコードが完全に機能することを確認する必要があります（非回帰を含む）。

正確性は最初から組み込まれている必要があります。1人の開発者がそれを達成できない場合、プログラムをペアにするか、チーム全体と計画を立てますが、後から追加できるものとして扱わないでください。

コードレビューが非常に困難であると考えた場合、壊れずに変更するのはほぼ不可能であり、壊れることなく変更することはできないため、問題が発生します。しかし、問題はコードレビューにありません。脆弱なコードはユニットテストできないため、問題はユニットテストにもありません！コードが単体テスト可能であれば、それは小さな独立したユニットに分割され、それぞれをテストでき、うまく機能します。それはまさにあなたが持っていないものです！

したがって、ごみコードの山（別名「技術的負債」）があります。あなたができる最悪のことは、ごみコードのヒープを修正し始め、仕事を終了しないことです。そうすれば、ごみコードのさらに大きなヒープが得られます。そのため、最初に行うことは、経営陣に修正を求め、仕事を終わらせることです。またはあなたはしません。その場合は、触れないでください。

修正するときは、コードから1つのユニットを抽出し、明確に定義され、十分に文書化された動作をするものにし、そのユニットのユニットテストを記述し、コードをレビューして、壊れないように祈ります。そして、次のユニットで同じことを行います。

バグに遭遇したときに注意が必要です。コードのネズミの巣は、状況によっては非常に脆弱で複雑であるため、間違った動作をすることがあります。ユニットを抽出すると、残りのコードがより明確になります。（リファクタリング後、関数が「if（condition1 && condition2 && condition3）crash（）;」で開始した場合がありました。これはリファクタリング前の動作でしたが、より明確でした。奇妙で望ましくない振る舞いがはっきりとわかるので、修正できます。一方、あなたはどこなのですしなければならない既存のコードの動作を変更するので、それは）慎重に行う必要があります。

残念ながら、コードレビューの時点でこれについてできることは、コーヒーをもう1杯飲むこと以外にはあまりありません。この問題の実際の解決策は、あなたが蓄積した技術的負債に対処することです：脆弱な設計、テストの欠如。少なくとも、何らかの機能的なQAを持っていることを願っています。それがない場合は、常にいくつかの鶏の骨の上に祈りがあります。

あなたはバギー/非機能のソフトウェアに同梱されて、後でそれを修正する内容じゃない場合は、V＆V努力はすべきで開発努力よりも長く！

既存のコードが脆弱な場合、最初の質問は「変更する必要がありますか？」です。経営者は、このコードの再設計と再実装のコスト/リスクががらくたの山を修正するコスト/リスクよりも大きいかどうかを判断する必要があります。1回限りの場合は、パッチを適用する方が簡単な場合があります。将来、より多くの変更が必要になる可能性が高い場合、将来の痛みを避けるために今すぐ対応することをお勧めします。 上司に適切な情報を提供することは仕事の一部であるため、これを経営陣に提起する必要があります。 それはあなたの責任レベルを超える戦略的な決定であるため、彼らはその決定を下す必要があります。

私の経験から、問題のシステムに変更を加える前に、ユニットと統合の両方のかなりの量のテストでコードをカバーすることを強くお勧めします。最近では、その目的のために非常に多くのツールが用意されていることを覚えておく必要があります。開発している言語は関係ありません。

また、統合テストを作成するためのすべてのツールのツールがあります。はい、コンテナ、特にDockerとDocker Composeについて話します。インフラストラクチャ（データベース、mongodb、キューサーバーなど）とアプリケーションを備えた複雑なアプリケーション環境をすばやくセットアップする方法を提供します。

ツールが利用可能です、それらを使用してください！:)

なぜまだ言及されていないのかはわかりませんが、これら2つが最も重要な部分です。

• チェンジリストを複数の小さなチェンジリストに分割し、それらを次々にレビューします。*
• チェンジリストのレビューの結果、チェンジリストが適切であると判断されない場合、明らかに変更を拒否します。

*例：ライブラリAをライブラリBに置き換えます。1つのチェンジリストがライブラリBを導入し、さまざまな異なるチェンジリストがAの使用をピースごとに置き換えます（たとえば、モジュールごとに1つのチェンジリスト）。

可能な限り最善を尽くし、明らかな欠陥を見つけることのみを試みてください（おそらく、これはコードレビューが最も目指すべきものでしょうか）。

コードレビューの潜在的な価値を過小評価しないでください。彼らはバグの検出が得意です：

• テストを通して検出するのが難しいバグを見つける
• テストでは特定/修正が難しいバグを見つける

これらは他の理由でも役立ちます：

• チームのメンバーをクロストレーニングするのに役立ちます
• コードが他の品質測定基準を満たしていることを確認するのに役立ちます。たとえば、バグがないだけでなく、理解可能で保守しやすいことを確認するのに役立ちます

この状況で何をすべきか？

最良/理想的なケースでは、コード検査に合格することは、「明らかなバグがない」ことを意味するだけではありません：「明らかにバグがない」ことを意味します（もちろん、テストすることもできます）。

コード検査で新しいコードベースを検証できない場合は、より広範な「ブラックボックス」テストが必要になります。検査に合格した後にコードを本番に投入する開発サイクルに慣れているかもしれませんが、「検査に合格」できない場合は「生産に投入」できず、より長いサイクルが必要です。例えば、統合テスト、システムテスト、アルファテスト、受け入れテスト、ベータテストなど。

単体テストの包括的なスイートが利用できない、または変更された断片化されたコードに対して実行できない単体テスト

統合テスト、システムテスト、受け入れテストについてはどうですか？

とにかく、おそらくプロジェクトマネージャーとプロダクトマネージャーに、コードはほとんど間違いなくバグがあり、不明な数のバグがあることを伝える必要があります。そして、彼らは単に「期待するもの」を取得するのではなく、「検査するものを取得する」こと、つまり、コード品質はテストよりも優れていないことを確認します（コード品質はコード検査によって保証されていないため） 。

彼らはおそらくそのメッセージを顧客またはユーザーに中継する必要があるため、ベータテストを行うか（早期導入を希望する場合）、新しいバージョンがベータ版になるまで古いバージョンを使用します（そうでない場合）。

適切なコードレビューなしで、大量のコードが記述され、マージされます。うまくいく。それが「壊れたコード」ではなく、コードの匂いと呼ばれる理由があるのです。コードレビューの欠如は警告のサインであり、運命の前兆ではありません。

この問題の解決策は、StackExchangeスタイルの回答にパックできるすべてのケースに適合する1つの解決策はないということです。ソフトウェア開発コミュニティは、コードレビューが重要な「ベストプラクティス」であることを強く認識しており、この場合はスキップされています。あなたの開発は、もはや「すべてのベストプラクティスに従う」という狭いチャネルにはありません。独自の方法を見つける必要があります。

とにかく「ベストプラクティス」とは何ですか？理解すると、一般的に人々がコードを改善すると考える一連のプラクティスです。 彼らはコードを正しくしていますか？嫌です！ インターネットには、「ベストプラクティス」を順守し、それに夢中になった企業の話が散らばっています。 おそらく、「ベストプラクティス」のより良い観点は、それらがソフトウェアの世界の「火と忘れる」ソリューションであることです。 私はあなたの会社、プロジェクト、チームについて何も知りませんし、あなたを助けるものとして「ベストプラクティス」を捨てることができます。一般的な「害を与えない」アドバイスです。

この計画から明らかに外れています。幸いなことに、あなたはそれを認識しています。よくやった！彼らは知識は戦いの半分だと言います。もしそうなら、意識はそれの半分をはるかに超えています！今、解決策が必要です。あなたの説明から、あなたがいるビジネス環境は、「コードレビューを行う、それがベストプラクティスである」という退屈なアドバイスがそれを削減しない点に進化したことは明らかです。このため、ソフトウェアのベストプラクティスに関して使用する重要なルールをお勧めします。

ソフトウェア開発のベストプラクティスがビジネスニーズに勝るものはありません。

率直に言って、彼らはあなたの給料を払っています、そして、ビジネスの生存は通常、ソフトウェアの品質よりはるかに重要です。私たちはそれを認めたくありませんが、完全に書かれたソフトウェアを維持しようとする努力によって死んでいく会社の体に閉じ込められているなら、完全に書かれたソフトウェアは役に立たないのです。

それでどこに行きますか？力の軌跡をたどります。何らかの理由で、何らかのタスクについてコードレビューを受けるのは不合理であると指摘しました。私の経験では、その理由は常に一時的です。それは、常に「十分な時間がない」か「時間を過ごしている間に給料を流し続けるのに十分なお金がない」ということです。これはビジネスです。いいんだよ。それが簡単だったら、誰もがそれをするでしょう。力の痕跡を上にたどり、コードレビューがオプションではない理由を理解するのに役立つ立場にある経営陣を見つけます。言語は困難であり、多くの場合、法令が上級管理職からtrickし、歪められます。あなたの問題の解決策はその歪みに隠されているかもしれません。

これに対する答えは、必然的に、特定のケースシナリオです。コイントスが頭か尾かを予測しようとするのに似ています。ベストプラクティスでは、100回裏返すと言われており、予想は約50頭と50尾になりますが、1回裏返す時間はありません。ここで、状況の詳細が重要になります。コインは通常、約51％の時間から投げられたのと同じ向きで着陸することをご存知ですか？投げる前にコインがどの方向にあるかを観察するのに時間をかけましたか？それは違いを生む可能性があります。

使用できる一般的な解決策の1つは、コードレビュープロセスを引き出して非常に低コストの作業にする方法を見つけることです。コードレビュープロセスのコストの大部分は、あなたがそれをしている間、誰もがコードレビューに100％専念することです。これは、コードレビューが完了するとコードが祝福されるためです。おそらく、コードを別のブランチに配置し、メイントランクでの開発と並行してコードレビューを行うことができます。または、ソフトウェアがテストを行うように設定することもできます。たぶん、あなたは顧客が古いものと並行して「新しい」コードを実行し、彼らに結果を比較させることができるビジネス環境にいるでしょう。これにより、顧客は多数のユースケース作成デバイスになります。

これらすべての「多分」を実行するための鍵は、コードを簡単に断片に分割するよう努力することです。ミッションクリティカルでないプロジェクトでコードを使用することにより、正式なコードレビューに頼らずにコードの一部を「証明」できる場合があります。変更の合計が大きすぎて査読できない場合でも、変更が小さな断片である場合、これを行うのは簡単です。

一般に、プロジェクト、会社、チームに固有のソリューションを探します。一般的な答えは「ベストプラクティス」でした。あなたはそれらを使用していないので、今回はこの問題に対するよりカスタマイズされたソリューションを探す必要があります。これはビジネスです。すべてが私たちがいつも期待した方法で行った場合、IPOは値を割り当てるのがはるかに簡単になりますよね！

コードレビューの置き換えが困難な場合は、コードレビューで機能することが証明されたコードが1つもなかったことを忘れないでください。*コードレビューでは、コードに自信を持ち、修正する機会が与えられます。問題になる前に。コードレビューのこれらの貴重な製品は両方とも、他の手段で入手できます。コードレビューには、特に優れているという認識された価値があります。

*さて、ほとんど：L4マイクロカーネルは、コードが適合C ++コンパイラーでコンパイルされた場合、ドキュメントが述べているとおりに動作することを証明する自動証明システムによってしばらく前にコードレビューを受けました。

@EricLippertは、彼の優れた答えで指摘するように、この種の変更は必要以上の注意ではなく、少ないです。あなたが取り組んでいる変更がそのような変更になることを理解している場合、役立つかもしれないいくつかの戦略があります：

• バージョン管理に頻繁にコミットします。レビューはコミットごとに進行する可能性があり、コミットが小さいほど理解しやすくなります。
• 各変更の理由をできるだけ明確にコメントしてください。
• もっともらしいのであれば、この種の変更にはペアプログラミングを使用してください。2は、通常、見逃される可能性のある問題を避けるのを助けることができるのではなく、問題に目の3セットを持って、そしてあなたは、あなたがコード上の任意のコメントを向上させることができます作業中のペアを持つと思ったことは明らかだったが、あまり明確であることが判明しましたあなたが信じていたよりも、それは後で査読者を助けるでしょう。（a）開発中のエラーを削減し、（b）ドキュメントを改善すると、実際には、より多くの人が関与しているにもかかわらず、これに費やされる人件費が少なくなる可能性があります。

さらなる答えは、あなたがこのポイントに到達した方法に対処しています。それらの多くは状況を改善するためにいくつかの提案をしますが、短い答えを出すために私の答えを投げ入れたいと思います。

コードレビューが「難しすぎる」場合の対処方法

1. メインラインコードブランチに戻る
2. リファクタリングした機能のテストを作成します（例：機能テスト）
3. 合格するテストを取得する
4. 「テストが難しい」コードにテストをマージします
5. テストはまだ合格していますか？

はい

あなたの開発者は素晴らしかったです！みんなのために猫が帰ってきた！

（または、米国のテレビで「ザ・シンプソンズ」を見て育ったことがない人のために：テストに合格している場合は、違いを見ることをスキップして、開発者に変更のツアーを案内してもらってください）

番号

テストが合格するまで、リファクタリングとテストカバレッジの追加を続けます。

乗算と同様に、コードレビューはゼロに適用されるとゼロの結果を返します。このような場合、値は増加しませんが、他のほとんどの場合は増加します。

作業する必要があるコードは、さらに開発中のコードレビュープロセスの恩恵を受けるには設計が不十分です。コードレビュープロセスを使用して、リファクタリングまたは再開発します。

また、コードはまだ耐えられるが、タスクは良くないかもしれません。それは広すぎて、少しずつ行うべきでした。