是什么使项目变大？[关闭]

出于好奇，小型，中型和大型项目有什么区别？它是通过代码行或复杂性来衡量的还是什么？

我正在建立一个物物交换系统，到目前为止，大约有1000行代码用于登录/注册。即使有很多LOC，我也不会认为这是一个大项目，因为它不是那么复杂，尽管这是我的第一个项目，所以我不确定。如何测量？

复杂。

复杂程度越高，学习项目中所有内容的难度就越大。

我大致如何看待事情-请记住，这或多或少是任意的。项目的“大小”由其他因素组成，例如复杂性，代码的源代码行，功能/业务价值的数量等。非常小的产品可以交付大量的价值，等等。

• 2m + sloc是一个大型项目。这些通常是如此复杂，以至于只有很少一部分人能熟练地使用整个系统。相反，责任倾向于按照代码的结构模块化。这些项目通常提供巨大的业务价值，并且可能是关键任务。他们有时还承受着沉重的技术债务和其他遗留问题的压力。

• 100k-2m sloc是一个中型项目。这是我的中间立场：该项目非常复杂，需要一些专家知识，并且可能已经累积了一定程度的技术债务；它也可能带来一定程度的商业价值。

• 10k-100k是一个很小的项目，但又不能太小而没有足够的复杂性，您需要专家考虑；如果您是开源的，请考虑让您信任的人来审查您的提交。

• 少于1万个sloc的东西确实很小。这并不意味着它根本无法提供任何价值，而且许多非常有趣的项目都留下了很小的烙印（例如Camping，其来源约为2 kb（！））。非专家通常可以引起对价值的关注-修正错误并添加功能-无需对域有太多了解。

项目的规模由不可维护程度来衡量。

可以通过几种方式估算复杂度：

1. 预算。例如，预算为10,000,000美元以上的项目可能与10,000美元以下的项目有很大不同。这可能包括人工，软件，硬件和执行项目时产生的其他成本。
2. 完成项目所需的工作时间。会花费一百万小时还是其他时间？这也可以看作是时间因素，其中一些项目可能要花几年的时间，而有些项目则需要不到一周的时间。请注意，人员时间可能会像有人认为的那样令人误解，因为员工人数会增加一倍，因此该项目的工作量是工作量的两倍，然后将进度表切成两半，这在我看来很少起作用。
3. 使用该项目正在构建的硬件，其他系统和人员的数量。如果将某些东西绑定到101个系统中，那么它可能会更加复杂，如果它独立存在并且不绑定任何其他东西。

虽然听起来听起来是衡量此需求的一种不错的方法，但是在我相信采用非瀑布方法论的情况下，完成一个项目通常会发现更多的需求。

一个项目的规模最好用系统的需求数量来衡量，而这些需求无法进一步降低。

当然，更多的需求通常意味着更多的复杂性，但并非总是如此。

我通过将整个项目看成一个单一的整体图有多么困难来衡量一个项目的规模。例如，对于正在研究的机器学习问题，我有一个探索性/原型代码库。它只有5k行代码，但是感觉就像是一个巨大的项目。有大量的配置选项以不可预测的方式交互。您可以在代码库中的某个地方找到几乎已知的每种设计模式来管理所有这些复杂性。设计通常不是最理想的，因为事物是通过进化而增长的，并且没有得到应有的重构。我是在此代码库上工作的唯一人，但是我常常对事物之间的交互方式感到惊讶。

另一方面，我的一个爱好项目的代码大约是其3-4倍，但感觉却要小得多，因为它基本上是一个相互正交的数学函数库。事情不会以复杂的方式进行交互，因此孤立地理解每个功能是很不错的。看到一张大图很容易，因为没有太多可看的。

任意答案：该项目有多大，您希望从一开始就使用事件源和SOA完成多少工作。或者该系统的作者已经阅读了Evan的书“ DDD：解决软件核心中的复杂性”;）

共性与范围

我认为复杂性和范围决定了项目的规模。但是，有几种无形资产也会影响项目的规模。

要求

我面临的最大失败是缺乏需求。在我的特殊情况下，销售经理正在确定需求。他的重点是销售...得得到销售。在他看来，客户的要求似乎并不那么复杂，因为我们已经建立了类似的东西。含糊的要求导致工作价格低估，并超出了期望值。

缺乏CCMU

CCMU是我所说的“ Coo Ca Moo ”（清除完全的相互理解）。您需要与客户建立CCMU。

如果您的小型项目的CCMU较差，那么您可以完成2,3,4或更多次该项目。这样，一个简单的20个小时的工作就变成了一个60个小时的项目，需要压力很大的员工和非常不满意的客户。

范围蠕变

这种情况比您想像的更多。客户认为，既然您已经在进行A，B和C，添加D甚至F就不那么困难。如果不检查此行为，它也可以将一个小项目变成一个中等大小的项目。根据销售经理出售工作的方式，这些范围预期对客户可能看起来“免费”。

奇怪的是，阅读很多这些答案后，我发现我对项目的规模有很大的不同。也许这是我在一家大公司中工作，但我倾向于将项目的规模视为对其客户可见性/期望程度的更大程度（取决于您的工作领域，这些人可以是同事或实际的付费客户）。

复杂性是正确的答案，但是如何估算呢？

因素有：

1. 扩展点数
2. 模块层数（功能，类，类系统，库，共享库，应用程序，网络应用程序等）
3. 依赖项计数（包括平台）
4. 具有相互依赖性计数。
5. 必要的非代码资源（包括图形/艺术，驾驶脚本（如关卡设计脚本）以及完成应用程序版本所需的其他资源）。

您拥有的越多，项目就越复杂。

众所周知，LOC 在很多测量中都不准确，但我认为您正在尝试测量的东西实际上是没有准确的测量方法的。也许替代方法可能是循环复杂性。

但最终，我认为项目的“规模”很难量化。这几乎就像问您如何确定狗是否大。不仅有多种测量方法（质量，体积等），而且我个人认为它不是很有用。现实情况是，我的标准可能类似于“如果我在黑暗的小巷中看到它，我有多可能从这只狗身上逃跑？”

出于记录，我通常不会认为1k行代码太多。这将是相当大的代码块，但是在宏大的方案中并不会那么多。当然，我想这确实取决于语言。例如，1K行代码是多在像C语言比在像Pyhon语言更少的代码。