量变引起质变

在做拉取巨量引擎广告数据时，本地开发时只拉取了近一个月的数据作为样本，将一个月的数据可能出现的问题都做了处理，但是当上线后拉取历史之前的历史数据时就出现了一些未考虑到的问题，比如某字段在历史数据里不存在的情况，还有部分功能由他人编码，在做集成时考虑不周全引起的异常问题，具有经验的人会考虑的比较多一些，这是经验的价值，有直接经验的人会处理的更好，我还需要时间来积累这些经验以及和他人学习获得这些经验。但也要注意具体问题具体分析，不要过分迷信经验的价值，那样容易落入经验主义和教条主义的陷阱中。

随着我们的业务发展，以前写个小脚本或者出个粗糙的方案就能解决问题，甚至这个方案在很长一段时间内还很好用情况会减少。因为量太小了，体量上达不到需要考虑那些问题的时候，当量开始增长变大，以前那一套行之有效的方法就会失灵，就会不奏效，甚至会拖累我们的生产力，这就是量变引起质变，当质变来临时就需要有制定新的方案，用新的代替旧的，以适应和解决新的出现的问题。当然也要注意尺度，过于超前的新也是不好的，会耗费巨大的精力和资源，但是得到的效果却平平，因为过于超前就意味着浪费，浪费的同时还需要巨大的精力和成本去维护我们用不到的部分，造成拖累。

回顾我们目前的上线制度的变迁就是这样，当我们的代码规模小，公司规模也小的时候，上线是一件全公司都知道的事情，而且上线的代码影响范围也小，即使上线后有影响都可以在线修bug，但是随着项目逐渐变多规模变大，上线后运行程序的容器规模增加，上线采用最开始那种方式已经不再适应新的生产力要求了，所以我们目前的上线制度就是因为量变引起质变后所制定的规则和方案，未来规模再进一步变大那么制度依然会更新，具体问题只有到了该解决的时候才会需要解决，如果在我们规模较小的时候采用这种上线方式那么实际上是对我们生产力的损害，但现在这种规模下这种制度不产生损害且是正向的作用。海尔的质量意识和日高日新也是因为要适应量变引起的质变而砸出来的，并不是一开始就凭空制定的。

这道理同样可以推演到单元测试，其实之前我们每个程序员都或多或少知道和了解单元测试，但是为什么实际写的人并不多呢，就是因为没到量，量还不足以引起质变，在没到量的时候按照大公司的那一套去写单元测试实际是对我们的生产力的损害，没到量而去做别人所谓的业界最先进的东西很多时候百害而无一利，这是一种彻彻底底的教条主义。一定要避免这种教条主义在我们生活和工作中的蔓延，坚持具体问题具体分析，一切从实际出发，实践是检验真理的唯一标准。