推荐的方法将一些功能分解为功能，模块和包？

Question

有一个问题，在一个相对大型的项目中，需要考虑将功能分为各种功能，然后是各种模块，然后是各种包。有时跨越不同的源代码分发（例如：将公共实用程序（例如optparser）提取到单独的项目中）。

问题 - 如何决定放入同一模块的零件，以及放入单独模块的零件？包的问题相同。

Answer 1

David Parnas的一篇经典论文称为“关于将系统分解为模块的标准”。这是一个经典（并且具有一定的年龄，因此可能有点过时）。

也许你可以从那里开始，这里有一个PDF

http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

Answer 2

取出一支笔和一张纸。尝试绘制软件在高级别上的交互方式。绘制软件的不同层等。按功能和目的对项目进行分组，甚至可以使用他们使用的技术。如果你的软件有多个抽象层，我会说按它分组。在较高的层面上，特定层的元素都具有相同的通用目的。现在您已经将图像分层，您可以根据特定功能或专业化将这些图层划分为不同的项目。

至于你应该达到的某个阶段？我会说当你有多个人在代码库上工作或者你想让你的项目尽可能模块化时。希望您的代码足够模块化以实现此目的。如果您无法在高级别上分解您的软件，那么您的软件可能是意大利面条代码，您应该考虑重构它。

希望这会给你一些合作的东西。

Answer 3

请参阅How many Python classes should I put in one file?

绘制整套课程定义。

将这些类定义划分为“模块”。

彼此分开实施和测试模块。

将模块编织在一起以创建最终应用程序。

注意即可。分解一个有机发展的工作应用程序几乎是不可能的。所以不要这样做。

尽早并经常分解您的设计。构建单独的模块。集成以构建应用程序。

Answer 4

恕我直言，这应该是你在开发过程中早先做过的事情之一。我从未参与过一个大型项目，但是你可以制定一个路线图，说明将要做什么以及在哪里做。 （不要因为你犯了错误而试图纠结你：D）

模块通常按某种方式按目的或功能分组。您可以尝试接口或其他连接的每个实现。

Answer 5

我同情你。你正遭受自我怀疑。别担心。如果您能说任何语言，包括您的母语，您就有资格自己进行模块化。有关证据，您可以阅读“语言本能”或“数学本能”。

环顾四周，但不要太多。你可以从中学到很多东西，但你也可以从中学到许多不好的东西。

1. 一些项目/框架得到了很多宣传。然而，他们的一些功能组合，甚至模块的名称都是误导性的。他们没有“揭示程序员的意图”。他们没有通过“高凝聚力”测试。

2. 书籍并不好。请在您的图书选择中应用80/20规则。即使是像Capers Jones的2010年“软件工程最佳实践”这本优秀，非常完整，研究得很好的书也是毫无头绪的。它表示10人Agile / XP团队需要12年才能完成Windows Vista，或者需要25年才能完成ERP套餐！它表示，到2009年，没有任何方法可用于分割，即模块化的术语。我认为它不会对你有所帮助。

我的观点是：您必须非常仔细地选择您的模型/参考/示例来源。不要过高估计名人，低估自己。

根据我的经验，这是我的帮助。

1. 这很像决定哪些属性去哪个DB表，哪些属性/方法去哪个类/对象等？在更深层次上，它很像在家里安排家具，或在书架上安排书籍。你已经做过这样的事了。软件是一样的，没什么大不了的！

2. 首先担心“凝聚力”。例如书籍（Leo Tolstoy，James Joyce，DE Lawrence）很有选择性。（HTML，CSS，John Keats，jQuery，tinymce）不是。有许多方法可以安排事情。甚至分类学家对此仍然存在严重的不和。

3. 然后担心“耦合”。怕羞”。 “别跟陌生人说话。”不要过于友好。尝试使您的包/ DB表/ class / object / module / bookshelf尽可能独立。 Joel谈到了他对Excel团队的钦佩，他们厌恶所有外部依赖，甚至构建了自己的编译器。

Answer 6

实际上，对于您创建的每个项目，它都有所不同，但这是一个示例：

1. core包中包含您的项目无法生效的模块。这可能包含您的应用程序的主要功能。
2. ui包中包含处理用户界面的模块。也就是说，如果您从控制台中拆分UI。

这只是一个例子。你真的会决定在哪里以及去哪里。