Design patterns 应用工程和用户数量

除了性能问题外，基于web的应用程序是否应该根据（并发）用户的数量进行不同的构建？如果是，那么（比如）4、40、400和4000用户的主要区别是什么

---

我特别感兴趣的是如何根据并发用户的数量来使用日志记录、错误处理、设计模式等。

我不是这方面的专家……但以下是我的想法

如果应用程序将由4个已知用户使用，那么广泛使用设计模式、构建广泛的日志功能等可能不是非常必要的，因为您投入的每一个额外的工作单元都会带来较少的回报

但是，如果应用程序将被更多的人使用，您会担心可伸缩性、安全性等问题。使用设计模式等可能更有意义。当然，我的假设是，如果只有4个人使用一个应用程序，那么它可能不是非常关键的任务

---

所以我相信你应该从简单开始，根据需要做出改变。但是，以下好的设计模式总是好的-理想情况下，您的设计允许您根据需要更换零件。

aip.cd.aish给出的答案给了我这个想法：

我认为答案是估算在给定情况下工程工作的成本与相对效益

用户较少的应用程序对业务的附加值较小，这种情况并不少见，但你需要仔细研究个别情况

事实上，在某些情况下，更少的用户需要更多的工程努力。例如，如果你的应用程序被一些关键客户使用，除非你的产品提供比你的竞争对手更好的服务，否则他们会去别处，那么你可能有理由花时间在坚实的工程上

具体想法：

---

日志记录：对于“小型”应用程序，您最好与用户进行实际交谈（…我知道…），而不是记录所有内容。对于“大型”应用程序，无法描述的日志记录可能意味着日志增长太快，没有太多用处。

在你的帖子中有一些我没有想到的好主意。谢谢