这是一种贯穿于编程中的概念，主要分为两类：价值观和原则。价值观是编程过程的统一支配性主题。关注与他人的沟通的重要性，把代码的复杂性去掉，并保持开发的心态。沟通、简单和灵活影响着编程时所做的每一个决策。原则不像价值观那样作用深远，原则是价值观和模式之间的桥梁。
在一次和许哥交流的时候也可以感受到，有时候代码复杂性降低不下去，可能是协议理解得不够透彻，考虑的角度被局限在当前的小模块了，用另一种方式或者其它的角度，代码的复杂度就降低了。
价值观
有三种价值观与卓越的编程血脉相连，分别是：沟通、简单和灵活。
沟通
在编程的时候，都会倾向于编写与计算机交流的程序，思考的角度也是从计算机的角度去思考的，这样很容易出现在一个函数里面，平铺的展开整个逻辑，各种判断条件和没有含义的语句。只有在编程的时候，考虑到他人的感受，才能够写出好的代码，在这种前提下，编写的代码才会简单易于理解，更有效率和清晰的表达想法。
其实软件的绝大部分成本都是在第一次部署之后产生的，着急的写出一些复杂，引入过多标志位，没有清晰结构的软件，可能会让你在某次比赛或者小打小闹的工具上获得收益，但是在庞大的软件下面它隐藏的bug，会让你吃尽苦头。其所消耗的人力和带来影响数倍于，前期充分思考带来的消耗。还有一点就是有些bug并不是测试能够测出来的。
简单
简单这个概念需要明确一点：就是对于一个将专业工具使用得得心应手的高级程序员，他所理解的简单，对于一个初学者来说（或者后期维护你的代码的人来说），真的比登天还难。在我们的系统上也是一样的，可能熟练掌握协议的两个人，即使平铺的把代码写出来，也能够轻松的交流，可是对于一个新人可能就是一头雾水了。
还有就是简单和代码的可沟通性是紧紧相连的，复杂的程序，往往会隐藏很多bug。
灵活
灵活是衡量低效编程和设计实践的一把标尺。
灵活性也需要明确一点（编程经验的重要性）：想象中明天或者会用得上的灵活性，可能与真正修改代码时需要的灵活性完全不是一回事。这就是简单性和大规模测试所带来的灵活性比专门设计出来的灵活性更为有效的原因。因为你可能觉得这个地方需要灵活性，增加了代码的复杂度，而实际上这一块，以后完全不会变动，完全没必要这么做。
原则
模式是在原则的基础上提炼出来的实践标准。我们在使用go语言的时候，不能拘泥于其它语言的编程习惯，应该使用更为契合的模式，或者修改相应的模式，体现语言的优势，规避语言的不足。
局部化影响
组织代码结构的时候，要保证变化只会产生局部影响。这里有个很简单的例子，就是为什么我们代码里面不让使用全局变量，稳态数据会好一点。但是那种在正常业务逻辑里面，有修改到全局变量的地方，在改起代码来，可能就需要我们对协议有更充分的理解，不然稍微一改，就挂一片alpha。
最小化重复
重复会增加代码变化的开销。很简单的一个逻辑，之前在重构编解码的时候，修改了300+的文件，这就是变化带来的代价。不过这是没办法的事情，接口的返回值发生了变化。不过在user在与itf之间的在封一层接口，就可以把itf带来的变化全部集中到一个地方。再就是我们代码里面不能直接访问平台接口的原因。
逻辑与数据捆绑
这也是局部化影响的一种，尽可能将这两个放到同一个方法中，退一步一个对象中，最后实在不行也要放到一个包下面。
对称性
写代码的时候，需要体现业务的对称性。就是withOi或者withoutOi这种，这样可以从函数命名上将其区分。
声明表达式
没理解，哈哈
变化率
就是我们在编写程序的时候应该将变化率一致的东西，组合到一起，变化率不一致的区分开。也是降低影响局部化的一种方法。
看一手代码：
setAmount(int value, string curreny){
this.value = value
this.currency = currency
}
// 可以改为
setAmount(int value, String currenct){
this.value = new money(value, currency)
}
// 再进一步
setAmount(Money value){
this.value = value
}