标签：
最近负责的Android APP项目，由于团队成员变动、界面改版导致代码大幅修改等原因，产品发布后屡屡出现BUG导致的程序崩溃。
经过对异常统计和代码走读，BUG主要集中在空指针引起的NullPointerException和RuntimeException异常，这也是Android项目中最容易导致崩溃的根源。
导致这些BUG的原因主要是：
1、对项目架构不熟悉，缺乏整体思考；
2、写代码逻辑不周密，思考不全面；
3、对代码的BUG和程序的稳定性重视不足；
4、项目较为复杂，多界面跳转、数据结构复杂等。
仅仅在每次发版前对代码review的方式已经保障不了产品的稳定性。
代码出BUG是人为的因素，但不应该仅在人身上找原因。好的架构设计以及制度和工具保障，才能根本降低代码BUG。并且能在团队成员变动的情况下，做到稳步提高团队的代码质量。
在实践中总结出以下几点：
1、加强对BUG的重视程度，不能抱有侥幸心理；
2、利用APP的移动统计工具（目前我们使用的是百度移动统计）对运行期间出现的BUG进行分析；
注：百度移动统计中的错误报告可定位到发生BUG的代码行，对BUG处理非常方便，在产品测试期间也可充分利用；
3、产品发布前对代码走读，尤其是对没有经验和没形成良好编程习惯的新手编写的代码；
4、把代码走读中出现的错误不仅要修改，更重要的是记入checklist系统，最终形成积累；
注：这点非常重要，根据以往经验，如果仅仅是修改了事，重复问题还会出现，也无法在团队成员中进行信息的分享。
目前还没有相关的工具，前期checklist可以用word或者excel，通过SVN共享。今天用1个小时写了个简单的checklist，更方便团队成员查看。
形成的checklist可以在代码走读时对照list检查，可以避免犯重复性错误，随着checklist的积累，团队的代码质量也会稳步提高。
5、制定代码规约并严格执行，违反的问题记入checklist；
总之可以归纳为分析+积累+分享，没有checklist的积累，仅仅依靠团队成员的经验积累，是非常不靠谱的。
我用的checklist也非常简单，一个添加页面、一个列表页面：
添加页：
列表页：
标签：
原文地址：http://www.cnblogs.com/ym123/p/4206953.html
