我不确定是否可以就该主题提供一般性建议，但请尝试。很难解释我的情况，因为它太复杂而无法解释。这正是问题所在。
我似乎经常偶然发现我尝试设计项目的某些部分的情况，但是要考虑的事情太多了，我无法掌握它。
是否有任何关于如何一次查看我的系统的一般提示或建议？如何找到可以单独设计的较小部分？
问问题
162 次
5 回答
4
创建词汇表。
换句话说，确定对项目领域有意义的术语——不是从程序员的角度，而是从熟悉主题的用户的角度。
然后尽可能精确和离散地定义这些术语。这种形式的良好定义可以作为一种伪代码。
由于您甚至没有确定问题的领域，因此我将选择一个随机示例。在文职人事系统中，您可能有以下术语：
- 方坯：特定等级和步骤的服务期限（从开始日期到结束日期）
- employee：与特定 SSN 关联的一系列方坯
- 等级和步骤：联邦总表中的行和列
等等。这并不是要识别功能单元，因为这听起来像是您正在尝试做的那样，但这是在这样做之前的一个很好的准备步骤，以便您可以用明确定义的术语表达您的功能步骤。
于 2009-05-31T22:13:50.567 回答
2
自上而下和自下而上进行问题分解很有用。
如果您无法将一个大问题拆分为两个或多个小问题，请尝试考虑需要解决的最小问题。处理完这些问题后，当您处理原始的大问题时，您可能会开始看到将它们组合成更大问题的方法。
于 2009-05-31T22:15:51.593 回答
2
您的主要目标是：
- 高内聚：一个块/模块/分区内的代码（方法、字段、类）应该密集交互；这些元素相互了解应该是有意义的。如果您发现其中一些与其他部分没有太多交互，则它们可能属于其他地方或应该形成自己的分区。如果您发现外部代码与分区密切交互并且对其内部工作了解太多，那么它可能属于内部。典型的例子可以在以过程风格编写的 OO 代码中找到，其中包含“哑”数据对象和对它们进行操作但实际上应该是数据对象的一部分的“管理器”代码。
- 松散耦合：片段/模块/分区之间的交互应该只通过狭窄的、定义明确的、记录良好的 API 发生。尝试识别此类 API，并查看实现它们所需的代码以及将使用它们的代码。
于 2009-05-31T22:47:15.007 回答
1
当我发现自己复制和粘贴代码块时进行了最小的调整，我意识到这是一个“分区”，然后创建了一个类、方法、函数或其他任何东西。
实际上，整个面向对象的方法就是它的全部内容。试着把你的应用程序看作是有形的东西。编写描述事物是什么以及它们做什么的伪代码，我发现很多这样的“分区”。
于 2009-05-31T22:08:54.790 回答
1
这是一个尝试，一种疯狂的猜测。
人们通常会低估完成这项工作需要多长时间。如果您的项目很大，那么您很可能需要几个人来处理它，因此您可以尝试考虑这一点进行规划。现在可以期望一个人只控制头部的一个区域，因此您需要向他准确解释他应该执行什么样的任务。
所以我想说你应该试着写一份工作描述，尽可能多地包含一个人认真专注的内容。重复，直到您将项目分解为您想要的部分。作为一个好处，你已经准备好组建你的团队了。但是如果你发现零件很小，也许你仍然可以自己做。
于 2009-06-01T00:14:20.653 回答