试图跟踪进展并建立公司范围的基准。我知道每种语言都是不同的，但是这些东西有通用的基准吗？
开发人员可能不应该一次进行大量更改并将所有更改作为一次提交来完成。但是他们可能不应该在每行更改时都提交。
对性能标准有什么想法吗？
问问题
525 次
2 回答
0
根据编写的代码行数创建策略可能不是最好的方法。
您应该有某种明确的目标/冲刺/故事/任何您想称呼它们的计划。一个好的做法是尽可能频繁地提交最低级别的定义。因此，如果 sprint 由目标组成，而故事由 sprint 组成，则承诺每个目标。
同样，只提交经过全面测试和工作的代码也是一种很好的做法。特别是如果你在做主干开发，主干应该总是 100% 测试并且稳定。如果您有错误代码，请将其保留在本地或单独的分支中。
最后，因为我写了 X 行代码而提交不应该被用作标准。虽然它确实在数据丢失的情况下提供了某种冗余，但它最终会用不重要的进度标记使你的提交日志变得混乱。我有没有提到每个提交都应该有评论？想象一下使用 line# 策略的评论会是什么样子。
'我添加了 int x=0; 并重新组织源代码，使其更具可读性'
如果我正在查看日志，试图找出我一周假期后项目的进展情况，我将不得不筛选所有那些无用的代码提交
于 2013-02-27T16:43:08.053 回答
0
虽然我同意对于某些跟踪提交和行的数量并不是质量代码最有用的指标，但它仍然可以为您提供一个很好的鸟瞰图来了解您的公司的运作方式。对于超过 20 人的开发团队来说，能够跟踪您的编码人员并确保每个人都在正轨上并推进项目是一件好事。
此外，一些人认为解决一个错误可能需要一整天的时间，但被困在一个问题上也可能是徒劳的。最好继续前进，而不是陷入单一项目。能够知道谁被卡住了，这有助于我更好地分配我的资源，并且坦率地说，这些资源根本没有完成任何事情。
如果您正在寻找这样的指标，我会推荐CodeGraphite或git-stats
于 2013-04-03T16:22:28.853 回答