概述

约定优于配置是一个简单的概念，主要用于编程。这就意味着我们的编程环境（系统，库，语言等）会默认预设诸多的逻辑处理（这里类似配置但可以动态加载的配置），所以如果我们采用这种已经预设好的编程环境，而不是每次都创建自己的规则，那么编程将变得轻松和高效。

作用

这种范式可以有效减少我们做出决策的数量，并且消除应用程序开发所必须要有配置的复杂性，这样带给我们的直接收益就是能在更短的时间内创建更多的东西。

使用

podspec

我们比较熟悉的如podspec文件就是基于这个范式来创建应用的。这个文件包含了我们创建库的名称，版本号，简介，详情，来源，依赖库，支持的最低系统，支持语言的最低系统，子库的配置，子库文件路径的设定，以及是动态库还是静态库。提前搞好了这个文件，就能让使用这个库的家伙们省去很多麻烦，不需要再去设定需要的配置，并且能根据不同的需求来导入不同的子库，不失去灵活性。

Ruby on Rails

这个非常成功的编程环境也是基于此范式的。如果遵循已建立的约定，则与使用Java开发类似的Web应用程序相比，可以用更少的时间和更少的代码来开发Rails应用程序。
另一个方面，如果你想要忽略约定，则可以始终用自己的代码替换它们。但是，由于约定不是任意的，而是由高级程序员社区建立的，因此浪费时间重写约定几乎是没有道理的。

GTD （尽管去做）

实际上，约定优于配置的概念也是任何需要某种结构的工作的基础。如 GTD 的这种时间管理的方法，为个人提供一系列约定。比如建立管理一系列具体列表，建立五个阶段的工作流程，定义六个透视图级别，从而通过这些约定来接您工作的重要性。还定义了其他的一些方面，例如查看系统或计划项目的理想方法。
这些约定由GTD的创建者David Allen定义，经过数十年的努力，他帮助客户组织了自己的工作，并查看了哪些有效，哪些无效。后来，它们被每天使用此方法的数十万人验证，并得到认知科学研究人员的支持。
当然，事情都有两面性。在任何结构化的工作环境中，都有两个基本问题。首先，它需要更大的学习曲线，您需要了解该系统以充分利用它。其次，有人认为不太适应这种方法的强制性。
要在约定和配置之间找到平衡并不容易。过多的约定会使系统过于混乱，并会增加学习难度。过多的自由度又会使用户可能会不必要的增加系统复杂性，从而难以实现所需的目标。
在任何情况下，使用预先设置了大部分约束的系统总是比使用完全开放的系统要高效，在完全开放的系统中，您必须设置所有规则并做出所有决定。而且投资回报通常超过学习的需要。
当然，您始终可以保妥常规，使用自己的解决方案覆盖系统。但是，如果我们讨论的是GTD，大多数时候您都是在自欺欺人，试图让自己不去做自己应该做的事情。

就像Ruby on Rails降低了访问功能强大的Web应用程序编程的障碍一样，GTD降低了您进化为非常高效的个人的障碍。触手可及，何不来试一试呢，朋友们。

原文链接：
https://facilethings.com/blog/en/convention-over-configuration