如何评价“约定优于配置”的编程模式?

回复内容：

这是框架的设计理念，没见过哪个语言是这样的。 语言的语法就可以看做是一种约定
编译器或解释器的参数如果能影响语法的含义或支持，就算配置。 用心智空间换打字速度 人都是很懒的，能既省时间又省精力干嘛要重复做那些麻烦的事 我想到了lavavel，你倒是举个例子啊～～ 作为一个可悲的java开发者，我说一下感性的东西。
多组件配合的时候，你可以去配置，100个配置点你就有写100遍，因为你不可能知道这些配置点默认值是什么，是否必填项。
那么，约定就好像java的getter和setter，name属性，它的setter必然是setName,getter必然是getName，我不需要去配置中指定，用反射直接可以拿到setName和getName。
这是一种设计理念，一个团队中约定条件1 2 3，比如，dao的底层sql查询用add_表示增、del_开头表示删除，那么配置事务时候就直接add_* 指定一个策略就行了，这是约定。减少你出错的可能性，这是工程层面的东西，那么扩展到一种语言，就好像java的getter和setter，也算一种约定，但是为了语言的灵活性，这样的约定会比较少，不像框架中约定使用的这么随意。 就好像和熟人合作优于陌生人，但现实是残酷的 约定重于配置会造成熟的人上手很快，不熟的人学习成本上升。
约定重于配置会导致扩展性下降，为了弥补配置的不足会产生很重的实现，最终又体现在学习成本的增加上。
约定重于配置能够让熟手在熟悉的领域快速开发，长远来看不一定是好事。 约定大于配置，只要记住约定的，就少写了配置文件 没见过哪个语言？go语言的函数首字母大写表示public、小写表示private算不算？