0

進捗状況を追跡し、全社的なベンチマークを確立しようとしています。言語ごとに異なることは理解していますが、この種の一般的なベンチマークはありますか?

開発者はおそらく、一度に大量の変更を加えて、すべてを 1 つのコミットとして行うべきではありません。しかし、おそらく行が変わるたびにコミットするべきではありません。

パフォーマンス基準について何か考えはありますか?

4

2 に答える 2

0

記述されたコードの行数に基づいてポリシーを作成することは、おそらくそれを実行するための最良の方法ではありません。

目標/スプリント/ストーリー/あなたがそれらと呼びたいものは何でも、ある種の明確に定義された計画を持っている必要があります。最も低いレベルの定義と同じ頻度でコミットすることをお勧めします。したがって、スプリントがゴールで構成され、ストーリーがスプリントで構成されている場合は、すべてのゴールをコミットします。

また、完全にテストされて機能するコードのみをコミットすることもお勧めします。特にトランク開発を行う場合、トランクは常に100％テストされ、安定している必要があります。バグのあるコードがある場合は、ローカルに保持するか、別のブランチに保存してください。

結局、X行のコードを記述したためにコミットすることを標準として使用するべきではありません。データが失われた場合に何らかの冗長性を提供しますが、重要でない進行状況マークでコミットログが乱雑になることになります。すべてのコミットにコメントが必要だと言いましたか？line＃ポリシーを使用してコメントがどのようになるか想像してみてください。

'int x=0を追加しました。ソースコードを再編成して読みやすくしました」

休暇の1週間後にプロジェクトがどのように進行したかを調べるためにログを調べていた場合、これらの役に立たないコードコミットをすべてふるいにかける必要があります。

于 2013-02-27T16:43:08.053 に答える
0

コミット数と行数を追跡することは、コードの品質を測る最も有用な指標ではないという意見には同意しますが、会社の業績を俯瞰的に見ることはできます。20 人を超える開発チームの場合、コーダーを追跡し、全員が順調にプロジェクトを進められるようにすることは、知っておくとよいことです。

さらに、1 つのバグを解決するのに丸 1 日かかることもあると主張する人もいますが、1 つの問題にとらわれているのも生産的ではありません。1 つの項目に行き詰まるよりも、前に進み続ける方がよいでしょう。誰が立ち往生しているかを知ることができれば、自分のリソースをより適切に割り当てることができ、率直に言って、何も成し遂げていない人を見つけることができます。

そのようなメトリクスを探しているなら、CodeGraphiteまたはgit-statsをお勧めします

于 2013-04-03T16:22:28.853 に答える