进入新公司后，接手小程序3周，接连被”故障”强奸两次。
说实话，我到现在内心是崩溃的，甚至有点”恐惧”，一听到”故障”我现在都会手脚出汗。
不过遇到”故障”，必须要直面面对，这也是开发和成长的一部分，所以我必须选择一种直面应对”故障”的方案，因为只要我持续开发下去，肯定会有”故障”出现，但是我可以规避一些”故障”和快速发现一些”故障”。
(如果目前你也没有建立起”故障”的概念，我希望用过这篇文章能让你对”故障”产生一定的意识，因为这对于你以后可能会有所帮助。)”故障”，
在每个公司可能名称不一样。
我理解的”故障”是bug的升级版，一般在生产环境下发生的问题我认为叫做”故障”，而在开发环境下一般叫做bug。
以前所在的公司，因为用户消费行为比较少，对于”故障”的概念，并没有完整意义的理解，也不会引起代码本能的意识。
但是目前的公司，因为用户量和用户行为与消费直接挂钩，一旦发生故障，就会对业务产生影响。
故障一般都是从bug隐藏开始的，因为实际的生产环境和开发环境有着很大的不同，在开发环境下，不管是程序员本身还是测试人员，都不能够覆盖到所有的bug。
而在生产环境下，用户基数变大、场景变化以及设备多样性还有很多不定项的因素，这些因素都是在测试环境下很难模拟的。一经生产环境下一定用户的使用，就会触发bug，进而影响业务进行，升级为”故障”。
这也是为什么产品小步快跑，这样不仅可以验证产品本身的正确性，也可以在可控范围内查看产品本身是否就具有bug。
有必要说一下，在经历了这段恐怖的日子以后,我总结了几点规避”故障”和定位”故障”的经验
一 做好足够的经验储备
(是的 虽然你被强奸了，但是还是要写出你的经验！)
这一点我认为是最重要的，发生”故障”虽然恐怖但是可以容忍，
但是再次发生同样的”故障”这就是极大的错误和失败。
所以，每次发生”故障”，解决以后，你必须要做好文档和解决方案的编写，避免再次发生。
具体就是维护一个常见的”故障”库，每次进行”故障”review，都要写明”故障”的原因、发现、解决、规避的过程，形成文档这样也可以让这份文档，成为代码review、测试参考、编写规范的一部分，有效的规避出现同样的错误什么叫做专家？ 每行每业经验多了，踩坑填坑填多了就变成了专家。所以经验是很重要的，切记切记。
二 收集环境变量，所谓环境即用户使用的环境，确定这些环境是否发生变化。
(注意查看强奸现场, 保存证物)
比如，对于小程序而言，影响因素有很多，手机型号(iOS/Android)、手机版本(iOS10.0.x or iOS9.x)、微信版本(6.5.4/6.5.6)、小程序的SDK版本等。
我遇到的”故障”中，如果是在全量下发生的”故障”，基本上可以肯定是代码错误或者是逻辑错误，但是比较难发现和定位的基本上就是在特定机型或者特定版本上发生了”故障”，这点是很痛苦的。
比如在这个”故障”中，当你在输出超过4位时，只在Android 微信版本为6.5.6的下才会被触发，实际上很简单，只要修改value不再绑定test值即可，这个在MVVM中很容易出现的”循环绑定”，但是这个问题却在其他机型和系统上不会出现。
最后，才发现是因为前几天微信版本升级后，不再”包容”这个错误，然后点燃了这颗”炸弹”。
所以及时的关注这些环境变量，一旦发生环境变量变化，自己主动去验证在这种环境变量发生变化后，程序会不会发生”故障”，及时发现及时修正
三 做好版本管理，发生故障，切回上一个版本，看是否是在以往代码就已经存在，缩小”故障”点排查范围
(及时的摆正心态，应对强奸)
这一点，比较容易理解，不再展开。
四 做一个代码保守派
(大半夜，别出门。老老实实在家了，减少遇到坏人的几率)
尽可能使用流行方案编写你的程序，除非你想要尝试新东西，并且自己有足够的实力来进行维护新库。
新的代码库，可能引发一些未知的错误，所以如果业务面向的是用户，那么选择一种比较流行的代码库是一个明智的选择。可以参考github的star数，因为越是流行的代码库，遇到的问题、修复的问题、存在的问题都会被及时有效的控制，你也可以在相关issue或者社区中找到解决方案的答案，即使没有，你也可以提出问题，获取其他人的帮助。
反观新库，由于种种原因，可能不适合你在生产环境下使用，风险太大。
但是，对于你来说，如果发现一个新代码库比较好，可以尝试在平时关注和提出你的想法，维护和壮大这个库，来让大家更放心的使用。
比如小程序中使用”es6-promise”\在OC中使用AFNetworking\在PHP中使用TP\在Node中使用Express等
五 尽可能的自己测试
(多学一点防狼术, 遇到坏人，一招毙命)
这一点基本上公司是会提供支持，不管是QA，还是你需要的设备已经环境，可以和相关的人进行申请，不要认为这是在增加你的工作量，相信我，你越是测试的多，越是能保证你自己的工作进度和心情。
为什么不让QA进行测试？我告诉你，”故障”的直接责任人是你，但是你可以尽可能的陪同QA进行测试。
关于修复”故障”方面
不同技术有不同的方案
对于后端来说，代码可以及时的在服务器上修正或者回滚
对于前端来说，代码可以及时的在服务器上修正或者回滚对于
iOS/Andorid, 也有类jsPatch(不知道苹果爸爸还让不让用)的热修复方案
我举的几个例子，可能太多以小程序为例子，毕竟小程序是一个特例，发生故障后，时间修复问题的时间是不可控的，因为本身小程序不支持热修复和回滚版本。
但是对于小程序，我目前没有很好的方案来做一个bak方案，如果你有更好的方案，可以留言或者找我，非常感谢。如果代码强奸了你，别反抗别挣扎，尝试去享受.
201704061140:翻过珠穆朗玛峰，你还害怕阿尔卑斯山吗？
Di 订阅号“小码消息” - 或许，只有小码消息才可以拯救中国程序员
