拆分大型模块是否有负面影响？[关闭]

我正在浏览一个github项目，发现此模块有1万多行。

在一个模块中包含这么多的代码是一种惯例吗？

在我看来，这应该分为多个模块。也许每个数据库引擎一个。

开发人员从制作这样一个巨大的模块（而不是“将其全部放在一个地方”）获得什么好处，或者将其拆分（而不是“复杂性”）有什么坏处？

您遇到的是所谓的“ 上帝对象 ”，因为它可以做所有事情或知道所有事情。逃避它（如果可以的话）。

每个模块没有确定的LOC数量，但应该可以轻松浏览代码并轻松了解方法的作用。根据我的个人经验，如果您的模块超出1k行^*，则说明您做错了。

^{*甚至1k线路模块也很大。}

这似乎是一个可能不适用典型尺寸限制的模块。大多数功能位于代码和注释的前2k行中。文件的其余部分似乎是很多适配器类和其他支持类，它们似乎与模块紧密耦合。用其他语言，这些类将放在合理大小的单独文件中。

一些更多的文档字符串可能很有用，但是它们会增加已经很大的模块的大小。该代码清晰易懂，并在需要时提供适当的注释。

当然，实际的“限制”因您的项目和多种因素而异。

但是我的经验法则是：200行不错的Python。也就是说，没有用Python编写的C或Java代码，而是用Python编写的优秀Python。

哇。

我想我不知道这个的完整答案，但我想作为标题问题“ Python模块应该有多大？”的答案。作为Parnas的概念，隐藏了一个秘密。在这种情况下，该模块似乎可以正确地执行此操作（这就是它隐藏的重要秘密）。

后来我一直在研究论文，这些论文讨论了很多有关耦合和内聚的内容。也许拥有许多数据库模块会导致模块之间的调用过多，从而导致不良做法（即较低的内聚性和较高的耦合性）增加？

我已经看到了实验数据，这些数据涉及程序员决定为简化和理解而牺牲良好的实践，尽管有良好的实践要求。实际上，良好实践之间也可能存在冲突。说，性能通常不会使以后进行维护的人员感到高兴。我不确定使用如此大的模块在这种情况下如何提高可读性。

我注意到的另一件事是，代码的一部分被声明为通用代码，其余的dbs从该代码扩展而来。我不是python程序员，但是也许这可以证明某些理由？

因此，我没有最终答案，但我希望有人也能强调这些观点！