将多少行代码（LOC）视为大型项目？只有一个人写这个怎么样？
我知道这个指标值得怀疑，但对于单个开发人员来说，在1k到10k LOC之间存在显着差异。我通常使用空间来提高可读性，特别是对于SQL语句，我尝试减少LOC的数量以便维护，以尽可能多地遵循最佳实践。
例如，我创建了我今天修改的代码的统一差异，它超过1k LOC（包括注释和空行）。 “修改过的LOC”是一个更好的指标吗？我有~2k LOC，所以我修改了1k令人惊讶。我想重写计算为删除和添加都会使统计数据翻倍。
答案 0 :(得分：3)
略微无用的指标 - 编译时间 如果你的项目需要超过......比如说，30分钟就可以编译，那就太大了：）
答案 1 :(得分：2)
在比例的上限范围内使用Steve Yegge作为基准，让我们说500k lines of code是（超过？）单个开发人员可以维持的最大值。
但更严重;我想一旦你达到100k LOC，你可能会想要在扩展代码之前开始寻找重新考虑因素。
但请注意，绕过此限制的一种方法显然是更多地划分代码。如果所有代码的总和由两个或三个大型库和一个应用程序组成，那么组合这可能比你可以维护的单个代码库更多，但只要每个库都是很好的自包含你就不是不会超出理解解决方案各个部分的能力。
答案 2 :(得分：2)
也许另一种测量方法是COCOMO测量 - 即使它可能与LOC一样无用。
单个开发人员只能做有机项目 - “小”团队具有“良好”经验，处理“不太严格”的要求。
在这种情况下，在人月中应用的efford计算为
2.4 * (kLOC)^1.05
这就是说，1kLOC需要2.52个月。您可以根据产品，硬件，人员和项目属性使用多个因素来优化它。
但我们现在所做的只是将LOC投射到时间测量上。在这里，您必须再次决定2个月或20个月的项目是否被视为大型项目。
但正如你所说，LOC可能不适合使用。关键词：软件度量，功能点，基于证据的调度，计划游戏。
答案 3 :(得分：1)
在我看来，它还取决于你的代码的设计 - 我曾经在1-10K loc系列的项目上工作，设计非常糟糕，感觉就像一个非常大的项目。
但是LOC真的是一个有趣的代码安慰吗？ ;-)