V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
darasion
V2EX  ›  程序员

代码走读这种事情靠谱吗?

  •  
  •   darasion · 2012-12-22 22:11:57 +08:00 · 6996 次点击
    这是一个创建于 4354 天前的主题,其中的信息可能已经有所发展或是发生改变。
    如题。
    想提高一批人对写出可靠代码重要性的意识。
    但是找不到什么好办法,各种业务忙起来之后什么单元测试什么代码评审什么敏捷什么QA什么什么的,几乎就一下子不起作用了,最后总是归结到进度第一。而且出了什么稳定性的事情还照样追究责任。。。

    怎样解决这些问题呢?
    25 条回复    1970-01-01 08:00:00 +08:00
    sinxccc
        1
    sinxccc  
       2012-12-22 22:18:25 +08:00
    相当靠谱。

    另外不管忙到什么地步,其他所有的繁文缛节都可以丢,但代码 checkin 之前一定要经过两个或者两个以上人的 code review。追究责任的时候可以连 reviewer 一起追究。
    gfreezy
        2
    gfreezy  
       2012-12-22 22:28:54 +08:00
    @sinxccc 一旦追究责任,代码review的性质就会发生变化。
    qiukun
        3
    qiukun  
       2012-12-22 22:49:16 +08:00
    先画 NS 图
    xuwenhao
        4
    xuwenhao  
       2012-12-22 22:52:24 +08:00
    @gfreezy 说得没错,no silver bullet,或者说 no free lunch,不考虑客观规律,直接来个进度第一,然后各种规律不遵守,加什么都是扯淡
    surfmanjoe
        5
    surfmanjoe  
       2012-12-22 23:03:49 +08:00
    @darasion 进度第一和大干快干100天提前完成任务一个性质,然后就做俯卧撑。
    tremblingblue
        6
    tremblingblue  
       2012-12-22 23:12:45 +08:00
    正在经历的坑爹项目,连人都要被耗疯,平时写代码都会想多点再想细点,但现在想到就写,根本容不得一点重构或者反思的时间。更别说单元测试,review了。简直就是奢望。
    laihj
        7
    laihj  
       2012-12-22 23:36:41 +08:00
    走读本身是靠谱的,但贵团队是这种状况,

    ”各种业务忙起来之后什么单元测试什么代码评审什么敏捷什么QA什么什么的,几乎就一下子不起作用了“

    估计最后走读也会就成什么什么之一吧
    kylefeng
        8
    kylefeng  
       2012-12-23 00:03:19 +08:00
    靠谱,如果比较懒就得有流程来保证了。
    wodemyworld
        9
    wodemyworld  
       2012-12-23 01:05:22 +08:00
    项目嘛,只有“呵呵”最适合他
    greatghoul
        10
    greatghoul  
       2012-12-23 09:29:17 +08:00
    大部分时间,大家讲走读只是走形式而已,忙起来上面就会觉得这件事没有意义,然而跳过这一步的结果是后果是你买单。

    哥们儿难道在华为么
    saturn
        11
    saturn  
       2012-12-23 09:51:48 +08:00
    业务繁忙、时间紧迫,能够作为代码质量低下的理由吗?能作为不遵守流程的理由吗???唯有从源头开始,提高大家的责任心、提升个人基础技能着手。

    胡萝卜+大棒。
    fly2never
        12
    fly2never  
       2012-12-23 10:54:07 +08:00
    pull-request,合并到主分支之前必须review
    darasion
        13
    darasion  
    OP
       2012-12-23 12:51:53 +08:00
    有没有好点儿靠谱点儿的成熟的流程可以借鉴呢?
    meta
        14
    meta  
       2012-12-23 13:16:08 +08:00   ❤️ 2
    我见到的大多数国内软件公司都是这种情况,设计人员、开发人员、测试人员和维护人员的比例是0:100:0:100。
    至少在我的行业里是这样。
    jesse_luo
        15
    jesse_luo  
       2012-12-23 16:31:04 +08:00
    @greatghoul 同问啊……难道在我司么……

    不过我们项目的走读做的不错,每一份代码都要由另外两个人做review。

    问题是要提高所有人的重视程度,要不然这种不关绩效的事情肯定是呵呵的……
    wang2191195
        16
    wang2191195  
       2012-12-23 20:22:30 +08:00
    相当靠谱+1,很多隐藏的BUG,能够被code review的同学看出来。。。表示自己实习的时候体会到了。。。
    gfreezy
        17
    gfreezy  
       2012-12-24 10:20:02 +08:00
    @wang2191195 除非review的人做的内容和被reveiw的内容一样,否则光靠两只眼睛根本看不出逻辑错误,最多也就是语法层面,或者是代码风格层面上的的问题,而这种类型的问题一般属于优化,也就是让代码可读性更好点,对于减少bug的作用没有想象中的那么大。
    cqust1
        18
    cqust1  
       2012-12-24 10:24:55 +08:00
    相当靠谱
    wang2191195
        19
    wang2191195  
       2012-12-24 10:52:40 +08:00
    @gfreezy 他们会脑补流程 对于边界值什么的 肯定有好处的~
    gfreezy
        20
    gfreezy  
       2012-12-24 11:36:40 +08:00
    @wang2191195 其实我们每次合并前都必须发pull request,然后别人review后才可以合并。对代码质量的提高还是很有帮助的,一遍review看不懂说明要么逻辑过于复杂,要么函数名字没取好。
    tyzc
        21
    tyzc  
       2012-12-24 12:46:08 +08:00
    @meta 顶!!!!
    darasion
        22
    darasion  
    OP
       2012-12-25 11:38:48 +08:00
    会不会有这种情况出现:

    大家都不懂,或者因为不想改变的缘故,最后以某种有缺陷的传统做法当成好的做法推广;并且如果出现了更好的代码实现,大家都偏见的认为这种实现是有害的。然后将好的东西消灭在萌芽之中了。。。
    zhfsxtx
        23
    zhfsxtx  
       2012-12-25 13:41:29 +08:00
    @meta 感同身受
    winnie2012
        24
    winnie2012  
       2012-12-25 18:10:30 +08:00
    rails这方面好点,一开始就是敏捷
    kneep
        25
    kneep  
       2012-12-26 17:46:13 +08:00 via iPhone
    其实可以参考开源软件的模式,一个模块能力最强的人每天就review各个小弟提交上来的patch
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1030 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 19:35 · PVG 03:35 · LAX 11:35 · JFK 14:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.