プロジェクトにコード検査を導入するプロセスに取り組み始めたとき、このプロセスをゼロから整理する上で賢明な資料が不足していることに不愉快な驚きを覚えました。 別の非常に不十分な照明の側面は、検査プロセスのスケールアップです。
このギャップを埋めて、この素晴らしいプラクティスをチームに導入した経験を共有したいと思います。 コメントの建設的な批判は大歓迎です。
それでは始めましょう。
なぜこれだけなのですか？
まず最初に、コードを調べて達成したい目標を定義しましょう。 もちろん、これらの目標はプロジェクトごとおよびプロジェクトチームごとに異なります。 それらは、プロジェクトの性質（1回または長期）、プロジェクトの存続期間（短期または長期の保守サイクル）などの影響を受けます。私たちにとって、次の目標が最も重要です。
- ソフトウェア品質管理部門の同僚や会社の顧客が発見した欠陥の数を減らす。
- コードの品質を改善することにより、アプリケーションのメンテナンスを安くします。
- 単体テストの品質と量を保証します。
- コード共有の提供。
- チーム内での経験の交換を保証します。
- コードの記述スタイルの改善。 物議を醸すスタイルの側面を特定し、チーム内で議論する
誰が検査に関与していますか？
トピックの後半で使用するいくつかの用語を明確にしましょう。
著者はコード開発者です。
インスペクター（レビューアー）-プロジェクトブランチの特定のモジュールまたはパスに該当するすべての変更を担当する開発者。
オブザーバー（オブザーバー）-専門家として関与する開発者。
いつ検査しますか？
ここで、開発プロセス中のコード検査の場所、検査の時間を決定します。リポジトリにコードを追加する前（コミット前）または追加した後（コミット後）です。 コード検査を実装するプロセスは多くの場合苦痛を伴うため、選択は慎重です。 「個人」コードの所有権が普及しているチーム（およびこれは常に発生しているチーム）が最も危険にさらされています。 そのため、最初に避けられない「ホリバー」が原因でプロジェクトの期限に間に合わないリスクを最小限に抑えるために、最初にコミット後の検査の実践を導入するのが賢明です。 プロジェクトチームメンバーが必要な経験を積むと、コミット前検査に進むことができます。
私たち自身にとっては、最初にコミット前検査を選択したと言わなければなりません。
どのように機能しますか？
検査を作成するときに、開発者は次の参加者を追加します。
- グループの検査官。
- チームリーダー。
チームリーダーは、モジュールが変更されたチームリーダーとしてオブザーバーを任命します。
チームリーダーは、チームのインスペクターを指定します。
このアプローチにより、検査参加者の分散型の任命が保証され、垂直方向（階層内）と水平方向（プロジェクトチーム数の増加）の両方に完全に対応します。
実装には何が必要ですか？
コード検査の実装を成功させるには、いくつかの条件を満たす必要があります。
- リポジトリに入る前に、コードに精通している少なくとも1人がコードを表示する必要があります。
- 開発チームは、他のグループがプロジェクトに加えている変更を常に認識しています。
- グループのリーダーは、グループが行うすべてのことを認識しており、グループ内のコードについて十分なアイデアを得ています。
- グループ内では、開発者は同僚が書いたコードをよく理解しています。
これらの条件が満たされると、プロジェクト参加者による適切なレベルの共通コード所有権が達成されます。
おそらくそれだけでしょう:)
コード検査のトピックと経験の説明がhabrasocietyに興味がある場合は、SmartCear CodeCollaboratorを使用して検査プロセスを自動化するために次の記事のいずれかを取り上げます。
よろしくお願いします！