看了Expert Weekly Meeting Report
在讨论提高代码质量
讨论过程中,提出来一些方式,方法,Code Review也好，按照Bug数量奖惩也好，事后Bug分析也好，各种办法
质量是产品的生命线，必须搞好
我说说我的想法，希望大家都支支招，别Expert自己讨论的挺欢，毕竟大部分的代码都不是Expert来完成的
以下是个人观点，不对的地方，请大家多多批评：
1.总结Bug或者代码质量差的根本原因，也就是得有Bug分析，得用数据说话，直到咱们每一步，执行起来，能真正的解决多少问题，例如，如果是需求不明确，带来的问题，如果咱们把需求明确了，能解决百分之多少的问题，如果是技术能力不行，那么提高技术能力，又能解决百分之多少的问题，因为咱们资源有限，不可能解决所有的问题，只能先挑大头来，哪个性价比高，就先整哪个
2.Code Review：个人感觉，目前的Code Review，不是很必要，太形式化，另外Review的时候，都要看什么呢？能被安排独立开发功能的，都有一定的技术能力，区别基本上是好一点的写5行代码能解决问题，差一点，我写10行，也一样解决问题，运行起来的效果，没差到哪去。我觉得这个地方，Review一下代码结构和对于需求的理解，这个更有必要，PM和QA都可以参加，开发要描述自己的对于功能的理解，同时，这个功能要怎么样去实现，像 说的，有点答辩的性质，或者说有点招标的感觉(如果有一些不特定Team开发的，能不能拿出来，大家竟标)，答辩通过了，那么就按照这个结果继续做，答辩没通过，回去再准备，再来一轮，然后在以后的开发过程中，需要严格按照这个答辩的结果来做，代码里多加点comment，写出来一些文档跟踪，保留证据
3.即时需求理解的不对，那么做出来的东西，也不能有太多bug，目前开发过程中，给的需求和设计，没有那么细，比较粗糙，这样有难免在一些细节上，导致开发的理解和PM的理解或者客户想要的东西不一致，那么即使是这样，也不应该出现很多杂七杂八的低级bug，说白了，就是开发责任心的问题，写完的东西是不是认真测试了，就提交了，别说等QA测试，自己写的东西要负责的，开发当然需要做到心里有数，怎么样提高责任心，提高不了，有责任心的还是可能随着时间的推移，逐渐就没有了，没有责任心的，还是没有，怎么办，行政手段，不能说发现一个枪毙一个，但是一定要有足够的，足够有力度的，奖惩制度，别指望靠自觉，那都是扯淡的，没用
4.很多客户也在用咱们的产品，QA也在测试咱们的产品，咱们有很多Bug，必须要到客户那才能测试出来，回头QA一重现，还真能重现，原因何在？我这里没数据，不好说，摆在这，大家帮想想，这样的情况有还是没有，多还是不多
5.Expert讨论中，说道一个新代码和旧代码的问题，不管新代码还是旧代码，不管之前是不是你维护的代码，质量要求都是一样的，新代码不用说，旧代码之前的bug提出来，责任不在当前的开发，但是提出bug以后，bug改的质量，就是当前的开发应该负责的
6.有一个最根本的，减少bug数量的方法，就是少写代码，怎么少写代码，公用的方法，模块，工具类，都拿出去，除了维护公用部门的开发，其他开发就专注于自己模块逻辑的开发，其实可以注意到，逻辑上的东西，除非理解的不对，理解的正确了，写出来的东西，问题都不大，很多bug是开发要关注的地方太多，东一个西一个，没法专注在自己的业务逻辑上，说到这，有一点，一直比较奇怪，公司这么长时间了，怎么开发的D6的时候，都没有一个工具类什么的，拿出来一个像样的API这样的，常用的方法，大家查API，然后调用就行了，工具类什么的有，里面有什么方法，现在不知道，用的时候自己去找，有的找到了咱用一下，找不到自己偷偷写一个，哪天那个工具类一下改了，完蛋了，傻眼了，各种bug全出来了，试问一下，这么久了，在这方面没有一个积累和总结么？
转播
