在开始开发项目之前要计划什么？[关闭]

假设我已经从客户那里收到了一个项目的规范，现在是时候开始开发它了。通常，我只是从第一个模块开始（通常是用户注册），然后从一个模块进入下一个模块。我只是在即将开始模块工作之前就在脑海中计划，但在此之前没有任何计划。

但是，我认为最好在编写代码之前仔细阅读规格并计划系统的工作方式，例如主要组件是什么，它们将如何交互等。我只是不确定我应该怎么计划。

为了更好地了解我的要求，我应该如何-

a）将项目分为几个部分，

b）计划他们的交互，例如我应该做类图，编写单元测试等吗？

有任何想法吗？

当您有特权开始一个新项目时，您将拥有一块空白的画布，它既令人兴奋又令人生畏。我迭代工作，这就是我划分工作的方式：

• 从项目目标开始。目标不一定是最模糊的，但可以帮助您将重点放在客户或用户打算对软件进行的操作上。归根结底，您想要实现这些目标-即使这意味着放弃一些非常酷的功能。
• 然后，我开始将应用程序细分为子域。可能有一百种不同的方法可以做到这一点，这就是为什么我们从项目目标开始。我们希望将应用程序分解为支持这些目标的一些相关子系统。这有助于我们专注于下一个任务。
• 确定子系统如何以及何时进行交互。我们不处理细节，仅处理高级信息以确保我们具有子系统的集成系统。您需要对此有一个总体思路，以便充实支持项目总体目标的细节。
• 仅提供当前我正在处理的子系统的详细信息（类似于您当前的策略）。我已经知道该子系统如何与其他子系统进行交互，但是我可能需要找出几个替代方案，以便最有意义。每个子系统都由一个接口隔开，因此我可以在不破坏整个系统的情况下尽可能地调整实现。
• 与在其他子系统中实现的方式相比，回顾一下我当前子系统中的实现方式。用户必须学习每种不一致的方法。如果我们正在谈论一个全新的概念，那就可以了。出于可用性考虑，我们不希望有5种不同的方式来删除仅仅因为我们很懒而存在的信息。重用相同的用户界面元素是使应用程序更加直观的最快方法。学习三个概念比学习20要容易得多。

从本质上讲，这种从非常高级到更详细的设计逐步定义项目的方法对我很有用。在实际尝试实现子系统时，甚至子系统之间的交互也会得到完善。这是好事。

我认为如果我超过规格会更好

对。好主意。

在编码之前，先计划了系统的工作方式。

好。做更多的。

主要成分是什么

优秀。

他们将如何互动，

正确。

我只是不确定我应该计划什么。

您怎么能确定何时已经列出一堆东西呢？如果这些是您关心的事情，为什么不只关注这些事情呢？

阅读4 + 1视图模型：http : //en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

阅读有关Zachman框架的信息：http : //en.wikipedia.org/wiki/Zachman_Framework

那就是您需要计划的。

我应该如何a）将项目分为多个部分，

对其他类似项目使用广泛采用的设计模式。

如有疑问，请阅读J2EE蓝图以获取想法。

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

我应该如何b）计划他们的交互，例如我应该做类图，编写单元测试等？

是。好主意，全部。

最重要的事情是：查看规格，与客户互动以获得更完善的规格。

这些要求无疑是不完整，模糊或不正确的。浪费时间最多的是做错事。客户不是专业的软件工程师，不能期望他们擅长制定一套好的要求。

因此，您应该查看规格，采访客户，并确定这是否是他/她真正需要和想要的，负担得起的，等等。

制定测试/用例并与客户进行审查。如果需求不可测试，则将其丢弃。

开发设计，并确保所有部件都能正常工作，以确保理论上可以完成您需要的工作。

开发一个体系结构原型，该原型可以测试要在每个层中使用的所有技术，但是会忽略功能。您正在测试体系结构，而不是功能规范。具有错误的体系结构将意味着您必须重写所有内容，因此获得正确的体系结构很重要。确保它可以满足您对速度，效率，安全性等方面的要求。

您绝对希望在开始编码之前进行一些设计。

一旦有了这些，我通常更喜欢先进行初始架构阶段，以定义您的应用程序层如何组合在一起。这将包括安全性和日志记录之类的骨干东西。

然后，我从上到下构建了1个功能部件，以便您完全实现一些功能。

然后从那里去。

一切

对所有内容进行计划，与在纸上进行部分编码相比，更容易在纸上进行更改，这为您提供了很好的文档基础和许多其他好处。