源代码树:宽或深

Question

在写了几个python appengine应用程序后，我发现自己在两种组织源代码树的方法之间左右为难:宽的或深的。

具体来说，考虑一个小型咨询公司的内部应用程序，用于管理联系人管理、项目跟踪和报告以及员工管理等业务操作。应用程序可能使用关键实体，如:公司、用户、联系人、客户、项目、时间表等。不深入细节，可以想象这些模型是跨网站功能的。这可能意味着存在一些耦合。

在这个例子中，最好是以深度的方式进行组织，例如：

models/
   people.py
   accounting.py
   projects.py
   foo.py
controllers/
   reporting.py
   employeeops.py
   accounting.py
   crm.py
views/
   ...

或广泛的方式，例如，通过“应用”：

people/
   models/
   views/
   controllers/
contact-mgmt/
   models/
   views/
   controllers/
time-tracking/
   models/
   views/
   controllers/
project-reporting/
   models/
   views/
   controllers/

我知道所有的设计都涉及到权衡，所以在回应时，你可以指出你的偏好和一些推理(例如，假设，调制关注，框架限制，可伸缩性问题，代码维护考虑因素，开发团队结构的影响，等等)。

Answer 1

注意:我没有专门用过python。话虽如此...

Wide，我会告诉你为什么:能够快速删除东西从来不会有什么坏处。在我的职业生涯中，我经常被要求添加一些东西，并给出一个相对合理的时间表来完成它，但当需要删除一些东西时，请求几乎从来没有影响分析或浪费时间。当你按主要的功能模块进行分解时，你通常会得到一个耦合少得多的设计。这可能是一个真正的痛苦，但对于那些你必须在周末关闭工作指令模块的时候，它是一个救命稻草。

Answer 2

太深的文件夹结构会让人感到困惑。太宽了会让人迷惑。我更喜欢在它们之间保持平衡。在我正在做的项目中，我们不知道我们需要什么，所以我们没有过早地创建一个庞大的文件夹结构。毕竟，我们一开始只有5个文件，所以我们实际上不需要文件夹结构。随着项目变得越来越大，我们组织了一些东西来保持它的整洁；没有超过10个文件的文件夹，清楚地将它们分组到文件夹中。移动它需要几分钟的时间。现在我们有上百个文件，而且文件的位置总是很清楚。我的建议是做类似的事情--保持整洁，无论是深度还是宽度都不要走得太远，否则你会把事情搞得过于复杂。

Answer 3

在你的情况下，我认为“宽”模型更好。你应该尝试创建你的应用程序，使它们可以重用，即使你不打算在任何地方重用它们，因为这将鼓励不同应用程序之间的松散耦合，并从长远来看，使维护更容易。