如何将问题划分为更小的可理解部分？

Question

我不确定是否可以就此主题提供一般性建议，但请尝试。很难解释我的案例，因为它太复杂而无法解释。而这正是问题所在。

我似乎经常偶然发现我试图设计项目的某些部分的情况，但是有很多事情需要考虑，我无法掌握它。

关于如何一次以较小的碎片查看我的系统，是否有任何一般性提示或建议？如何找到可以单独设计的较小部分？

Answer 1

创建词汇表。

换句话说，确定对项目域有意义的术语 - 不是来自程序员的观点，而是来自熟悉该主题的用户。

然后将术语定义为精确和离散。这种形式的良好定义可以作为一种伪代码。

由于您还没有确定问题的域名，我会选择一个随机的例子。在文职人员系统中，您可能会有以下术语：

• 方坯：特定等级和步骤的服务期限（从开始日期到结束日期）
• 员工：与特定SSN相关的一系列方坯
• 成绩和步骤：联邦总体日程表中的行和列

等等。这不是识别功能单元，因为它听起来像你正在尝试做的，但这是一个很好的准备步骤，所以你可以用明确定义的术语表达你的功能步骤。

Answer 2

自上而下和自下而上处理问题分解很有用。

如果您在将大问题分成两个或更多小问题时遇到问题，请尝试考虑需要解决的最小问题。处理完成后，您可能会开始看到在处理原始大问题时将它们组合成更大问题的方法。

Answer 3

您的主要目标是：

• 高内聚：单件/模块/分区中的代码（方法，字段，类）应该密集交互;它应该有意义让这些元素相互了解。如果您发现其中一些与其他部分没有太多交互，那么它们可能属于其他地方，或者应该形成自己的分区。如果您发现外部代码与分区密切交互并且对其内部工作了解太多，那么它可能属于内部。典型的例子是在以程序风格编写的OO代码中找到的，“哑”数据对象和“管理器”代码对它们进行操作，但实际上应该是数据对象的一部分。
• 松散耦合：件/模块/分区之间的交互应该只通过狭义，定义明确，记录良好的API来实现。尝试识别此类API，并查看实现它们所需的代码以及将使用它们的代码。

Answer 4

当我发现自己以最小的调整复制和粘贴代码块时，我意识到这是一个“分区”，然后创建一个类，方法，函数或其他任何东西。

实际上，整个面向对象的方法就是它的全部。尝试将您的应用程序视为有用的东西。编写伪代码来描述事物是什么以及它们做了​​什么，我用这种方式找到了很多“分区”。

Answer 5

这是一种尝试，一种狂野的猜测。

人们通常会低估他们完成这项工作需要多长时间。如果您的项目很大，那么很可能您需要几个人来处理它，因此您可以尝试计划这一点。现在一个人可能只能在头部占据一个区域，所以你需要向他解释他应该做什么样的任务。

所以我要说你应该尝试写一份工作描述，尽可能地让一个人认真地专注。重复，直到您将项目分解为您想要的部分。作为一项好处，您已准备好组建您的团队。但如果你发现零件很小，也许你仍然可以自己动手。