3

あなたの「エンタープライズ」作業環境では、エンジニアはコード検査と単体テストの実行についてどのように責任を負っていますか? ソフトウェアの品質を確保するために、どのようなプロセス (正式な方法論またはカスタム プロセス) に従っていますか? 成果物に開発者の「サインオフ」シートを実装したことがありますか?

前もって感謝します!

更新: Code Collaborator を使用して検査を行っていることを忘れていました。問題は、人々に「理解」してもらい、中核となる人々のグループの外でそれを行うことに同意してもらうことです。以下で stalbot が指摘しているように、これは文化の変化ですが、問題は、レビューや単体テストなどの品質イニシアチブを促進するために文化をどのように変えるかということです。

4

8 に答える 8

5
于 2008-11-06T16:15:32.950 に答える
3

チェックインの前に、すべての変更リストがレビューされることを確認したい場合は、ソース管理ツールで未レビューのチェックインを拒否することができます。たとえば、チェックイン コメントに "CodeReview: " がない場合、トリガーはチェックインを拒否できます。人々はまだ嘘をつくことができますが、責任を問われる可能性もあります.

チェックイン後にすべての変更リストを確実にレビューしたい場合は、Code Collaborator がソース管理システムとうまく連携し、各チェックイン (プッシュまたはプルなど、機能するものは何でも) 後に自動的にレビュー タスクを作成するかどうかを確認できます。その後、Code Collaborator の「礼儀正しい」機能を使用して、レビューが実際に行われるようにします。

すべてのチェックインではなく、一部のチェックインのみをレビューしてもらいたい場合は、頑張ってください。

于 2008-11-06T21:31:41.300 に答える
2

かなりクールなセットアップがあります。コーダーは、チェックインの前にコードをテストして、ビルドが壊れないことを確認し、意味があるが高いカバレッジは必要ないテストを作成することが期待されています。

複雑なメソッドはコメントする必要があります。

フェーズの終わりに、コードはチーム全体によってレビューされます。

于 2008-11-06T15:08:16.160 に答える
2

ペアプログラミング。作業項目には、共同作業者 (作業のためにペアになった人) の必須フィールドがあります。

于 2008-11-17T00:30:57.467 に答える
1

私たちは ITIL の概念に大きく依存しています。ITIL が提供するフル スケールの ITSM は必要ありませんが、特に変更管理とリリース管理の分野で、ITIL のベスト プラクティスの一部を利用したプロセスを実装しました。

コード レビューは、RM 戦略の一部です。コードの変更または新しい部分が RM プロセスを通過すると、多くの目がそれを見ます。最終的には、リリース マネージャーが承認またはやり直しを決定し、そのすべてが文書化されます (TFS と SharePoint を使用しています)。正式なコード レビューは、リリース マネージャーと彼が選んだ技術チームによって行われます。リリース候補の主な開発者は、標準への準拠、機能、および完成したテスト計画の検証について責任を負います。品質基準が満たされていない場合、成果物は却下され、プロジェクト スケジュールが更新されてやり直しが反映されます。

はい、これはすべて非常に重いです。私は政府で働いており、従わなければならない複雑な法律があります。具体的には、税や ADA コンプライアンスなどの分野です。

于 2008-11-06T15:07:08.660 に答える
0

3つの基本的なルールを使用します

1)単体テストが存在しない場合、開発者はコードのバグを修正する責任があります。テストがある場合、テストを破った人がそれを修正する責任があります。

2)コードレビュー。防御と非難のリダイレクトの2つが最も一般的であるという、良い警告サインであるコードレビューの匂いがいくつかあります。

3)電子メールコード、JAR、または構成ファイルはありません。すべてがscmにあります。

于 2008-11-06T21:11:48.890 に答える
0

文化を変えることは大変なことです。それでも変える方法はあります。

  1. コード レビューとコード レビュー ツールの重要性について認識を高めます。これは、トレーニング セッションを使用して行うことができます。

  2. 人々をやる気にさせる : コード レビューに報酬を与える。

  3. プロセスの変更 : コード レビューが適切に行われるようにします。これは、チェックリストとリリース プロセスの一部を使用して実行できます。

  4. 完全に変えようとしないでください。ゆっくりと新しい変更を導入します。コード レビュー プロセスの変更を観察し、議論するための小グループを作成します。

  5. 問題を作るのではなく、解決策を提供します。プロセスはオーバーヘッドであってはなりません。それは自動的に来ます。プロセスに関連する人々の問題に解決策を提供します。
于 2010-10-22T07:16:02.857 に答える
0

文化を創造するには、まず自分の基準と価値観を定義し、何よりもそれらを周知させます。

次に、それらを信じる人、またはそれらに適応できる人を雇います。あなたの会社の価値観とまったく関係のない人を雇ってはいけません。

これらの価値を尊重し、改善を示す人が「報われ」、「適切に」認識され、モデルとして見られるようにしてください。多くの人にとって、お金がすべてではないことを忘れないでください。

責任を果たさない人に対しては、ためらわずに適切な措置を講じますが、そのことを知っておいてください。そして彼らに彼らの行為に責任を負わせてください。人々が新しい責任に慣れるのを許してください。

于 2010-10-16T10:44:58.917 に答える