在项目的第一次迭代中要投入多少细节？

我刚刚开始一个新的个人项目（Python），并且正在编写相当于该程序“草稿”的内容，这是完成我想做的事情的最低要求。我尚未投入大量的错误/异常处理或美观的UI元素（即使在我最终将需要这些东西的情况下），并且该文档仅足以帮助我将来了解自己在做什么。

如此粗糙地违反项目设计/管理的既定原则？我是科学家，而不是程序员，因此无法及时掌握这些信息。因此，主要问题是，是否应该就介于以下两个极端之间的目标达成共识：

1. 从一开始就编写全面，高质量的代码，包括所有异常处理，使您知道最终需要使用。

2. 从一开始就编写一份工作最少的草稿，然后再填写所有细节。

相关问题：什么时候可以牺牲设计的“整洁度”来完成项目？

没有一个答案，因为这完全取决于项目。我们需要在这里考虑两件事。您最终的目标是什么？您希望如何到达那里？

最终结果

您是否正在编写Mars Orbiter控制软件？然后最好让该死的确保您正在编写最强大的代码，最好检查每个异常是否都是明智的。

您是否正在编写仅会运行的程序，并且偶尔会只手动运行一次？然后，不要为异常而烦恼。不要为笨重的建筑而烦恼。使它工作到适合您的程度。

您希望如何到达那里？

您是否正在进行大量瀑布开发，在那里您花费大量时间弄清楚需要什么，然后您将花费数月的时间进行开发？如果是这样，那么您想尽早达到上述目标质量。从一开始就计划好所有错误检查基础结构。

您是否正在进行大量敏捷开发，将一两个星期放在一起，然后向利益相关者展示，他们可能会要求进行彻底的修订，并且您希望能够迭代1-2次Wee冲刺直到你击中目标？这样一来，您可能会觉得工作起来比较好，但很快就会变得脆弱，并且随着产品需求的巩固而仅添加皮带和悬挂器。

如果您控制瀑布式决策或敏捷决策（实际上是一个连续统，而不是二进制选择），那么请根据预期的变化做出决策。如果您确定确切知道最终结果将是什么样，那么瀑布是您的最佳选择。如果您对最终的需求只有一个模糊的概念，那么敏捷是您的最佳选择。（近来，敏捷之所以流行，不是因为它本质上更好，而是因为第二种情况更为普遍。）

现在找到自己的答案

对于大多数人来说，答案就在中间。回答关于项目的两个问题，它应该引导您迈向基本方向。

我可以这样说，如果我经常编写一次性的脚本，这些脚本设计得非常小，并且没有错误检查任何内容。我还处理生产代码，其中错误处理和体系结构引起了大量关注。这完全取决于您在做什么。

最后一个警告：如果您决定要执行一次性的脚本，那么请确保快速完成。不幸的是，经常发生的事情是，当其他人注意到它们时，执行某些有趣操作的快速脚本又被广泛使用。确保发生这种情况时，有时间进行硬化。

所有软件设计，编码概念和模式都是针对某些问题而出现的。模式或概念是解决该问题的方法。随着时间的流逝，某些模式成为“知名”的首选解决方案，因为它们以满足某些对一致性，熟悉度，性能，可维护性等要求的方式解决了问题。

因此，如果您的特定软件中不存在要解决的软件模式问题，那么您就不需要该模式。 此外，关于您的软件可能需要哪种模式的任何讨论还必须包括对所建议软件的详细讨论：它应该做什么？它解决什么问题？会有多少用户？用户会以某种方式共享数据吗？依此类推。

异常应该解决的问题是，当发生某些事情而代码无能为力时。一个示例是File / Open操作，其中指定的文件名在存储介质上不存在。异常使代码可以对调用者说：“发生了某种事情使我无法继续前进，对此我无能为力，所以我放弃了。” 如果您的代码中没有类似条件的任何地方，那么您就不需要例外。或者，您可以简单地返回错误代码，并完全避免该异常。

随着经验的积累，您将了解有关软件模式以及何时适当使用它们的知识。您还将知道您需要多少前期设计。同样，这完全取决于您正在编写的应用程序。换句话说，小型实用程序以与大型企业应用程序根本不同的方式编写。

有一种非常简单实用的方法，适用于各种中小型项目。即使对于Mars Explorers来说可能效果不佳。

首先，确定您希望系统执行的操作，并记下每个单独的功能。这可以像整个用户故事板一样复杂，也可以像在您面前的一张纸上写下的几个要点一样简单。但是重要的是您知道自己想要做什么。

在此基础上绘制出系统的总体结构。同样，这通常只是对不同类/模块及其相互关系的快速描绘，但可能与整个文档一样复杂。重要的是，您对如何实现系统有某种想法。但是，这可能会随着您的工作而得到完善，因此请不要尝试过于复杂和详细。

在所有这些功能中，可以算出程序需要做的关键事情-核心功能。

然后一对一地实施它们。现在，这里的关键是要真正确保一旦实现了一项功能，此功能就可以完成并且可以正常工作-理想情况下，这需要进行单元测试以确保其正常工作。我通常会假设自己会很忙，以至于我再也没有时间重新使用该功能并进行修复。

一旦实现了核心功能，我通常会尝试使系统尽可能接近生产环境使用。这使您a）之前可能错过的所有错误，并且b）您对下一个功能的优先级有了很好的了解。

然后，您可以根据需要继续实施其余功能。

代码质量与功能

考虑到以上几点，如果我必须规定最后期限，那么我倾向于牺牲功能而不是代码质量。仅仅因为，至少在我的工作中，当我完成某项工作时，我的管理层认为它已经完成了。他们可以给我下一个任务。事后我没有太多时间使代码更好。

现在，异常处理呢？

如果您不希望立即实现该功能，则可以将其作为列表中的另一个功能列出。而当您实现它时，您可以实现它。但是在您的情况下，很可能还有许多其他事情首先要重要。

但是，对异常的最低要求是：确保发生任何错误时都通知用户-无论输出多么难看。不要在任何地方吞下异常。