design-patterns - 您如何在设计和(实际)实现应用程序之间取得平衡

Question

我的问题不是特定于编程语言的，而是更通用的问题，以了解人们的思维方式。

通常在大型开发公司中，每项工作都有特定的角色，例如程序员和架构师。因此架构师的观点是拥有完美的架构师和解决方案设计，另一方面程序员正在处理实际实现应用程序功能和 UI 的东西。因此，如果您让架构师在没有程序员的情况下处理应用程序，您将从内部(设计模式、类、数据库表)获得完美的应用程序，但从外部不会得到任何东西，反之亦然。程序员总是关注输出，而不太关心设计原则(例如 SOLID 原则)。

现在我在一家小公司工作，团队最多由 8-10 人组成，所以你需要照顾你的应用程序设计以及实现功能。所以我的问题就是

• 您什么时候需要停止设计和实现您的解决方案？
• 或者应该是增量工作？
• 如果您仅仅因为从一开始就没有设计好而搞砸了该怎么办？

我希望我们能有不同的思维方式，这样我们就能想出多种可以接受的解决方案

Answer 1

彻底思考问题/设计将改进最终的代码。但是，除非您在编写代码时花费数月时间进行设计，否则您将发现设计中的缺陷、您没有想到的新功能或您没有预料到的交互。在大多数软件项目中，目标都会发生变化(客户会想要一些稍微不同的东西，或者你会在中途产生一个好主意，等等)。

瀑布方法倾向于在您不知道代码将如何实现之前就预先完成整个设计 - 这是不灵活的，并且会导致设计缺陷发现得太晚而无法对其采取太多措施。通常，即使在瀑布方法中，我也建议进行原型(prototype)设计，其中高风险编码任务在设计阶段实际实现到足够大的程度，以确认它们可以完成并按预期工作。

敏捷方法建议您只应开始设计所需的量，然后在发现需要时再进行更多设计。这将编码与设计混合在一起，形成了一种更加灵活的方法。然而，这常常被误解为“没有完成任何设计”，或者直到为时已晚才考虑设计的大部分内容 - 情况不应该如此。您应该设计足够的整体结构，以便您了解如何继续进行，并且您没有精确指定的设计的小部分足够简单，以便您知道以后能够在不影响最终产品的情况下设计它们。

因此，无论走哪条路，您都需要充分计划，以便知道自己的前进方向，足够灵活，可以在需要时改变方向，但在此过程中编写一些代码(原型(prototype)或最终代码)来帮助指导你的设计。如果程序的某些部分被证明不充分，请准备好重构和重写它们。