最近实现底层模块的升级的时候，颇费了一些周折。
回头看了下，底层模块实现的时候，还是应该遵循这个反直觉的原则：
要完全的把改动所涉及的所有模块cover住，在逻辑上确保相关所有模块在改动下都是正确的。
要不然呢？
上面说法应该是非常政治正确，在实际开发中又很容易被人舍弃的情况。
实际开发中，从产品到程序，都会有这样的倾向：最少改动，能少改少改。
这很符合我们的直觉，但是在底层方面是错的。
这点在经验中也常常成立原因是：
在大部分模块里，这样是ok的，但它ok主要是因为它牵涉的模块很少，最小改动在局部对了，就是对了。
另外人的惰性也是倾向于最小改动，在review和diff都会有一个更好的安全感（虽然是假的）。
并且人的惰性在大的工作压力下就更大，所以更倾向于最小改动。
底层情况
但是底层情况则是反的，它会影响很大，尽可能少的改动其实是影响很大的模块了。
正确做法就是：要完全的把改动所涉及的所有模块cover住，在逻辑上确保相关所有模块在改动下都是正确的。
一个造成更大消耗的case
这里也记录一个情况，现在各种开发量大，所以本能的希望处理的底层模块能够多快好省的弄好。
然后尽可能少改，改好了之后，QA报的问题，有问题就修bug，最后确实也把问题弄好了。
但是中间第一个bug起，就发现了之前没有考虑完全的点，其实就应该把相关所有模块彻底的过，修改所有改改的地方。
结果是报着少改，尽快结束战斗的心理，最后浪费了2倍的精力。
按部就班的打歼灭战
这个就是一个该有的开发状态，一来道理上应该知道该怎么做，二来面对工作压力，想迅速解决战斗的倾向，都应该保持一个按部就班的节奏，打歼灭战的原则。
因为这个就是最快的方式，其他的方式只表达了着急的态度，却采取了“把事情做的更慢”的行为。
依照原则行事
这里就很同意高效能人士里说的方式，依照原则行事，因为这个是在整体上更优的方式。
原则就是：像死歌一样，hold住全场
misc
一些零星的经验：
- 影响面大的改动，理论上会开始出现程序员hold不住的情况，这种情况，恐惧好于自信，尽可能延长团队QA和灰度的时间是一个好的策略
- 能灰度则都灰度