コード レビューには本質的な欠陥があります。これを修正する方法は次のとおりです

最近では、プログラミングで物事を行う方法について批判的に考える必要があります。プロセスに工学的アプローチを適用する必要があります。私たちソフトウェアエンジニアは、抽象クラスと純粋関数についての議論に自信を持っています。一方で、「経営」的なことを話し合う必要があるときは逃げます。

膨大な量の欠陥がある私のお気に入りの広く普及したプログラミング プロセスは、コード レビューです。このストーリーでは、さまざまな視点からそれを見て、改善を提案します。

ソフトウェア インスペクションについて私が最初に読んだ重要な事実は、Robert Glass 著の「Facts and Fallacies of Software Engineering」という本にありました。それは次のように主張しています。

厳密な検査により、最初のテスト ケースが実行される前に、ソフトウェア製品から最大 90% のエラーを取り除くことができます。

これらの言葉が単にコード レビューに関するものかどうかは判断できませんでした。私はそれらをさまざまな種類の検査と呼ぶものとして扱いますが、これについては後で説明します。

ボブ・マーティンおじさんは、現代のレビューのルーツを発見するのを手伝ってくれました。 Michael Fagan は、1976 年に彼の記事「プログラム開発におけるエラーを減らすための設計とコードの検査」で検査のアイデアを策定しました。

そこでは、次の 3 種類の検査を発見しました。

• 設計検査、
• 単体テスト前のコード検査、
• 単体テスト後のコード検査。

Fagan の研究は、コードに対する新しいアプローチを提案するものではありませんが、既存の現象を文書化し、それを主張しています。しかし、この記事は、私が見つけた最も古い検査記録です。

コード インスペクションは、最新のコード レビューのように見えます。今日、他の種類の検査を見逃しているのはなぜですか?

今日、コード レビューしかない理由: いくつかの仮定

今日、コード インスペクションが人気を博し、他のタイプのインスペクションがほとんど存在しないのは、私たちのツールによるものです。 GitHub、BitBucket、または GitLab にはすべて組み込みのコード レビュー手段があり、Git フロー、GitHub フロー、およびその他のアプローチに自然に適合します。

設計活動に使用するツールは何ですか? UI/UX の問題ではありません。ビルドするコードの構造についてです。 CASE または UML ツールについて聞いたことがあるかもしれません。私が働いていた会社でそれらが真剣に使用されているのを見たことがなく、私は7年間働いていました.

HackerNoon では、「 UML 」検索クエリは関連する結果を 2 つだけ返します。したがって、具体的なソリューション設計プロセスがない場合、設計検査を導入する場所はありません。私が率いるチームでは、インターフェイスのデザインに Miro を使用しました。このプロセスはもっと満足のいくものだったかもしれません。他の作図ツールと同様に、問題を解決するのではなく、すぐに描画を開始します。ツールから独立することができます。これをサポートするために、「Investments Unlimited」の本から少し引用します。

...ツールでできることだけを行うと、常にツールの機能に制限されます。

既存のコードレビューにはどのような欠陥がありますか?

さまざまな観点から、その古典的な形でプロセスを見てみましょう。いずれも重大な問題を示しています。

BPMN の観点

BPMN は、ビジネス プロセス モデリングの表記法です。アクション、イベント、論理ゲートウェイ、メッセージ、およびその他の手段を使用してプロセスを記述します。フローチャートよりも説明的であるため、アルゴリズムを開発する場合にも使用することをお勧めします。レビュアー1人のコードレビュープロセスをこの表記法で表現し、分析してみましょう。テキストベースのツールを使用して、次の図を生成しました。多くの戻ってくる文字でそれに少しグリッチがあります。

すべては PR の作成から始まり、ここで特筆すべきことは何もありません。次のステップは、レビュアーに通知することです。これは、「やあ、私の PR があなたを待っています!👋」と言うために利用できるさまざまな手段を単純化したものです。ここで重要なのは、現在の活動から解放されることです。ここで、PR は不明な期間待機します。その後、レビュー担当者はタスクに飛び込んでレビューを実施します。 PR がすぐにマージされる可能性があります。ただし、逆のことが起こる可能性があります。修正が必要なコメントがいくつか表示されます。

コードの作成者はすでに次のタスクに取り組んでいる可能性があり、未知の長さの待ち時間がもう 1 つあります。また、戻ってくるには、コンテキストの復元、コメントの解釈、およびそれらの修正が必要です。

次のステップは、レビュアーへの通知です。

私たちはすでにそこに行ったことはありませんか？はい、あなたは正しいです。潜在的な無限ループの最初の反復が終了しました。はい、無限です。新しいコメントが表示される可能性は常にあります。または、待機期間の1つが永遠に続くこと。

