严谨求实——一次事故的复盘

最近在复盘一个问题时，发现自己在一个月前引入的问题，但是当时没有暴漏，打包脚本这块自己几乎没有接触过，但是对应的负责人的有不是太愿意交流，于是自己就修了打包脚本，运行起来没什么问题，就提交了，正式发版也没有问题。

大概过了一周之后（7月14）问题开始暴露，有同事反馈合了集成分支代码后，本地编译报错，已经在类styleable中定义了google的constrainlayout相关属性。我看了这个很可能和我的修改有关系，经过半天的排查终于找到原因，删除了宿主common中的constraintlayout-values，然后通过修改打包脚本，把各个插件的编译依赖了公共的constraintlayout的aar【这里其实自己不了解机制，看打包脚本的负责人这样修改我也这样改了，这里犯了错误，只看到其一没看到其二；打包脚本的修改提交没有测试也没有给该模块的负责人review，只是自己验证了下ok就用管理员权限合入了】
第二天（7月15）有同事反馈，本地编译正常了，但是线上打包后界面错乱，经过排查发现是因为使用了aar中的R，由于资源id被混淆，而aar内部使用时需要根据这心id进行查找对应的value，查找不到于是就出现了界面错乱。找到问题修复了。验证打包正常，并且对应同事的界面也正常，就大胆的直接合入提交了【第二次犯错了同样的错误】。

又过了一周（7月21），开始集成灰度，测试团队反馈同样的界面错乱问题，这使我感到非常意外，已经解决过了并且同时已经验证ok，为什么有出现了。为了排查问题和验证猜想，用不同的打包机进行打包，发现有一台打包机正常，其他打包机不正常，怀疑是，让负责打包机的同时把缓存清除，发现清除之后的打包机再次打包就正常了。我修改了constrainlayout引用方式，以及打包脚本的修改，以及把宿主原来的constraintlayout-values删除。

又过了几天（7月24），另外一个是事业部的同事发现有概率在打包机上打包失败，负责打包机的同时找到问我是否还有类似情况出现，我说没有了，测试没有反馈。

周一来了后（7月27）负责打包机的同事发现了正常和不正常打包机打包过程的差异，如果先打包宿主再打包出来插件没问题，但是如果先打包出来插件再打包出来宿主就有问题，有打包机正常，有打包机异常。负责打包机的同时说之前有遇到过类似的情况，原因是因为模块资源ID冲突导致类似的现象，通过插件中间产物 obf-androidfanxingmedia.jar 带了一个错误的 R.java 才导致会出现这样的问题，最终的解决方案是插件打包生成产物的时候过来constrainlayout的R打入插件，而是使用宿主的R。

整个过程持续了近20天，这个很不正常。流程上有很大问题，

对于自己不熟悉的东西，没有抱着敬畏之心，而是正常运行就直接提交合入，这个操作很不符合规范流程。一般插件方面的修改要给负责的同事review，给插件的专项测试同事测试，而自己对这个流程不熟悉或者说觉得正常跑通，没有搞清楚原因原理。

事后对这个事情也缺乏反思教训，感谢测试团队的同事对事实追求本源的态度，也让自己对去了解所以然以及不要钻空子，特别是对于自己不熟悉的领域。常在河边走，哪有不湿鞋，特别对于不严谨的人来说，就是九死一生。

本周在读《苏世民 我的经验和教训》一书，黑石集团的创始人在书中提到自己在雷曼兄弟工作时，因为一个标点符号使用错误被上司批评，然后排查和修正。严谨求实的态度打造黑石成为另类资产界的巴菲特。

小结：
面对不熟悉的领域，自己折腾学习时一定要找到该领域的牛人（负责人），了解和执行流程。
严谨的做事态度，减少不必要的损失，这在打造个人品牌，提升影响力中是非常重要的，否则很大可能凭运气成功，凭实力失败。以此为鉴。