コードの品質を確認する
2つのコードベースの品質レビューを依頼されました。私はそのようなことをしたことがなく、それを実行して報告する方法についてアドバイスが必要です。
背景
コードのプロバイダーは2つあります。1つはVBで、もう1つはC（ISO 9899：1999（C99））です。これら2つのプログラムは一緒にうまく機能しません。もちろん、2つのサプライヤーはしたがって、私は独立した人として両方のコードをレビューし、包括的なレベルでコードの品質をレビューして、問題がどこにある可能性が最も高いかを見つけます。問題を見つけるのではなく、単に品質と、コードの管理と理解がいかに簡単か。
編集：問題の内容に関する情報をまだ受け取っていません。品質の観点からコードを調べると言われました。それほど多くはありません。彼らがこの決定を下した理由の背景はわかりません。
その「背景」を頭から落としてください-それはあなたが持っている割り当てには役に立ちません。
両方のプログラムについて、同じことを行います。コードをファイルごとに、行ごとに読み取ります。気分が悪い場合は、問題のリストに追加してください。誤植、重複またはデッドコード、理解が難しいこと、IDE /コンパイラの警告など。自由形式のコメントを使用してください。現時点では構造について心配する必要はありません。注意を引くものをリストに記入してください。
リストを確認したら、それを確認します。メモが正しいかどうかを再確認します。気づいた問題に何らかの構造/グループ化が見られる場合は、リストを再配置して合わせてください。それについてあなたに尋ねた人にリストを提出してください。
過去のプロジェクトで、私の同僚は、メモリが機能する場合は5または10 KのLOCを維持するために割り当てられたコンポーネントを確認するように言われました。彼はそれに目を通し、180アイテムのリストを提出しました（18気づいた問題）。 1週間後、経営陣は私にそのコンポーネントをやり直すための全力と無制限の時間を与えました。私は約1か月を費やし、その男がリストしたすべての項目に対処しました。レビューの結果、5年間の集中的な使用が行われ、このコンポーネントに対して2つまたは3つのバグが提出されました。
私にとって、あなたの質問は"非難ゲーム"のように聞こえます。
問題は本当に2つのコードプロバイダーのコード品質ですか、それとも2つの間のインターフェイスの説明についてですか？
書面による要件または単体テストは、将来この種の問題を解決するのに役立つ可能性があります。
- 有効な入力/出力とは何ですか？
- エラー管理はどのように行うべきですか？
実際のバグを見つけることではなく、単に品質を測定することがタスクの場合は、それを測定する方法が必要になります。
Cではこれは非常に簡単です。コードが既知のコーディング標準にどれだけ適合しているかを簡単に確認できます。最もよく知られ、認められている機関はおそらく MISRA-C ですが、 CERT C もあります。どちらも使用できますが、前者は高整合性システムに、後者はPCプログラミングに適しています。どちらの基準も、危険な行為の禁止に重点を置いています。
このようなコーディング標準から、レビューの一部となるいくつかのルールを選択できます。たとえば、未定義の動作への依存を禁止するすべてのMISRA-Cルールを含めることは、理にかなっています。その結果、品質を測定する手段として使用できるいくつかのルールが得られます。
次に、実際のレビューが行われます。確かに手動で行う必要がありますが、専門的な方法は静的解析ツールも使用することです。 MISRA-Cをサポートするものも多く、CERT Cをサポートするものもいくつかあります。より洗練されたツールは、データ異常、バッファオーバーラン、不必要な複雑さなど、その他のさまざまなバグも見つけることができます。また、コードカバレッジを実行して、実行されないコードがプログラムにあるかどうかを確認することもできます。
VBに関しては、それははるかに困難です。あなたが引用できる広く認識された権威はおそらくありませんが、おそらく使用できるコーディング標準があるかもしれませんが、多分 this one ？ （Googleで見つけた、私はそれを使用したことがない）。マイクロソフトが引用する最高の権威であり、VBの記述方法については漠然とした浅いガイドラインがあるようですが、Cコーディング標準ほどプロフェッショナルではありません。
（コードに関しては、ただ飛び込みます-それはそれを学ぶ唯一の方法です）。
私は、2つの当事者が連携するためのAPI（基本的に契約）を検討することをお勧めします。それらがAPIに準拠している場合、コードは一緒に動作するはずです。
Webサービスの世界でWSDLを使用する方法とよく似ています。
可能であれば、APIにテストスイートを用意して、その動作を確認してください。それ以外の場合は、非難タグゲームを何年もプレイできます。
あなたにとって本当に必要なもののように聞こえるのは、toアプリケーションの間に座って、それらが互いにやり取りしているメッセージをスパイするためのいくつかのインストゥルメンテーションです（それらが通信する方法に応じて、これはあなたが自分自身を書くために必要なものか、wiresharkのようなすでに利用可能なものかもしれません）
メッセージを確認したら、インターフェースの仕様と比較して、誰が正しいか、誰が間違っているかを判断できます。もちろん、仕様が不明確な場合は、仕様を修正する（またはコンポーネントの1つを変更すると追加のコストが発生する）か、スパイツールを互換性シムに変換する必要があります。
彼らのコードをレビューすることには確かにそのメリットがないわけではありませんが、インターフェースの問題を追跡するのには役立ちません（特に仕様が間違っている場合）。
関係するすべての関係者に受け入れられる方法でコードレビューを行うのは困難です。良いプロセスは客観的な基準と同様に役立ちます。これにより、レビューが検証可能で繰り返し可能なものになります。また、分析と技術的事実の取得も1つです。別の見方、立場、感情の管理など、問題の状況を解決する方法で報告することも別です。
視覚的な検査と、コードに問題があるすべてのリストを作成することは、通常、時間と予算の制約がないか、コードベースが非常に小さい場合にのみ有効です。そうしないと、検査自体が作業量が多すぎたり、提案する修正に時間がかかりすぎて実行できない場合があります。推奨事項を提示するときは、このことを覚えておいてください。
クライアントはコードレビューのためにどのような調査質問をしていて、その結果はどうなりますか？
6面サイコロを振る。 1-3はVBコード、4-6はCコードです。2か月の休暇を取り、戻った後にどのコードが悪いかを全員に知らせてください。あなたはそれが現れるでしょう。
さらに良いことに、コードをレビューするつもりであることを伝えます。両方のコードセットを一緒に機能させるための修正を行います。
割り当てられている時間はどれくらいですか-確認しているアプリの開発時間の大まかな順序が20％から50％でない限り、あなたは時間を無駄にして、誰かにそれについて気分を害させるような政治運動を行っています。
（私たちが知る限りでは）ソフトウェアの品質を決定するための不正確な方法であり、厳格な調査に耐えることはほとんどありません。報告の内容を慎重に検討してください。最終的に証人ボックスで弁護しなければならない場合があります。この論争はどこまで進んでいて、どれだけのお金がかかっているのか、当事者は解決策や非難を求めていますか？
あなたがプログラマーであり、プログラミング専門のフォレンジックアナリストではない場合（この場合、公開フォーラムでこの質問をしなかったことがわかるでしょう）、もし私があなただったら、私はできる限り強力な方法で割り当てを拒否します。あなたは転倒する準備ができています-あなたの意見だけでソフトウェアベンダーを互いに競い合ってください.....それらのベンダーの1人がこのQ＆Aを見つけた場合、それはどのように見えるのでしょうか....
レポートを完了する前に、それが何に使用されるのかを確認する必要があります。 「コードはくだらない」などの絶対的な表現ではなく、「出現する」や「信じる」などの表現で表現されていることを確認してください。アサーションを行う必要がある場合-公開され広く受け入れられている標準への参照が必要になります。例えば「コードがMISRA Cのガイドラインで指定された基準を満たしていない」というのは事実ですが、それらのガイドラインを満たしている必要があると述べることはできません（契約がそう述べているか、そうであると彼らが主張した場合を除きます）。
それは本当に彼らが何を望んでいるか、そしてコードの品質によって何を意味するかにかかっています。
しかし、一般的に、あなたの目標は、次の点でコードがどのように運ばれるかについてレビューを与えることです。
- 保守性と拡張性の容易さ、
- 安定性とセキュリティ、
- パフォーマンス。
ほとんどのメトリックはこれらのポルトマントウカテゴリに分類されます（実際には、一般的にはパフォーマンスも考慮していません。ほとんどの場合、安定性と保守性の点で良いスコアのボーナス副作用と見なしています。適切なコード設計）。
一部のコードベースで直接適用および測定できるコード認定など、探すべき絶対的なものはいくつかありますが、必ずしもこれらのカテゴリの詳細なレビューを提供するわけではありません。
私はあなたに助言します：
- IDEを開き、コードの閲覧を開始します。
- 実行時に何が起こるかを知るためにブレークポイントを置き、興味深い横断的関心事と主要なボトルネックを特定し、
- コードチェッカーを見つけて違反を報告し、コードベースの「ホットスポット」を特定します。
- アプリケーションのプロファイリングを行ってボトルネックを特定し、
- 使用したツールとシステムのビルドも確認します（直接尋ねたものではありませんが、いくつかはそれから推測でき、他の問題を特定するのに役立ちます）。
- 特定したメトリックの改善を開始するためのプロセスと実践を定義し、それがコードベース、開発者、および最終製品にどのように役立つかを説明します。
あなたはvbのタグを付けたのを知っていますが、例を挙げれば、 ソナー は良いです 例 いくつかのマーカーをビジネスコストに（多少正確に）リンクすることにより、技術的な観点からの、またはビジネスの観点からのコード品質から、多くの点でコードベースの品質を定量化するのに非常に役立つツール。お住まいの地域で、同等のツール、または同様の結果を達成できるツールのセットを見つけたいと考えています。ソナーには必要に応じてCプラグインがあり、Visual StudioにはVB用のいくつかの優れたコード品質アナライザーがビルトインまたはエクスターナルにあると確信しています