复杂性守恒定律 (The Law of Conservation of Complexity or Tesler’s Law)：系统中存在着一定程度的复杂性，并且不能减少。
系统中的某些复杂性是无意的。这是由于结构不良，错误或者糟糕的建模造成的。这种无意的复杂性可以减少或者消除。然而，由于待解决问题有固有的复杂性，这些复杂性是内在的。这些复杂性可以转移，但不能消除。
该定律有趣的一点是，即使简化整个系统，内在的复杂性也不会降低。它会转移给用户，并且用户必须以更复杂的方式行事。
现实世界的复杂度无法使用代码来消除，如果你想少写代码，就要多写配置；如果你想少写配置，就要多写注解……
业务逻辑无法使用代码来化简或消除，业务逻辑不写在代码里，那就一定会转移到配置文件里或者其他什么地方。
业务逻辑不是程序员能控制的，程序员只负责代码实现，公司的领导层或许可以通过流程再造来改变业务逻辑。
因为现实世界的复杂性无法在代码层面消除，过度地抽象、解耦、套用设计模式反而会增加代码的复杂度。
关于配置文件
配置文件尽量保持简单直白，不要有分支或循环逻辑。分支或循环逻辑应该放到控制器里，因为控制器就是写业务逻辑代码的，改需求改的是控制器里代码，不变化的代码封装在模型里。配置文件里的配置信息应该是控制器的辅助，而不是相反。
由于外部环境的改变而经常跟着改变的变量值应该写在配置文件里，例如数据库配置信息测试环境一套，生产环境另一套，系统环境变量，要启用的进程数、线程数，公司名称、学校名称等，而不要把业务逻辑中的流程控制语句写在配置文件里。
总之，不要过度设计，不要过早优化，等版本稳定下来了再用设计模式重构代码也不迟。当然如果你的项目不缺钱也不缺时间，那么过早优化完全没有问题。
参考
https://github.com/nusr/hacker-laws-zh
https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity