在开始编写代码之前，清楚地了解需求和体系结构有多重要？

Question

只要有可能，在开始编写代码之前，我一直要求了解下一个工作范围的需求和体系结构。

有时，由于对较大项目的日程安排压力，我必须先开始编写代码，然后才知道我需要了解的工作范围，但在这种情况下，我把尽快赶超作为一个优先事项。如果我不能把所有的事情都写进发行版，那么至少在接下来的几周里，我要了解的是我需要知道的事情。

这似乎是一个显而易见的没有头脑的，我甚至不好意思问它，但我一直被推倒，所以我想要一个现实的检查。也许在你做之前了解你将要做的事情有一些坏处，如果是这样的话，我希望有人能告诉我。

或者，如果我所做的似乎是一个最佳实践，那么一个简单的确认将不胜感激。

如果有什么不同的话，我所受到的阻碍是在一个项目上，这个项目的开发时间约为5个月，对我工作的公司来说，价值高达数百万美元。

Answer 1

我见过人们直接钻研代码，做出错误的假设，花了很长时间写错了东西。

另一方面，我看到人们花了几周的时间“理解需求”，绘制漂亮的体系结构图等等--结果发现，当他们真正开始编写代码时，他们忽略了一个根本的问题，如果他们开始编写代码，他们会更早地发现问题。

换句话说，一切都是平衡的。高级开发人员的关键技能之一是确定如何为特定的工作设置这种平衡。对于某些工作，风险在于需求，您应该花更多的时间在这些方面。对于其他工作，风险在于实现，您应该花更多的时间进行编码。没有简单的答案，对不起。

Answer 2

有一个很大的研究领域致力于此。例如，参见：

• https://en.wikipedia.org/wiki/Category:Software_项目_管理
• https://en.wikipedia.org/wiki/Agile_软件_开发
• https://en.wikipedia.org/wiki/Iterative_和_增量式_开发
• https://en.wikipedia.org/wiki/Waterfall_模型

从根本上说，在实现用户使用、研究和提供反馈之前，完全的需求可能是不可知的。因此，在几乎任何软件项目中，需求都会随着时间的推移而变化，以满足用户的需求和正在解决的市场。

因此，你不一定能提前知道完整的需求--部分原因是鸡蛋问题，部分原因是我们无法预见新市场的发展。

因此，我们拥有的最佳智慧似乎是将代码编码到当前已知的(和优先级的)需求上，而不浪费时间来架构&编写预期的特性，但实际上并没有要求和/或优先级--因为这些特性很可能在将来消失，取而代之的是一些不同的东西。

尽管如此，对于如何解决这个问题还是有很多不同的意见，而且有许多相互竞争的、相当正式的或者至少有详细记录的过程可供选择或适应，还有许多关于成功项目开发的故事，原因是流动性问题，以及(好的或坏的)对特定情况的开发过程的选择(即目标/项目、参与的团队、公司等)。

关键词是重构，技术债务，增量与瀑布。(注意，简化的瀑布有时被认为是对一个极端的提案的捕捉，实际上没有人能够跟随它，因为开发过程的一个部分到另一个部分存在反馈问题。)

让我补充一下，当模糊需求变得清晰时，我发现重新架构并不像看起来那么困难，因为知道编写什么代码比编写代码要困难。

Answer 3

最重要的是知道什么时候该停下来。

收集需求。做建筑设计。当它没教你什么的时候就停下来。我想他们就像做爆米花。当它使想法流行的时候，它就很棒。一停下来，马上回去工作。

如果你这么做只是因为你应该这么做，那你就是在浪费时间。

我向上帝发誓，我曾经参加过一些会议，在这些会议上，程序员使用了来自不同项目的UML图，只更改了类的名称(使用了windows画图)。我见过的最精彩的东西。我讨厌那些只关心复选框的人把好工具变成毫无意义的仪式。