EEPW论坛

　　1、Code Review - 逻辑分析

　　当需要开发或者新增一些功能的时候，首先就是设计实现方案，然后开始编码实现。我觉得在开始编码之前，需要思考一下你的实现方案的逻辑。这个设计是不是合理的？能不能满足需求，有没有漏洞？在能想到的各种情形下是否能工作？和现有的其他逻辑是否能保持一致性。不要在你还没有像清楚逻辑合理性之前就开始编码。在思考这些问题的时候，你可能需要和用户沟通你的理解，和其他设计人员或者开发者沟通你对别人的相关逻辑的理解，尤其是和你的将要实现的功能有交互的功能逻辑。准确把握好这些问题之后，就可以开始实现了。

　　当然，一开始不可能完全回答这些问题，只能尽量，至少一些核心关键点要高清楚，不然，你的努力方向有可能是错的。所谓“方向比距离重要”，不要急于开始，一面南辕北辙。在编码和测试中，你还要回头对这些问题思考和论证。对于复杂的逻辑，最好准备一个笔记本，画下你的思考，便于回头分析和查看。

　　2、Refactor

　　重构有太多的好处，我想说的时候它能很好地提高你的代码质量，重构使得代码更为易读，能让你更好的review你的代码和逻辑，从而发现设计上的bug，及时解决。通过code review可以发现和解决很多在测试中无法或者很难发现的bug。反过来，如果代码设计的好，基本上没有什么是在测试的时候发现的bug在code review的时候发现不了的。

　　3、Unit Test

　　我说的Unit test，必须是自动化的测试。刚开始因为懒，或者时间紧，你可能不写测试，这其实就是欠下了债务，越往后，你越觉得没有时间，同时你又不得不靠手工加班去找bug，尽管你花了几个小时才找到的bug，可能一分钟就搞定了，那时就会捶胸顿足。

　　在测试的时候，你需要再思考你的逻辑，从API或者用户的角度去思考，同时还要重构你的代码，以易于测试。

　　想想看，在你的开发工作中，你的debug时间占据了整个时间的比例大概是多少。我们的开发活动大概是这样的：分析和确定需求，设计实现方案，编码，单元测试，集成测试。大部分programmer都工作在设计实现方案到单元测试之间。分析和确定需求主要由项目经理或者产品经理来做，当然dev也可以给建议。集成测试一般由QA来完成。debug活动存在于单元测试和集成测试过程中。对于单元测试，你采用手工测试，也可能采用自动测试。集成测试也一样。

　　在你做单元测试的时候，你会有大量的debug工作。在QA做集成测试的时候，他们会给你提bug，这时候你还要debug。如果再单元测试的时候，你能用10分钟发现bug，2分钟解决bug，那么如果这个bug是QA在集成测试的时候给你提出来的，并且是3天或者一周后才给你提出来的，你大概需要几十分钟debug来确定问题所在，然后还可能是2分钟就解决了。

　　所以说，bug大部分情况下好解决，但是难找，并且越早去找，越容易找到。这还没有算上因此blockQA的时间，重新部署的时间，还有沟通和重现bug的时间。这大概是为什么大家强调单元测试的重要性。

　　但我也不赞成写太多的测试，只写我认为比较复杂，比较重要的测试，我认为只要覆盖30%左右就好了。希望这30%的功能是用户在常用的那70%。