この資料は、大規模なモバイル開発チームでの数年間の仕事で得た私の経験を簡単に絞ったものです。 主にモバイル開発の経験があり、使用した例とリンクに影響を与えました。 読むのではなく見ることを好む人のために、Mobiusカンファレンスのビデオが数か月以内に表示されるはずです。ここでは、同じトピックに関するレポートを、詳細で実用的な例とともに提示します。
コードレビューの目標
まず、コード検査を実施するときに追求すべき目標の概要を説明します。 これらの目標と互いに対する優先順位によって導かれ、このまたはその実践を紹介するように勧められています。
- 集団コードの所有権
コードの各コンポーネントが複数の目を見て分析したため、バスファクターが減少しました。知識は特定の開発者に属していません。
- コードの再利用
異なる作業タスクを解決し、製品知識の異なるセットを持っている複数の人が互いのコードを見ると、特定のパターンを確認し、既製のソリューションのいずれかを再利用するか、別のライブラリーで現在のソリューションを選択することを提案できます。
- チーム共有
チームの全員が学ぶべきことがたくさんあります。 誰かがアルゴリズムが得意で、誰かがメタプログラミングが得意で、誰かがジェダイMVCです。 互いの決定を見て質問をする能力は、チーム全体の技術レベルを上げる素晴らしい方法です。
- エラー検出
最も明白な目標は、さまざまな重大度のエラーを検出することです。 これは、コードレビューに特定の時間プロセスを設定するように彼に申し出たときに、マネージャーが最初に考えることです。
- プロジェクトの一貫性
何人のプログラマーがいるのか、コードの書き方についての非常に多くの見解。 プロジェクトのファイル構造であるタブとスペース-一貫性がないと、コードの読み取りと分析のプロセスが非常に複雑になります。
さて、ここまでです。
チーム全体のコードレビュー組織モデル
チームは異なります。同じ部署のどこかに30人の人が1つのプロジェクトを開発しており、開発者だけのどこかに一度に多数のアプリケーションをサポートしています。
小さなチーム
最初のケースはおそらく最も一般的です。 これは、1人のプロジェクトに取り組んでいる、たとえば最大4人の数人のチームです。 ここで、Git Flowは通常、mightとmainで開花し、タスクは別々のブランチで互いに独立して開発され、最終的にそれらはマージして開発されます。
この場合、モデルが最も効果的に機能します。この場合、すべてのチームメンバーの承認が必要であり、ブランチをタスクとマージしてメインの作業ブランチにします。 これは、最初のセクションにリストされているレビューのすべての目的の利点を最大化するのに役立ちます。
いくつかの別々のチーム
以前の状況を拡大し、それぞれが独自のプロジェクトで動作するこのような小さなチームを含む大規模なアウトソーサーを想像します。 このような状況では、階層構造は通常複雑であり、各チームの主要な開発者の存在に加えて、新しい層、チームリーダー、またはテクニカルリードが追加されます。
基本的なアプローチは変更されていません。プロジェクトチーム全体が参加するすべての新しいタスクに対してレビューが作成されますが、技術開発の最終的な責任は開発者が負います。 さらに、リードは重要なレビューにも接続する必要があります。これにより、プロジェクトで発生している問題を最新の状態に保ち、適切なタイミングで新たな問題の解決に接続します。
別の追加アクティビティが負荷になります-開発者が他のプロジェクトに精通するとき、定期的なプロジェクト間レビューは非常に効果的であることがわかります。 これにより、誰がどのテクノロジーとアプローチが使用されているかを広く認識し、誰が何を理解しているかを知ることができます。 さまざまな方法でプロジェクト間レビューにアプローチできます-すべてのプロジェクトのエンドツーエンドのリストを保持し、最新のレビューでソートするか、各開発者に目標を設定します-他のすべてのプロジェクトを一定期間に1回検査します。 このようなレビューは主に情報提供の目的で実行されるため、通常、タスクを完了するためにサードパーティのレビュー担当者の承認は必要ありません。コードを見る人は他のチームの経験を活用します。
大きなチーム
別の状況は、1つの大きなプロジェクトに取り組んでいる大規模なチームです。 このような状況では、承認後にブランチをマージできるレビュアーの特定のしきい値を確立することは十分に正当化されます。 この値はチームの規模によって異なりますが、妥当な量は2〜4人です。
大きな問題は、特定のレビュアーの定義のままです。レビュアーはランダムに選択でき、誰が最初に応答し、特にレビューの著者によって応答されます。 このプロセスを自動化して、論争を避け、より客観的にすることができます。 例として、バージョン管理システムまたはコードレビュー用システムの履歴に従って、コードの所有者を決定します。
ローンデベロッパー
最後のケースは悲しいです。 開発者はチームで一人で作業します。 まず、コードの共同所有権などの目標はすぐになくなります-チームも所有権もありません。 他の目標もかなり退屈になりますが、それでも、サードパーティのコードを見ると、いくつかのエラーを見つけて、技術レベル全体を向上させるのに役立ちます。
この場合、開発者はオープンコミュニティに支援を求める必要があります。 3つのチャンネルをお勧めします。
- さまざまなチャットと開発者コミュニティ
私のお気に入りの2つは、 Cocoa Developers Club Slack ChatとiOS Good Talks Telegram Chatです。
- 開発者会議
たとえば、毎週モスクワで開催されているPeer Labです。
- 別の部門の同僚とのコラボレーション
別のプラットフォーム（Android、Web、またはバックエンド）向けに開発している同僚を接続できます。 しかし、注意してください-誰もが準備ができているわけではなく、開発の別の領域からの問題のコンテキストに突入したいわけではありません。
コードレビューの実践
予定された仕事
主な問題は、開発者が引き出されるストリームの状態などの概念にあります。死も同様です。 自分で状況を想像してみてください。機能の開発に真剣に取り組み、頭の中に抽象概念の宮殿を作り、突然同僚が恥ずかしそうに肩に触れて、彼のコードを見るように頼みます。 良いことは何もありません-開発者は通常、自分のタスクに参加できなくなり、レビューが偏りすぎてイライラします。
スケジュールは状況を解決します。 チームの各開発者は、レビューを視聴する期間を決定します。 チーム全体のスケジュールを1つのテーブルに保持できるため、これに基づいて、独自のレビュー担当者を選択したり、タスクをチェックする時間を計算したりできます。 たとえば、私はいつも仕事に来てすぐに、朝の1時間の時間を取っておきます-それはちょうど私が仕事のリズムに入るのを助けました。
もちろん、このメカニズムが機能しない場合もあります。一部のレビューは、可能な限り迅速に監視する必要があります。 主なことは、そのような状況の発生が習慣にならないように、そのような体制に固執することです。
建築レビュー
タスクの実装後、まったく異なる方法でそれをしなければならなかったことが判明した状況に遭遇したと確信しています。 コードレビューは、グローバルアーキテクチャについて議論するのに適した場所ではありません。 コードはすでに作成されており、タスクはほぼ完了しており、すべてをゼロから書き直すのは費用がかかりすぎます。 そのようなことは、後のことではなく、事前に議論されるべきです。
オプションとして-アーキテクチャのレビューを行い、チームの前で、言葉または図でコンポーネントを保護します。 もちろん、レビュー中に誰かに明かされることもあります。この提案が本当に価値がある場合は、問題追跡ツールに文書化し、二度と戻ってはいけません。
参加者として、プロジェクトの技術リーダー、このタスクの実装に直接関心のある開発者、およびチームの全員を引き付けることができます。
サイズ制限を確認
1つの大きなパラドックスがあります-レビュー用のコードが少ないほど、コメントが多くなります。 このルールは、ほとんどすべてのチームで変更されていません。 数行のコードでは、巨大で緑豊かな議論の存在が特徴的です。 数千行への変更の量が増えると、コメントの数は1つまたは2つのレベルまで急激に減少し、そのレベルに留まります。
この方法は非常に簡単です。一度に多くの変更をレビューに送信することはできません。 この要件は、タスクの分解に関する標準ルールと完全に相関しており、各タスクは就業日を超えてはなりません。 あまりにも多くのコードを入力すると、レビュアーはすぐに目をぼかすことになり、多くの問題は単純にスキップされます。 ちなみに、これには追加の要件も含まれます。これは、レビュー担当者が変更の実際の意味に集中できないようにするすべての情報ノイズを削除します。
自己評価
著者は自分のコードの実際のエラーのほとんどを自分で見ることができます。 したがって、同僚をレビューに結び付ける前に、自分でコードを1〜2回慎重にレビューする必要があります。 この簡単な手順により、時間と神経が大幅に節約され、同僚との関係が改善されます。
説明レビュー
継続的にコードレビューを実施する場合、変更の実際の意味に焦点を当てることは困難です。既に述べました。 レビューアが集中し続けるのを助ける別の方法は、変更の意味を詳細に記述することです。 私は通常、次のパターンに取り組んでいます：
- レビュー名
- 変更の概要
- 見るべきもの
- 関連タスクと資料
チェックリストとその自動化
チェックリストはクールです。 コードレビューに使用します。 このようなチェックリストからの質問の例：「コメントコードはありますか？」、「ビジネスロジックはテストでカバーされていますか？」、「すべてのエラーは処理されましたか？」、「行は定数に投稿されましたか？」 レビューチームでよく発生する質問をすべて覚えて、リストに追加します。
主なことは、このチェックリストを拡大させないことです。 そこにリストされている各チェックを自動化する方法を考えてください。十分な努力をすれば、ほとんどのニーズを解決できます。 この作業に役立つツールは非常に多くあります-リンター、静的アナライザー、重複コード検出器。
コードレビューパフォーマンスの測定
あらゆるプロセスの実装には、その有効性のメトリックの収集と、それらのさらなる分析が必要です。 プロセス自体はそれ自体が目的ではありません。 コードレビューも例外ではありません。コードレビューがチームの作業にどの程度役立つかを理解できることが重要です。
便利なオプションは、コードレビューを実装するときに達成したい目標から進めることです。 チートシートとして、最初のセクションで説明したものを使用できます。 このような目標を達成する効果を測定する1つの方法は、目標-質問-メトリックのアプローチを使用することです。 これは、測定する目標の決定、目標の達成レベルの理解に役立つ質問の提示、および提起された質問への回答に役立つ指標の決定の3つの段階で構成されています。 例を見てみましょう。
最初に、目的の目標を決定する必要があります。 例として-「コードの再利用レベルを上げる」。 一度に複数の目標を使用することも可能であり、必要です。そして、それらを互いに独立して測定します。
次に、目標を達成しているかどうかを理解するために答える必要がある質問を定式化します。 私たちの場合、「プロジェクトで共有ライブラリを使用しますか？」、「ビジュアルスタイルは別のコンポーネントで使用されますか？」、「どのくらいのコードが複製されますか？」です。
最後の質問は、質問に答えるのに役立つメトリックの定義です。 私たちの場合、これは共有ライブラリの数、ハードコードされたスタイルが残っている場所の数、コードの重複のレベルです。
フレームワークの使用は非常に簡単です。 プロセスの実装前に示されたメトリックを測定し、望ましい結果を決定し、月に一度または四半期ごとにこれらの測定を繰り返します。 それらを自動化できれば、さらにクールになります。 しばらくして、結果を分析し、プロセスが効果的であると判断できるほどメトリックが変化したかどうかを判断します。
このメトリックが本当に優れているのはなぜですか？ ほとんどの場合、開発者はコードの再利用の提案に対処しませんでしたが、スペースまたはタブのトピックに関するホリバー-これらのレビューではこれらの重要な指標はあまり成長しなかったでしょう、私たちは望ましい結果を達成しておらず、プロセスに問題があると理解していたでしょうあれ。
さらに、プロセスの使用中に発生した問題を示すことができるメトリックをさらに収集すると便利です。
- 検査率-レビューの速度
- 欠陥率-レビューに費やした時間あたりに発見された問題の数、
- 欠陥密度-コードの行ごとに見つかった問題の数。
レビューごとにこのようなデータを収集すると、各チームメンバーのプロセスへの関与のレベルを非常に適切に評価できます。 コードレビューを実施するための多くのシステムは、たとえばAtlassian's Crucibleなどのデータを自動的に収集します。
おわりに
序論で述べたように、この記事は私のスピーチの簡単な絞り込みであり、プロセスを自動化するためのさまざまなツール、チームの行動のルールと規範、およびコードレビューの他の側面にも触れます。 録音の外観を見逃さないために、準備ができたら間違いなく投稿するTelegramチャンネルに登録してください。 まだ質問がある場合は、6月17日土曜日に会議に参加して、非公式の設定で話し合ってください。