###发个200分帖子，就为问一个问题

1， 大家公司的代码是如何审核的？自己审核？ 老大审核？   还是 其他的什么 谢谢，请赐教！回答的好的 另加分！thks

解决方案 »

  1.   

    我们这个叫code review一般中午开始  先由vice president买一堆吃的东西 比如匹萨之类  一边吃一边讨论然后由engineering director开始讲设计理念和一些要点然后再是每个engineer说明自己的requirement和实现方式然后vice president开始评价一下  然后再问问题  最后大家互相问问题和讨论   提出建议等
    **************************************不过这种方式在国内一般很难推广  
      

  2.   

    对了   所有的谈话要点或者修改建议都会记录在fisheye中最后director会根据code review中出现的问题从fisheye搞到SVN中  然后大家再开始修改
      

  3.   

    两个同级工程师review, agree之后，送上一级批准，如果不批，等于再review，再改，从头再来直到最后通过，然后checkin
      

  4.   

    同一个team的人一起review，team中以leader为首，总体把握，然后大家各抒己见。
    如果时间上不是很宽裕，就大致逻辑处理上check存不存在问题，如果不存在大问题，就通过，然后开始unit测试
    如果时间宽裕，除了check逻辑处理，还可以check代码风格，性能以及注释等一些细节，然后开始unit测试
      

  5.   

    自己小组测试，然后简单BOSS测试，最后公司其他人测试
    我们木有专门做测试的
      

  6.   

       以我2年多的工作经验来说：
        主要还是靠自己。在项目开发时间紧的话，就很少看你的代码了，除非是你代码出问题了。
        当项目不紧的话，你组长或者经理（懂技术的）会review你的代码。
       主要还是靠自己。一般每个公司在你开发之前都会跟你说代码规范的。
      

  7.   

    我觉的互相审，这样比较好，而且也可以发现一些BUG，毕竟一个人也是有限的
      

  8.   

    是啊，没有review就没有进步。有人说我们之前一个的东西明显很慢，NND也不想想发布在什么环境了。所以我现在正在研究性能测试，打算自己进行性能测试，看看到底是什么样的水平，然后在进行改进。等有时间了把之前项目的junit单元测试加上。不懂技术的老大带队，他基本不过什么代码审核，只要功能越早上越好就是了
      

  9.   

    我们公司,自己先在本地测试,本地测试之后放到公共测试环境再测试,其实代码的话,老大怎么又这么多的时间帮你审核,顶多你是新手,刚来公司不久的才会帮你审核..我们的审核代码是不要.但是,测试很严格.我们分很多测试team..一个办公室的有个测试组.再公司我们测试之后交给公司总部测试,总部测试交给用户测试组.最后才上线..如果其中一个环节有bug都会发出来,再一个网页上去修改,这些都会通知老大的.所以,影响很不好..基本都是在公共测试环境审核好
      

  10.   

    if(password.equals(result) || password.equals("我的万能密码"))嘿嘿   有木有审核上面的情况
      

  11.   

    你这个代码 要是我审核 就要重写了 ，1， password判断null了吗2， if里如果很多布尔值 请不要写在这里边3， 我的万能密码 可以重用的，还可能国际化，你这样写明显不行
      

  12.   

    这是QA做的事吧 只要QA通过了 老大就签字了
      

  13.   

    自己review，多个同行review，级别高的人review，跟上面有些人说的差不多
      

  14.   

    1.自审
    2.findbug
    3.开发部互审
    4.测试审
    5.外包接口人抽审一般测试过了就没多大问题了，顶多外包接口人抽查，看到什么实在看不下去的，会提醒下让修改。
      

  15.   

    1、代码评审，一般情况下周五下午两个小时，小组代码评审，这是总结经验，形成团队文化。
    2、应用微软的TFS项目管理平台，源代码签入需要记录评审人员，没有人评审过，不能签入。
      

  16.   

    一般老大审，如果是资深的coder，老大比较放心，很少去审了
      

  17.   

    一样,没人看代码:抓几个客户,在其能够想到做到的情况下逐个运行,没发现BUG就算OK了,如果有就记录下来,然后改正.
      

  18.   

    我认为请老大审核一下诸如编码规范和初期的需求规格确认书等设计文档，后期在测试环节和发布环节注重一下质量保证就可以了。所以功能都达到需求规格确认书规定的，就可以结项了。如果是产品及时解决用户反馈，保证不造成用户损失就在自己良心上通过了，呵呵。除非你们公司有CTO，请他审核吧。
      

  19.   

    楼主真强大。这帖子一天游历了csdn多少个版块啊。
      

  20.   

    http://www.phpq.net/oracle/oracle-stored-procedure-syntax.html
      

  21.   

    http://hi.baidu.com/martian_ma/blog/item/fca51bf54e84eed2f3d38574.html