源代码树：宽还是深

Question

在写了几个Python的App Engine应用后，我发现自己在组织源代码时有点纠结：是选择宽松的结构还是深层的结构。

为了更具体一点，假设有一个小型咨询公司的内部应用，用来管理业务操作，比如联系人管理、项目跟踪和报告、员工管理等。这个应用可能会用到一些重要的实体，比如：公司、用户、联系人、客户、项目、工时表等等。虽然不想细说，但可以想象这些模型在网站的功能中是交叉使用的。这很可能意味着它们之间有一些关联。

在这个例子中，是选择深层次的组织方式，比如：

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

在你的情况下，我觉得“宽松”的模型更好。你应该尽量把你的应用程序设计得可以重复使用，即使你现在不打算在其他地方使用它们。这样做可以让不同的应用之间的联系更松散，长远来看，维护起来也会更简单。

Answer 2

文件夹结构如果太深了会让人迷糊，太宽了也会让人困惑。我觉得保持一个平衡最重要。在我现在做的项目里，我们一开始根本不知道会需要什么，所以没有提前搞一个超级复杂的文件夹结构。毕竟，我们最开始只有5个文件，所以其实并不需要什么文件夹结构。随着项目的扩大，我们逐渐整理文件，让它看起来整洁；每个文件夹里的文件不超过10个，文件夹里的内容也分得很清楚。移动这些文件也只需要几分钟。现在我们有一百多个文件，所有东西都很清楚在哪里。我建议大家也这样做——保持整洁，不要在文件夹的深度或宽度上走得太远，否则会让事情变得复杂。

Answer 3

注意：我没有专门使用过Python。不过，话说回来……

我认为这样做是有好处的，原因很简单：快速删除东西总是有用的。在我的职业生涯中，我经常被要求添加一些功能，并且通常会给我一个相对合理的时间来完成。但是，当需要删除某些东西时，几乎从来没有人会提供影响分析或者给我时间去处理这些事情。当你把功能按模块划分开来时，设计通常会变得不那么紧密耦合。这可能会让人感到很麻烦，但在那些你必须在一周内关闭工作订单模块的情况下，这种设计就像救命稻草一样。