源代码树：宽还是深
在编写了一些 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/
我知道所有的设计都涉及权衡，所以在回答时你可以表明你的偏好和一些推理（例如，假设、调节问题、框架限制、可扩展性问题、代码维护注意事项、开发团队结构的影响等）。
After writing a few python appengine apps I find myself torn between two approaches to organizing my source code tree: wide or deep.
For concreteness, consider an internal application for a small consulting shop to manage business operations like contact management, project tracking & reporting, and employee management. The application might use key entities like: Company, Users, Contacts, Customers, Projects, Timesheets, etc. Without going into details, one can imagine that these models are cross-cutting across the functions of the website. This likely means there is some coupling.
In this example, is it preferable to organize in a deep-manner, e.g.:
models/
people.py
accounting.py
projects.py
foo.py
controllers/
reporting.py
employeeops.py
accounting.py
crm.py
views/
...
or a wide-manner, e.g., by "application":
people/
models/
views/
controllers/
contact-mgmt/
models/
views/
controllers/
time-tracking/
models/
views/
controllers/
project-reporting/
models/
views/
controllers/
I know all design involves trade-offs, so when responding can you indicate your preference and some reasoning (e.g., assumptions, modulating concerns, framework limits, scalability issues, code maintenance considerations, impact of development team structure, etc.).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
警告：我没有专门从事过Python工作。话虽如此……
宽，我会告诉你原因：能够快速删除东西从来没有坏处。在我的职业生涯中，我经常被要求添加一些东西，并给出一个相对合理的时间表来完成它，但是当需要删除某些东西时，请求几乎从来没有伴随着影响分析或混乱的时间。当您按主要功能模块进行分解时，通常会得到耦合度低得多的设计。这可能真的很痛苦，但对于那些你绝对必须在周末之前关闭工单模块的时候，它是一个救星。
Caveat: I haven't worked in python specifically. Having said that...
Wide, and I'll tell you why: It never hurts to be able to remove things quickly. In my career I am often asked to add things and given a relatively reasonable schedule on which to do it, but when something needs to be removed, the request almost never comes with impact analysis or time to mess around. When you break things out by major functional modules, you usually end up with a much less coupled design. It can be a real pain in the ass, but for those times when you absolutely have to get the work order module turned off by the end of the week, it is a life saver.
文件夹结构太深会让人感到困惑。太宽会让人感到困惑。我更喜欢在它们之间保持平衡。在我正在进行的项目中，我们不知道我们需要什么，所以我们没有过早地创建一个庞大的文件夹结构。毕竟，我们一开始只使用了 5 个文件，因此我们并不真正需要文件夹结构。随着项目变得越来越大，我们会组织一些事情以保持项目的整洁；没有超过 10 个文件的文件夹，将内容清晰地分组到文件夹中。将其全部移动需要几分钟。现在我们有超过一百个文件，而且文件在哪里总是一目了然。我的建议是做类似的事情——保持整洁，不要在深度或宽度上走得太远，否则会让事情变得过于复杂。
Too deep a folder structure makes it confusing. Too wide makes it confusing. I prefer to keep a balance between them. On the project I'm working on, we had no idea what we'd need, so we didn't prematurely create a massive folder structure. After all, we only started with 5 files, so we didn't really have a need for a folder structure. As the project got bigger, we organised things to keep it neat as we went; no folders having more than 10 files, grouping things into folders clearly. It would take a few minutes to move it all around. Now we have well over a hundred files, and it's always clear where things are. My recommendation is to do similar - keep it neat, don't go too far with either depth or width, or you'll over-complicate things.
就你而言，我认为“宽”模型更好。即使您不打算在任何地方重用它们，您也应该尝试创建可重用的应用程序，因为这将鼓励不同应用程序之间的松散耦合，并从长远来看使维护更容易。
In your case I think the "wide" model is better. You should try to create your apps so they reusable even if you don't plan to reuse them anywhere as this will encourage looser coupling bewteen different apps and make maintenance easier in the long run.
其实我更喜欢混合。软件分为水平组件和垂直组件。
水平组件可在所有模块中重用，并表示要重用的通用代码，这些代码不是特定于应用程序的，而是特定于体系结构的。
因此，我有常用实用程序、框架、可重用基础设施库的文件夹，例如持久性、通信、安全性、日志记录等......
垂直组件是单独的用例。
对于每个用例，我都有一个包含 UI、服务器的文件夹，在 UI 下我有视图和控制器。该模型通常在两者之间共享。
如果您的项目非常大，那么您可能有不同的职责领域，例如库存控制、销售、联系人管理、报告等...将这些添加到您的文件夹结构中，并将适用的用例放在它们下面。
如果有任何重用，可以随意将任何组件移至树上。
Actually I prefer a mix. Software is divided into Horizontal and Vertical Components.
Horizontal components are reusable across all modules and represent common code to be reused that is not application specific, instead is architecture specific.
So I have folders for common Utilities, Frameworks, reusable infrastructure libraries, such as Persistence, Communications, Security, logging etc...
Vertical components are the individual Use Cases.
For each use case I have a folder that has UI, Server and under UI I have views and controllers. The model is often shared between the two.
If your project is really large then you probably have different areas of responsibility, such as Inventory Control, Sales, Contact management, Reporting etc ... Add these to your folder structure and put the use cases that apply under them.
Feel free if there is any reuse to move any components up the tree.