1. 引言
随着 SaaS（软件即服务）时代的兴起，软件开发面临一个关键抉择：是开发一个通用性强、用户可自由定义使用方式的软件，还是提供一个引导用户按特定方式完成任务的软件？
于是，一边是提供多种通用方式让用户完成任务的系统，另一边则是提供特定工作流的系统。这两种设计策略的优劣构成了“非约定式（non-opinionated）”与“约定式（opinionated）”设计的核心讨论点。
本文将探讨这两种设计模式的概念与差异。 我们将从软件设计的历史背景讲起，然后分别深入非约定式设计和约定式设计的特点，最后通过系统性对比总结其适用场景。
2. 设计理念的演变
在云时代之前，软件通常是作为一次性购买的产品来销售的。 也就是说，用户选择一个软件、付费购买后，可以按照自己的方式使用。
这种模式在今天依然存在，但也存在一些潜在问题。例如，一次性购买的软件可能缺乏持续更新，导致用户长时间使用过时的版本，直到再次购买新版本。
进入云时代后，新的软件交付模式应运而生。软件可以按需订阅，用户不仅获得软件本身，还获得运行所需的基础设施。这种模式让软件变得高度动态，解决方案可以部署在云端，并随时更新。
这种模式被称为“即服务”模型，具体到我们的话题就是 Software-as-a-Service（SaaS）。
这种变化促使行业重新思考如何为用户提供软件解决方案。 是让工作流更灵活，还是更高效？是提供通用服务，还是专业服务？这些问题引出了非约定式与约定式设计的讨论。
值得一提的是，“约定式”这一概念早已有之，不仅适用于软件产品，也适用于编程语言等领域。但近年来软件开发的趋势使这一讨论再度升温。
3. 非约定式设计（Non-opinionated Design）
非约定式设计的核心理念是赋予用户充分的自主决策权。 这类系统通常提供多种完成任务的方式，用户可根据具体问题和上下文选择最适合的方法。
非约定式设计的关键词是“灵活性”。 通过提供多种实现路径，非约定式系统信任用户能做出最佳决策。因此，没有统一的“正确方式”，只有最适合当前资源和场景的方式。
当然，这种高度的灵活性也带来了挑战。例如，在使用电子表格软件时，用户可以自由定义数据结构，但不合理的结构可能导致效率低下，远不如一个优化过的结构高效。
同样，在使用像 Perl 或 PHP 这类通用语言开发软件时，如果决策不当，最终的系统工作流可能变得异常复杂。
总结来说，使用非约定式系统就像面对多条通往同一目的地的道路，选择哪条路取决于你的资源和目标。
下图直观地展示了非约定式软件在决策上的特点：
4. 约定式设计（Opinionated Design）
约定式设计更像是一个“导航系统”，它会告诉你完成任务的“推荐方式”。 这类系统提供清晰的指引和资源，告诉你应该如何使用它们。
但这并不意味着约定式系统只能用一种方式完成任务。实际上，用户通常也可以选择不走“推荐路线”。但这样做可能会遇到各种障碍，甚至引发问题。
约定式设计的关键挑战在于判断问题是否与系统设计的流程匹配。 如果匹配，使用约定式系统可以快速、高质量地完成任务；如果不匹配，最好换一个更合适的系统，或者选择非约定式方案。
一个典型的约定式例子是维基页面。它提供了一种无需 HTML/CSS 知识即可编辑网页内容的方式。如果你的需求正好适合维基页面结构，那使用它会比从头开发网页高效得多。
在编程框架中，Ruby on Rails 是约定式设计的典范。
简而言之，约定式设计就像在一条设有清晰路标的道路上驾驶租来的车。遵循这条路非常简单，但偏离它可能会带来灾难性后果。
下图展示了约定式设计的概念，延续我们上面的类比：
5. 系统性对比总结
在前面的章节中，我们分别探讨了非约定式与约定式设计的交互方式和适用场景。
总结来说，它们的核心差异在于“灵活性”。
- 非约定式设计提供多种完成任务的方式；
- 约定式设计则通常推荐一个“正确路径”。
灵活性可以是优势，也可以是劣势。优势在于用户可以根据资源和上下文做出最适合自己的决策；劣势在于错误的决策可能影响整个系统的性能或流程。
以下是对两者特点和示例的对比总结：
| 特性 | 非约定式 | 约定式 |
|---|---|---|
| 关键词 | 灵活性 | 引导性 |
| 用户视角 | 决策权在用户手中 | 系统指明“正确方式” |
| 软件示例 | Microsoft Excel、Eclipse IDE | 维基系统、Holacracy |
| 编程语言示例 | C、Perl、PHP | Ruby on Rails、Go |
当然，两者之间也存在一种“黄金平衡”——即在提供高度灵活性的同时，又通过强约定的惯例引导用户。这种设计下，用户有“推荐路径”可用，同时又能应对特定场景的个性化需求。
6. 总结
本文介绍了非约定式与约定式设计的核心概念。 我们从软件设计的历史背景讲起，逐步分析了这两种设计模式的特点和适用场景，并通过对比帮助你理解其差异。
随着技术行业商业模式的演进，关于非约定式与约定式软件的讨论变得越来越重要。每种设计都有其优缺点，关键在于根据实际需求选择最合适的方案。
最终，选择哪种设计模式，取决于你的目标用户、业务场景以及团队的技术偏好。合理权衡两者，才能设计出真正高效的系统。