之前看小米的"一块钢板的旅程"，我就想从代码的旅程展开说说。不同于从项目流程展开，测试流程展开，那么如果产品大部分bugs都代码引入的，我们不妨就从代码的角度展开来说。而工具是提炼了规则，流程，能力的，所以我会用工具来说明能做的事情。通过这个角度，不是想说，大家就用那些工具吧， 而是工具的思路，我们除了在测试环节去建设工具之外，还能做什么。

源码开发，对于代码来说，应该就是它出生的一刻。能做的事情无非两样，1，组件：用现成代码来减少问题, 优化代码质量，2，自测：用工具在本地测试新代码来保证没问题。先说组件，现成的代码能提供什么？1.快速可维护的代码，如butterknife; 2.更佳的性能，如Fresco更高性能的图片缓存和展示机制, okhttp支持spdy，io性能更佳的http操作api ;android-Iconics 在android使用iconfont，svg，减少安装包大小；3. 集中管理，eventbus提供更佳的回调机制，当然它不算是集中管理的经典，但是因为其使用的方式也起到了集中管理的作用。我更想指的集中管理是例如，我们可以建立一个线程管理器，全部的线程实例都从这里获取，如果某些优先级极高的操作，我们可以统一降低其他线程优先级; 4.避免错误, 如android-weak-handler。

然后就是自测，因为是源码开发阶段，所以最好要跟IDE结合，在ide输出结果。这类东西android studio就提供了跟lint静态检查的能力，分析cyclic的能力等等。像微软这类公司，如果没有跑fxcop，stylecop连check in都不行，甚至结合svn hook来做强制检查，不符合就不让check in。当然这种自测还包括了借助工具的code review， 这里就不多介绍了。

补充一句，源码开发是最容易被忽略的环节，无论是开发集成到ide的插件，高性能的库都会非常高效率地提升质量，而且会有以点打面的作用。

集成编译

，这个阶段有什么特别的？有，它是代码与功能信息连接的地方。除了编译打包工具，如gradle，ant，NativeLibCompression等优化打包压缩工具之外，还能做测试，这里的测试跟后面的测试调试大有不同。正如上面提到的，代码与功能信息连接的地方，利用测试工具来测试功能，配合代码信息，就能更佳精准地执行测试，定位问题。举个简单的例子，这里可以做基于代码增量信息的instrument单元测试，uiautomator等自动化测试，lint、findbugs、infer等静态检查，也可以让刚刚提到的测试结果与svn diff的结果结合，进而定位问题。这时，不得不说所谓“天下武功唯快不破”也在这里可以体现，如果可以做到每ci就编译集成（持续集成），每次集成测试都可以在10分钟（人的注意力高度集中时间就是10分钟）内完成测试，那么定位就可以在每个check in，甚至可以做到没有集成通过就不让check in。要做这个事情，这些编译，测试，静态检查都必须快起来，什么分布式，并行计算等等都不是理想，而是真真切切的需要。再拓展下大家的想象力，哪怕是Monkey测试，如果能快起来，5分钟完全上百个界面的遍历，那么它也能被持续集成容纳，也能利用版本之间的svn diff信息来强化问题定位了。

测试调试，这个阶段时是大家最不容易遗忘的，80%的精力都在这里，建设的工具也最多。这里的工具两类，度量类的和分析类的。之前我写过一篇《假如不是BAT,专项测试怎么做》，里面就提到过。这里不想多说，简单介绍几个特别的，思路可以借鉴和拓展的，

1. tPacketCapture手机无root抓包，这个应用的特点就是用了vpn的方式来配合抓包，大家仔细想像，当大家头痛为什么要root了才能抓包的时候，有木有想过这个思路呢？ 在这个思路底下，纯手机端的无root的弱网模拟，盖包，丢包，都不是梦呀。

2. MAT，LeakCanary，AllocationTracer，android-hprof-tools，dumpsys meminfo这些都是内存测试分析的工具。一大堆工具，能给我们什么思路呢？我们不妨从程序，代码，时间，规则这三个维度来看待我们的工具，android-hprof-tools优化抓取hrof速度的，与MAT快照分析配合使用，获取的信息是静态的代码信息，例如MAT获取是类名，对象数，引用关系等，这里没有时间的概念和信息，但是在代码之上，可以分析问题。而AllocationTracer就是在代码信息上，加上了时间的概念，可以称为动态的代码信息，这里分析的问题就必须跟时间是相关的，例如GC, 垃圾回收触发的时机对程序流畅度的影响。另外一个维度，隐匿了代码的信息，那就是程序的信息，这里top，meminfo，gc日志是代表，主要用来发现问题，因为相对轻量，持续时间可以更长。最后就是规则，在代码信息之上融合了规则的测试工具，会自动发现问题，最经典的就是leakcanary了。按照这个思路，大家不妨可以想想其他的专项工具，不要觉得没得想，最起码现在看来“代码＋时间＋规则” ＝ allocation tracer + 规则的工具，起码我至今还没有发现。

发布运营，发布就是研发流程外了，我们的质量保证不是应该在研发流程内彻底保证么？事实上，臣妾做不到呀。用户环境很复杂的，就以上次有个同学问我，国际网络测试要怎么办。我也只能厚着脸皮说，发布运营上做文章，做可以定位问题的数据上报。没错，研发流程内可以做一些相关质量保障，但投入产出比太低了，想想，难不成你要飞去美国做测试，当然，方便一点的就是买deviceanywhere的服务来做测试。如果能考虑灰度发布，那事情就简单多了。一方面，可以用applause提供的众测服务。另一方面，光“测”不够，因为在远端定位问题是充满悲剧的事情，必须要有远程定位问题的能力。定位信息有了，那征服“自定定位分析”，那为什么不动态运营一把呢？ 最经典的就是网络路由出口的问题，不同出口的网速到不同的地方，不同的运营商，天差地别，如果发现a出口不行，是不是自动动态划同一区域同一运营商可以试一下b出口呢？如果可以，是不是可以动态调整过来呢？这里有太多太多事情可以做了。上面说的必经是网络策略，那除了网络之外，对于功能，可以用ABTest, 如facebook的airlock, 监控工具可以用众多的APM(此处不列举）， 有bug可以用hotfix工具nuwa。

总结，容易遗忘的源码开发：效率最高；唯快不破的编译集成：联合代码信息；用力最多的测试调试：时间＋代码＋程序＋规则；发布运营：创造最接近用户的测试调试环境。

PS: qcon2016, 再次去了，分享的题目就是大家遗忘已久但大有可为的Monkey, 大家多多关注