コード検査は良好です。 私たちはこの手法をプロジェクトで使用しましたが、それほど前ではありません-約3か月-しかし、良い結果が得られています。 開発プロセスに検査を導入すること、検査 中のドキュメント フローについて、 Harbéについては既に話しました。CodeCollaboratorツールを使用して検査プロセスを最適化する方法については話しました。 今日は、検査中に達成できた結果をまとめて表示したいと思います。 行きましょう！..
実際、多くのプラスがあるため、このトピックではいくつかの基本的なものだけに触れます。
コードを書く一般的なスタイルは確立されました 。 もちろん、検査の導入前であっても、私たちのチームは、何が良くて何が悪いのかという特定のアイデアを持っていました。 しかし、検査のおかげで、全体的なスタイルが最終的に磨かれ、実際に各開発者の「頭の中に固定され」ました。
自転車の艦隊はゆっくり成長しています 。 状況「素晴らしいソリューションを思いついた」ということはますます少なくなり、サードパーティライブラリの実績のあるソリューションを使用する機会が増えています。 「集合的知識」の興味深い効果は、あるチームメンバーが特定のライブラリについて他の人が知らない何かを知っており、その最高の品質を最適に使用することを提案したときに発生します。
全体的なコード所有権の改善 。 プロジェクトのさまざまな側面について、より活発なコミュニケーションが行われました。なぜそうなったのでしょうか。 多分あなたはこれをする必要がありますか？ その結果、システムのさまざまな部分がどのように機能するかについての理解は、開発者に均等に分散され、開発者に集中することはなくなりました。
経験と知識の交換は強化されました 。 現在、システムの他の部分に実装されている同僚の成功した方法と実践を開発で頻繁に使用しています。 私たちの意見では、そのような経験は、他の誰かのコードを読むことによってのみ伝達することができます。他の方法はありません。 どの方法も、それ自体で「経験」する必要があります。そうして初めて、「独自の」方法でマスターできます。 このような「没入」には、よく知られている主題分野の誰かのコードの良い例ほど良いものはありません。形状、円、箱のような抽象的な幾何学的な例よりもはるかに効率的です。
コードベースはより「フォロー」されています。 改善点のリストは次のとおりです。
- マジック定数はテスターによってブロックされます。
- コード重複の減少（DRY）;
- アルゴリズムがよりシンプルになりました（KISS）。
- クラスとパブリックメソッドのドキュメントが大幅に改善されました（ほぼすべてのパブリッククラスとメソッドについて、検査官はドキュメントを追加する必要があります）。
コード検査の実装の唯一の欠点は、開発時間が長くなることです。 実装の初期段階では、時間が50〜100％増加しました（場合によってはより多く発生しました）が、結果として、リポジトリ全体の品質が大幅に低下し、「スラグ」が減少しました。
現時点では、すべてのプロセスの初期デバッグ後、追加の時間コストは約20〜50％に削減されています。 主な急増は、チームを共通のコーディングスタイルに仕上げることに関連しています。 一般的なプラクティスとテクニックを採用するのに多くの時間がかかりました。 経験豊富なチームの場合、開発時間の通常の平均増加は10％です。
チェックリスト
この用語は英語の文献でよく見られ、実際には検査官のメモ、つまり検査プロセスを容易にするための管理質問のリストを意味します。
プラットフォーム、ライブラリ、および使用するアーキテクチャソリューションによって大きく異なる可能性があるため、各プロジェクトおよび各チームのチェックリストを作成することをお勧めします。 同時に、リストは徐々に進化し、プロジェクトの現在のタスクをより完全に満たすようになります。
蓄積された検査の経験をまとめると、チェックリストの作成方法を理解し始めました。 現在のリストは次のとおりです。
チェックリスト-Inspector Memo Positive Technologies
1.サブジェクトエリアの実装の正確さ。
- 機能は完全に実装されています。
- 仕様への準拠。
- 指定された定数の忠実度。
- 行われた仮定と合意の有効性。
- 正しい処理シーケンス。
2.コードの「読みやすさ」。
ここで、主要なセキュリティの質問を自問する必要があります。「必要に応じて新しい機能を追加したり、検査したコードのバグを修正したりできますか？」 答えは「はい」でなければなりません。そうでない場合、作成者はコードを変更する必要があります。
3.テストカバレッジの存在と完全性。
- すべてのパブリッククラスとメソッドがテストされます。
- 境界条件がテストされます。
- 実行の「肯定的な分岐」のテストの十分性。
- 実行の「負の分岐」のテストの十分性。
4.他の誰かのコードから貯金箱に良い慣行を追加する価値があります。
5.マルチスレッドコードの正確さ。
- 共有データへのアクセスは同期されます。
- デッドロックがありません。
- 同期には、イディオムRAIIが使用されます。
- エラーハンドラでのリソースの戻りは正しく処理されます。
- リソースリークはありません。
6.コードは、考えられるエラーを正しく処理します。
7.システムの他の部分に目に見える望ましくない副作用はありません。
8.言語構成の正確さ。
- 使用される言語とフレームワークの正しいイディオムが適用されます。
- 正しいライブラリを使用します。
- 新しく発明された「自転車」の欠如。
- コードの重複はありません。
9.すべての変数は正しい値で初期化されます。
おそらく私たちのチェックリストは、あなたのプロジェクトに合ったものを作るのに役立つでしょう。
別の非常に重要な点に注意する必要があります。 単体テストがないプロジェクトの場合、一般に、検査がコードの欠陥を防ぐ唯一の効果的な方法です。 少なくとも他に何も思い浮かぶことはありません。 したがって、プロジェクトに単体テストがない場合は、最初に検査を導入してから、単体テストを作成する練習を行う必要があります。
では、なぜ検査はとても効果的ですか？ 開発者がコードを設計または操作するときに、ある時点で開発者が「盲目」になり、特定の設計決定または特定のコードに心がしっかりと固定されることがよくあります。 検査は、より柔軟で自由な集団の心に訴える簡単な方法です-「2つの頭の方が良い」という原則に基づきます。
ご清聴ありがとうございました！ 快適な検査をお願いします:)