我正在用java编写一个中等项目。截止日期非常紧迫。如何最好地分配你的时间： 1. 根据预期的逻辑编写代码，并在最后开始测试。2.或将逻辑分解为子任务并逐个编写/测试。
第二种方法看起来更合乎逻辑，但是假设写了我的任务和测试的1-5点之后，我会理解第8点和第9点迫使我重写第1-5点。这正是发生的事情，这就是我问这个问题的原因。结果，测试的时间被浪费了。
如果有关于这个主题的好文章，我将不胜感激。
RError.com
我正在用java编写一个中等项目。截止日期非常紧迫。如何最好地分配你的时间： 1. 根据预期的逻辑编写代码，并在最后开始测试。2.或将逻辑分解为子任务并逐个编写/测试。
第二种方法看起来更合乎逻辑，但是假设写了我的任务和测试的1-5点之后，我会理解第8点和第9点迫使我重写第1-5点。这正是发生的事情，这就是我问这个问题的原因。结果，测试的时间被浪费了。
如果有关于这个主题的好文章，我将不胜感激。
敏捷（迭代）项目管理延长了开发时间（在第二种选择中，您实际上是在准确描述敏捷技术），但将错误设计的风险降至最低。
不幸的是，在 90% 的项目中，在编写技术规范（或计划项目）时，不可能 100% 立即识别所有可能的问题。正如您自己正确指出的那样，某个阶段之后的项目开始过自己的生活，即：
如果项目很小，或者您确定错误设计的风险很小，那么您可以在最后立即编写和测试。
您可以选择另一种方式将任务不分成 8-9 分，而只分成 2-3 分，因为点数/迭代越多，您对非线性设计的自由度就越大，但点数越少，风险越大不正确的设计。
因此，您需要确定项目的阶段/迭代，而不是基于项目的内部逻辑，而是基于错误设计的风险，也就是说，如果您在项目中看到，比如说，10 个逻辑阶段，其中5个你很懂，另外5个是“黑暗森林”，那么把项目分成6个阶段是有道理的：1个阶段收集5点你很清楚，5个不理解就留下5阶段。很明显，这并不总是可能的，但尽管如此 - 作为一个普遍的想法。