通过估算您在一年内编写的代码来计算您可以节省多少时间[已关闭]

首先,所编写的代码行与实际生产效率没有很好的相关性。至少在我看来,如果你想衡量和/或估计生产率,功能点是一个更有效的衡量方法。其次,当一个指标在很大范围内变化时,平均值通常意味着很小。在这样的情况下,几何平均值通常比算术平均值更重要,但如果没有(至少)方差/标准差,它的意义仍然不大。

COCOMO II 该模型通常会产生比仅使用每单位时间的代码行要好得多的结果。至少有一个 free online implementation (编辑:查看它,现在允许基于LoC或功能点的建模)。还有一些工具,如 SoftStar 和 Function Point Modeler

18000平均每天大约36行代码。

每天只有36行代码,有什么问题?问题是调试和重写代码。

你所能做的任何自动化编码的事情都不会加快你的速度——事实上,任何你能自动化的事情都不应该被编码,因为如果你要在你的代码中自动键入某种模式,它应该被分解掉。

你可以节省时间的地方是对你如何编码更加小心。让您的项目更快地通过QA——使用更明确、类型安全的语言编写代码,代码更清晰。

永远不要自动化代码输入——如果可以的话,那就错了!

另一种思考方法是——必须调试和维护您创建的每一行代码。当您可以创建完全分解的代码时(完全分解的代码的输入不能自动进行,这在很大程度上是由定义决定的),为什么您要设法为每个人提供更多的工作呢。

Mythical Man Month . 以人-日/月/年为单位估计项目,或将代码行数作为生产力指标来计算,这将保证报告的准确性。

我相信LOC的费率在很大程度上取决于 technical debt 在这个项目中。

将代码(27KLOC)视为债务,我们的代码每月生成7%(2KLOC)的一次性代码,或每年生成88%(24KLOC)。

假设我可以继续每年生产29KLOC,并且假设维护代码的成本保持在88%/年,我个人的项目限制是33K行代码。除此之外,我将花费所有时间支付技术债务利息、编写一次性代码和生成净零LOC。