大家平时做code review吗？


你意思是不是有bug也留着让做测试的人指出来？

解决方案 »

  1.   

    检查代码格式的规范性
    是否有明显的空指针异常等
    异常是否及时捕获，处理
    是否有魔鬼数字等项目很近的时候，赶进度，松一点的时候，搞代码质量
    进行代码检查，code review
      

  2.   

    实现一个功能后，开个会，把你思路讲解出来，判断是否思路有bug，根据思路讲解代码。如果都觉得没问题那就过
      

  3.   


    你意思是不是有bug也留着让做测试的人指出来？如果真有bug是要提交给coder的。但一般复查这种方式看不出来的，如果团队成员水平相近的话。所以基本也是到测试才能知道bug在哪
      

  4.   

    §代码审查，应该做的几件事儿1）正确性
    是否满足客户需求
    是否和需求分析以及设计资料的内容保持一致
    一致的意思：不仅要求功能正确，而且要求完备极值（最大值、最小值、特殊值（比如0、负数、null、NaN）、异常值（字母、回车/换行等控制字符））等等特殊情况是否都已经被考虑到了，这些情况下程序的动作是否满足需求
    还有哪些情况没有被考虑？没有被实现？2）结构性
    现在的功能加入到系统后，
    对整个系统有什么好的影响，
    以及不好的影响（程序员一般都过于乐观，这点可能需要第三者帮着冷静的分析一下才行）以后再追加新的功能时，是否可以不大改结构就能够实现，千万别“将就”3）易读性
    换一个完全不懂这个系统的人，是否能通过代码立即理解原作者的意图（需要代码审查者把自己假想为一个完全的新人才行）推敲一下，是否有过多的不必要的注释：
    经年累月后，人们逐渐发现，只有代码本身才可以真正被信赖
    最小限度的注释，以及自说明的代码才是最好的方式
    1次书写N次阅读，多站在今后的阅读者的立场上考虑问题关心一下系统日志（log）：
    当出现Bug时，可以很容易的分析出是哪里出了什么问题吗？
    如果写代码的人自己都不能分分秒知道问题出在哪里，还能指望谁？
    例：
    看系统日志知道是系统运行时发生异常造成系统崩溃了
    log应该分分秒告诉你：是谁的问题？什么异常？什么时候发生的？哪里出的？为什么会出？怎么解决？（5W1H）4）性能
    有没有更好的，更合理的实现方法性能等是否有问题、有没有内存泄露、资源泄露等用测试的手法也不易发现的问题§代码审查，不应该做的几件事儿1）通过工具能够自动检查的问题
    比如项目组的编码规范不允许使用TAB，而需要统一使用空格来进行缩进
    这样的检查如果人工来做的话，会花费大量不必要的时间
    还好有Eclipse Checkstyle这样的自动工具代码审查时仅需要确认一下Checkstyle的检查是否实施
    所有的检查结果是否都是OK的
    如果有NG的地方，是否是被允许的
    是否需要更新Checkstyle的规则2）通过简单测试就能够发现的问题
    比如系统是否能启动起来，大体上的功能是否已经实现
    如果这些最基本的问题还没有解决的话，直接开代码审查就是在浪费时间3）过去经常发生，或者已经经常指出的问题
    网上有很多成型的东东，可以参考这些问题可以通过Check List的形式，让开发人员做自检
    并把检查结果报告给代码审查的责任人
    可以每次考察Check List中不同的一两项，来确认开发人员已经充分理解自检的目的
    比如：参数是否为null的判定，除数是否为零的判定，异常处理等最基本的需要注意的问题如果之后发现了Bug，一定要考虑是否需要更新Check List以杜绝发生相似的问题
    另外，如果Check List已经不能发现任何问题的话，
    可以考虑分类（新加入项目组的开发人员使用的，以及成手使用的），以节约成手的时间总之，这个东东最好小而强大，没用的东西要定期删除原创，转发请注明出处
      

  5.   

    code review很多公司都说要做，但都做得不好。
    其实真正做好code review对提高品质是很有帮助的。我觉得应该一如既往的做下去，而且要保证做好。
      

  6.   

    一般是自己做~
    有BUG对谁都不好嘛~
    我主要是来接点分的~
     
      

  7.   

    老板才是code review的最大敌人