代码库何时变得庞大且笨重？

Question

你什么时候开始认为代码库太大而且笨重？

Answer 1

- 当您的大量编码时间用于“我在哪里放置此代码？”

- 关于副作用的推理开始变得非常困难。

- 当有大量代码只是“在那里”时，没有人知道它的作用或者它是否仍在运行但是它太可怕了删除

- 当很多团队成员花费大量时间来追逐数据中某些空字符串引起的间歇性错误时，这些错误是不期望的，或者您认为通常会在编写良好的应用程序中捕获的内容，在某些边缘情况下

- 当考虑如何实现新功能时，“完全重写”开始看起来像一个很好的答案

- 当你害怕看到你需要维护的一堆代码时，并希望你能找到工作建立一些干净而合乎逻辑的东西而不是垃圾桶潜水通过其他人组织糟糕的思维的碎屑

Answer 2

当它超过100行时。玩笑。这可能是最难回答的问题，因为它非常个性化。

但是，如果您很好地构建应用程序并使用不同的层，即接口，数据，服务和前端，您将自动获得一个漂亮的“基础”结构。然后你可以将每一层分成不同的类，然后在类中指出类的appropriet方法。

但是，没有“每个方法的x行数是坏的”，但是如果有复制的可能性，请考虑更多，将其从当前的peice中分离并使其可重复使用。

重复使用代码是所有良好结构的基础。

分成不同的层将有助于基础变得越来越灵活和模块化。

Answer 3

如果您正在搜索，那么存在一些可计算的指标。静态代码分析工具可以提供帮助：

以下是一个列表：http://checkstyle.sourceforge.net/config_metrics.html

其他因素可能是更改/添加内容所需的时间。

其他不可计算的因素可以是

• 与变更相关的风险
• 特征的层次混合。
• 如果文档可以跟上功能/代码
• 如果文档代表应用程序。
• 所需的培训水平。
• 重复的数量而不是重复使用。

Answer 4

啊，神计划的反模式。

• 当你至少记不起来的时候 部分概述。

• 当你必须考虑如何 变化会影响自己或 的依赖关系。

• 当你不记得所有的 它依赖或依赖的东西 在它上面。

• 当需要的时间超过几个 分钟（？）下载源或 编译。

• 当你不得不担心如何做 部署新版本。

• 当你遇到的课程 在功能上与其他功能相同 应用程序中的其他类。

这么多可能的迹象。

Answer 5

我认为有很多想法为什么某些代码库太大了。

1. 很难保持不变的命名约定。如果类/方法/属性不能一致地命名或者无法一致地找到，那么就该重新组织了。
2. 当你的程序员在网上冲浪并去吃午餐以便编译时。将编制/链接时间降至最低对于管理来说非常重要。你想要的最后一件事是程序员通过长时间摆弄拇指而分散注意力。
3. 当小的更改开始影响许多其他代码位置时。合并代码有一个好处，但也有成本。如果修改一个错误的小改动导致十几个错误，并且通常会发生这种情况，那么您的代码库需要分散（版本化库）或者可能是未整合的（是的，重复的代码）。
4. 如果新项目员对项目的学习曲线明显长于可接受的时间（通常为90天），那么您的代码库/培训就没有正确设置。

..还有很多，我敢肯定。如果你从这三个角度考虑它：

1. 难以支持吗？
2. 难以改变吗？
3. 难以学习吗？

...然后，您将了解您的代码是否符合“庞大而笨重”的类别

Answer 6

对我来说，当代码库进行了大量更改时，代码变得难以处理，这些更改在程序最初编写或最后重构时没有计划。在这一点上，为了方便起见，东西开始适应现有的代码库以便于方便，并且你开始获得许多设计工件，只有在你知道实现的历史时才有意义。

Answer 7

简短回答：这取决于项目。

答案很长：

代码库不必太大而不笨重 - 意大利面条代码可以从第1行写出来。因此，从好到坏都没有真正的魔术跳跃点 - 它更像是一个伟大的光谱＆lt; - - ＆GT;非常糟糕，每天都需要努力让你的代码库走向错误的方向。您通常需要的是一位领先的开发人员，他能够客观地审查其他人的代码，并密切关注代码的体系结构和设计 - 没有任何一线开发人员可以做到这一点。

Answer 8

当我无法记住课程的内容或者其他课程时，我无法理解。它实际上更多地是我的认知能力和代码复杂性的函数。

Answer 9

我试图想出一种基于你的同事如何看待它的决定方式。

在我几年前的一个演出的第一周，我在一次站立时说过，我一直在跟踪ContainerManagerBean，ContainerManagementBean和ContextManagerBean周围的白兔（这让我感到不寒而栗，只是回想起这些话！） 。至少有两位开发人员看着他们的鞋子，我可以看到他们一直在窃笑。

就在那时，我知道这不是我对代码库缺乏熟悉的问题 - 所有开发人员都认为它存在问题。

Answer 10

如果经过多年的开发不同的人代码更改请求和错误修复，您迟早会获得具有重复功能的部分代码，非常相似的类，一些意大利面条等。 这主要是因为需要快速修复并且“新人”不知道代码库。所以他很高兴地编写了已存在的东西。

但是如果你有自动检查来检查样式，单元测试代码覆盖率和类似的，你可以避免一些。

Answer 11

人们已经发现许多指出问题的东西并不与代码库的原始大小有关，而是与它的可理解性有关。尺寸如何与可理解性相关？如果有的话......

我见过很短的程序，只是一团糟 - 更容易丢弃，从头开始重做。我也看过非常大的程序，其结构足够透明，即使在逐步更详细的视图中也是可以理解的。介于两者之间......

我认为从整个代码库是一个很好的角度看这个问题，但是从底层开始工作并首先考虑单个类，多类组件，子系统的可理解性，最后到整个系统。我希望每个细节层面的答案都能相互建立。

对于我的钱，最简单的基准就是：你能用一句话解释X的本质吗？其中X是组件的某种粒度，您可以假设理解组件上方和下方的级别。

Answer 12

• 当你需要一个实用工具方法或类，并且不知道其他人是否已经实现它或者知道在哪里寻找它时。

• 相关：当存在相同功能的几个稍微不同的实现时，因为每个作者都不知道其他作者的工作。