日常業務の一部として、潜在的に無限ループが必要ですか?通常は配送が早い方が望ましいため、よくわかりません。

ソリューション ビジョンの視点

場合によっては、チームに上級開発者やアーキテクトがレビュアーとしていることがあります。彼らは、一貫したコードベースを持ち、いくつかの方法とパターンに固執し、他の方法とパターンを避けたいと考えています。彼らにはビジョンがあります。開発者にもアイデアがあります。通常、彼らは先輩の意図に気づいていません。めったに発生しない、一貫したブロードキャストまたは補助環境が必要です。次の写真を見てみましょう。

コード レビュー参加者の 2 つのビジョンがどのように異なるかがわかります。最初の繰り返しの後、調整を開始しますが、まだ先があります。レビュアーは自分のビジョンを調整し、コード作成者は提案の解釈に従って動きます。

「あなたが家を頼んだと想像してみて、驚いてください！それはあなたが期待したものではありません」という比喩を使うことができます.または、その核心を見ることができます。人に何かを達成するよう依頼したと想像してください。その後、戻ってきて結果を確認しますが、達成者が下した一連の決定に驚かされます。特定の意思決定フレームワークは必要なかったので、驚かないでください。

対人関係の視点

画像はそれ自体のために言います。仕事に何日も費やした後、同僚のエンジニアに設計上の問題を修正するよう依頼しますか?スプリントが終了し、スタンドアップでチケットが緊張の原因になったと想像してください。同僚ができるだけ早くマージするのを手伝ってください。一方、上級エンジニアが後輩のコードをレビューしている可能性もあります。彼は、最初に下した決定を修正するために長い道のりを歩むように彼に依頼することができました.しかし、これはそのようなアドバイスをする適切な時期ですか?非常に多くの決定がすでに間違った選択に基づいています。

リーン生産方式はまだプログラミングに影響を与えていません。ただし、Mary Poppendieck と Tom Poppendieck による「Lean Software Development」という本のツールは既にあります。このツールは、7 つのソフトウェア開発の無駄です。

• 部分的に完了した作業、

• 余分な機能、

• 再学習、

• ハンドオフ、

• 遅延、

• タスク切り替え、

• 欠陥。

  
  

クラシック コード レビューは 7 点中 6 点を獲得しました!🎉

1. 部分的に完了した作業。レビューのタスクは、ほとんどの場合放棄されます。私は通常、開発のこの段階を、アクションがある段階ではなく、待ち行列として扱います。レビューを作成することには、興味深い心理的効果もあります。コードレビューは「誰の責任でもない領域」であるため、上位レベルにエスカレートすることがよくあります。
2. 再学習。上の BPMN ダイアグラムで再学習を確認できます。コンテキストの復元は再学習です。
3. ハンドオフ。正直なところ、これはここで無駄ではありません。コアメカニクスです。
4. 遅延。コード レビューの設計には、前に説明した 2 種類の遅延が含まれます。さらに恐ろしいのは彼らのループです。
5. タスクの切り替え。人々はタスクを一時停止して、レビューに注意を向けます。
6. 欠陥。レビューは外観上の問題を見つけるのに役立ちますが、最も害を及ぼす設計上の欠陥を見つけることはできません。上記のようにフェローに大きな変更を依頼する動機の欠如は、プロジェクトに重大な欠陥をもたらします。

コードレビューの問題を多方面からカバーしてきました。このプロセスを修正するにはどうすればよいでしょうか?

コードレビューの再設計

このセクションでは、前のトピックと同じトピックを取り上げますが、修正の観点から説明します。

プロセス構造の修正

ここでは、レビューが完了するのを待っているコード作成者と、レビュー担当者の概要の後のペア プログラミング セッションがあります。

提案されたプロセスでは、以前のものと比較していくつかの重要な変更が見られます。

• 潜在的に無限のレビュー ループはもうありません。

• 不明な期間の単一の待機時間も処理します。

• コード作成者がコンテキストを復元したり、フィードバックを解釈したりする必要はありません。コメントはペアのリマインダーとして機能するようになりました。

  
  

このプロセスが発生するための主要な前提条件は何ですか?今、チームには追加の役割が必要です。これは、誰かが補助的な活動を行うことを意味します。たとえば、技術的負債を処理したり、優先度の低いバグを修正したりします。コード レビューがレーダーに表示されると、この人はすぐに現在のタスクを破棄し、到着した PR に飛び込みます。仕事の構造に余裕が必要な理由を疑問に思ったことがあるなら、これがその例です。全員が優先度の高い機能に専念している場合は、後で配信することになります。

視界の広がりを修正する

