使用 LOC 确定项目规模
需要多少行代码 (LOC) 才能被视为大型项目？ 如果只有一个人写呢？
我知道这个指标是有问题的，但对于单个开发人员来说，1k 和 10k LOC 之间存在显着差异。 我通常使用空间来提高可读性，尤其是 SQL 语句，并且出于维护目的，我尝试减少 LOC 数量，以遵循尽可能多的最佳实践。
例如，我对今天修改的代码创建了一个统一的 diff，它超过 1k LOC（包括注释和空行）。 “修改后的 LOC”是一个更好的指标吗？ 我有 ~2k LOC，所以我修改了 1k 很令人惊讶。 我猜重写既算作删除又算作添加，这会使统计数据加倍。
How many lines of code (LOC) does it take to be considered a large project? How about for just one person writing it?
I know this metric is questionable, but there is a significant difference, for a single developer, between 1k and 10k LOC. I typically use space for readability, especially for SQL statements, and I try to reduce the amount of LOC for maintenance purpose to follow as many best practice as i can.
For example, I created a unified diff of the code I modified today, and it was over 1k LOC (including comments and blank lines). Is "modified LOC" a better metric? I have ~2k LOC, so it's surprising I modified 1k. I guess rewriting counts as both a deletion and addition which doubles the stats.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一个稍微没那么无用的指标 - 编译时间。
如果您的项目编译时间超过...比如说 30 分钟，那么它就很大了:)
A slightly less useless metric - time of compilation.
If your project takes more than... say, 30 minutes to compile, it's large :)
使用 Steve Yegge 作为量表上限的基准，假设 500k 行代码 是（超过？）单个开发人员可以维护的最大值。
但更严重的是； 我认为一旦达到 100k LOC，您可能会想要在扩展代码之前开始寻找重构。
但请注意，解决此限制的一种方法显然是对代码进行更多划分。 如果所有代码的总和由两个或三个大型库和一个应用程序组成，那么组合起来很可能比您作为单个代码库维护的要多，但只要每个库都很好地独立，您就可以不会超出理解解决方案每个部分的能力。
Using Steve Yegge as the benchmark at the upper range of the scale, let's say that 500k lines of code is (over?) the maximum a single developer can maintain.
More seriously though; I think once you hit 100k LOC you are probably going to want to start looking for re-factorings before extensions to the code.
Note however that one way around this limit is obviously to compartmentalise the code more. If the sum-total of all code consists of two or three large libraries and an application, then combined this may well be more than you could maintain as a single code-base, but as long as each library is nicely self-contained you aren't going to exceed the capacity to understand each part of the solution.
也许另一个测量方法是 COCOMO 测量 - 尽管它可能和 LOC 一样无用。
单个开发人员只能做有机项目——具有“良好”经验的“小”团队，满足“不太严格”的要求。
在这种情况下，以人月为单位应用的预算计算如下：
这表示，1kLOC 将需要 2.52 人月。 您可以根据产品、硬件、人员和项目属性，使用多个因素来优化它。
但我们现在所做的只是将 LOC 预测为时间测量。 在这里，您必须再次决定 2 个月还是 20 个月的项目是否被视为大型项目。
但正如您所说，LOC 可能不是正确的衡量标准。 关键词：软件指标、功能点、基于证据的调度、规划博弈。
Maybe another measurement for this would be the COCOMO measure - even though it is probably as useless as LOC.
A single developer could only do organic projects - "small" teams with "good" experience working with "less than rigid" requirements.
In this case, efford applied in man months are calculated as
This said, 1kLOC would need 2.52 man month. You can use several factors to refine that, based on product, hardware, personel, and project attributes.
But all we have done now is projected LOC to a time measurement. Here you again have to decide whether a 2-month or 20-month project is considered large.
But as you said, LOC probably is not the right measure to use. Keywords: software metrics, function points, evidence based scheduling, the planing game.
在我看来，这还取决于代码的设计 - 我曾经参与过 1-10K loc 范围的项目，但设计得很糟糕，感觉就像一个非常大的项目。
但 LOC 真的是一个有趣的代码衡量标准吗？ ;-)
In my opinion it also depends on the design of your code - i've worked on projects in the 1-10K loc range, that was so poorly designed, that it felt like a really large project.
But is LOC really an interesting meassure for code? ;-)