Design patterns 在决定产品开发的软件设计/架构时需要帮助吗？

关于基于Web的在线软件应用程序，我们在确定产品开发方法方面面临困难

我们正在为在线web应用程序进行系统设计，该应用程序有可能作为SAAS服务提供。在决定以下系统设计和实现相关决策时，我们面临着困难，同时也有很多成本方面的考虑

方法A：

我们设计和开发每一件事情都是为了满足基本要求，满足基本要求，解决手头的问题，并启动它。这是一个足够好的系统，可以支持几百个用户，而不必过分关注微观优化

当客户端请求时，我们通过添加新模块来添加新功能

因此，简单的设计、单一的开发、必要时通过升级基础设施或在需要时进行优化进行扩展，并可能在将来根据需要用全新的系统取代该系统

我们保持相同的服务器，但客户端帐户的数据库不同。同样，为每个访问单独数据库的客户机托管不同的应用程序等。当需要时，我们可能会添加新的服务器。尽管管理/维护和升级难度不大

方法B：

我们研究了完整的需求、可能增加附加值的功能（尽管我们仍然不确定哪些附加功能增加了多少值？），并设计了从一开始就支持大量用户（使用大量硬件）的系统

我们推出了功能齐全的应用程序，从一开始就进行了很好的优化

我们将其设计为在单个数据库和应用程序托管中支持多个客户端帐户，并使用类似成熟SAAS应用程序的体系结构在云服务器/负载平衡服务器上实现。尽管这使得编码和维护非常困难。而且肯定需要更多的时间来实施

请注意

我们准备了功能列表、用户界面和可能使用的技术设置。我想了解解决这种情况的最佳方法是什么

如前所述，我在另一个产品开发项目中看到，由于所有功能的集合，它花费了太长的时间才能完成，甚至它还有一些根本没有被使用的功能。此类项目的成本考虑非常高，我更愿意采用A方法，因为这是快速、简单和可预测的。此外，与第二种方法相比，我很快就会收到用户反馈，这可能会帮助我决定关注哪些功能以及为什么。此外，当需要时，我们可能会重写完整的应用程序，重点关注与方法B类似的系统

---

我想了解其他公司如何管理这种情况，以及实施此类项目的最佳方式是什么？

这是经典争论的新版本：我们应该在实施之前完成设计并完善，还是应该逐步设计

我看到过很好的争论和争论。就我个人而言，我更喜欢一个中间点：有必要做一些前期设计——否则您的设计会在迭代过程中发生根本性的变化——但这个阶段不应该花费太长时间，否则您只有一个架构文档，在数月的工作之后，程序员会感到厌烦

---

所以，我将用一点方法B来做一些方法A。

方法A听起来很合理。。。如果您也可以采用敏捷SCRUM，这意味着您可以在sprint中迭代地与客户合作，您将在每次sprint之后开发并交付产品版本和功能。客户可以看到交付的更小的软件单元……而且，客户往往会改变他们想要什么新功能的想法

因此，您将始终有机会响应客户需求，只构建客户需要的内容。

这取决于您的需求

经验法则：

• “没有”总比“破碎”好
• 80%的解决方案总比什么都没有好
• 前80%将消耗您80%的资源
• 以下20%将消耗您另外80%的资源
• 如果你不以80%的价格发货，其他人会
• 在达到80%之前，你不知道剩下的20%
• 环境和需求的变化比你想象的要大。即使在应用这条规则之后

---

不要让客户等待太久，运送损坏或无法维护的产品，从而吓跑他们。不要把钱花在不需要的基础设施上。

这听起来像是程序员的话题。stackexchange.com。我已经决定搬到那里去了。接近a听起来不错。直到用户真正使用它，你才知道用户真正关心哪些功能。方法B听起来像是在错误的问题上投入大量资金的好方法。不可能提前设计所有东西。没有事先的设计是不可能成功的。同样值得记住的是，“没有什么比临时解决方案更持久的了”。您确实需要足够的架构设计来确保多次迭代不会导致“spagetti之球”反模式。而且你需要小心避免BDUF转化为分析瘫痪，我完全同意你的观点。此外，我认为最好还是坚持使用一个简单的解决方案，该解决方案可以尽早发布，然后在其基础上增加新功能。