コードレビューでは何を議論しますか?開発中に下された決定。 1 時間前に作成したものもあれば、1 週間前に作成したものもあります。私たちの選択は互いに重なっており、独立していません。

次の数百人が立つ最初の決定の1つに疑問を呈する機会をどれほど楽しいと思いますか?あなたはその機会に不満を持っているかもしれません。

設計上の決定について話し合うのに最も適切な時期は、それらが登場するときです。もう 1 つのタイプのレビューが必要です。デザイン レビューです。問題が難しい場合は、時間をかけて計画を練り、知識のある同僚と話し合うとよいでしょう。

有名な軍事格言があります：

敵との接触に耐える戦闘計画はありません。

システムでそれを言語に翻訳すると、「最初のフィードバックが届いたときに、システムは確実にその動作を調整する必要があります」というような結果になります。プログラミングの場合、フィードバックは、設計をシステムに実装しようとするときに直面する問題になります。いくつかの決定を修正する必要があります。それらを変更し、レビュアーとのビジョンを再び分岐させる必要があります。

Adam Thornhill は、圧倒的な著書 "Software Design X-Rays" で次の方法を提案しました。

そのため、最初のコード ウォークスルーはかなり早い段階で行うことをお勧めします。機能の完成を待つのではなく、3 分の 1 の完成度で各実装を提示して議論することを習慣にします。詳細ではなく、全体的な構造、依存関係、および設計が問題のドメインとどの程度一致しているかに重点を置いてください。もちろん、3 分の 1 の完了は主観的なものですが、基本的な構造が整い、問題が十分に理解され、最初のテスト スイートが存在する時点である必要があります。この初期段階では、設計のやり直しは依然として実行可能な代替手段であり、ここで潜在的な問題を発見することには大きな利益があります。

私は自分のチームが便利な言葉を使えるように、「スケルトン レビュー」という用語を作りました。活動の背景にある考え方を反映するのに役立つことを願っています。

提案されたプロセスに対する無駄のない視点

提案されたプロセスは、発見された廃棄物を排除するか、大幅に対処します。

1. 部分的に完了した作業。コード作成者の予期時間中に別のタスクに切り替えることは許可されていないため、ユーザーにとって重要な部分的に完了したジョブはありません。優先度の低い部分的に完了したアクティビティはトレードオフです。
2. 再学習。コーディング完了からペアプログラミングまでの時間が短いため、再学習は発生しません。
3. 遅延。コード レビュー担当者の遅延を大幅に短縮し、作成者の遅延を排除しました。
4. タスクの切り替え。著者には許可されなくなり、レビュアー用に管理されます。
5. 欠陥。現在、設計上の欠陥の修正は安価になり、その中で最も重要な設計上の欠陥が修正されます。

追加の考え

1 人の作成者と 1 人のレビュアーのコード レビュー アプローチを確認しました。レビュー担当者が増えると、問題が増えます。したがって、残念ながら、最近人を追加して自分が行ったすべての決定を確認しても、すべてのバグが浅くなるわけではありません。代わりに、後でコードをマージします。

提案されたプロセスを導入しようとしたときに直面した最も困難な問題の 2 つは、次のとおりです。

開発者は、レビュー段階を完了した仕事として扱います。管理者は、日常業務に冗長性を導入することを提案すると恐怖を感じます。彼らが消防士のチームを管理していないのは素晴らしいことです.

最初の問題の解決策は、反復とスピードです。

2 番目の問題はより複雑です。ここで、Daniel Vacanti 著の「Actionable Agile Metrics for Predictability」という本を引用したいと思います。

フェデックスが採用している戦略はたくさんありますが、おそらく最も重要なのは、いつでもフェデックスが空の飛行機を空に飛ばすことです。はい、空の飛行機と言いました。そうすれば、ある場所が混雑したり、定期的に予定されている飛行機が満員だったために荷物が取り残されたりした場合に、空の飛行機が問題のある場所にリダイレクトされます (ジャスト イン タイムと言うべきです)。いつでも FedEx は「空中に予備品」を持っています!

あなたがマネージャーである場合は、次に使用率の最大化を計画するときにこれを考慮してください。

更新に満足していますか?はい、それは私たちが今持っているものよりも良く見えます.

もっとうまくやれるでしょうか？はい、できます。

目標は、必要な品質がすべてコードに含まれていることを保証できる時点で、コード レビューをなくすことです。これを実現するには、補助的な意思決定フレームワークを構築して、開発者が良いプラクティスとして扱われていることを適用し、悪いプラクティスを回避できるようにする必要があります。そのようなフレームワークは聞いたことがありませんが、IDE リンターはそれに向けた一歩です。

読んでくれてありがとう！説明されているアイデアについて議論したい場合は、コメントを書いてください。