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

[darasion]

如题。
想提高一批人对写出可靠代码重要性的意识。
但是找不到什么好办法，各种业务忙起来之后什么单元测试什么代码评审什么敏捷什么QA什么什么的，几乎就一下子不起作用了，最后总是归结到进度第一。而且出了什么稳定性的事情还照样追究责任。。。

怎样解决这些问题呢？

[sinxccc]

相当靠谱。

另外不管忙到什么地步，其他所有的繁文缛节都可以丢，但代码 checkin 之前一定要经过两个或者两个以上人的 code review。追究责任的时候可以连 reviewer 一起追究。

[gfreezy]

@sinxccc 一旦追究责任，代码review的性质就会发生变化。

[qiukun]

先画 NS 图

[xuwenhao]

@gfreezy 说得没错，no silver bullet，或者说 no free lunch，不考虑客观规律，直接来个进度第一，然后各种规律不遵守，加什么都是扯淡

[surfmanjoe]

@darasion 进度第一和大干快干100天提前完成任务一个性质，然后就做俯卧撑。

[tremblingblue]

正在经历的坑爹项目，连人都要被耗疯，平时写代码都会想多点再想细点，但现在想到就写，根本容不得一点重构或者反思的时间。更别说单元测试，review了。简直就是奢望。

[laihj]

走读本身是靠谱的，但贵团队是这种状况，

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

估计最后走读也会就成什么什么之一吧

[kylefeng]

靠谱，如果比较懒就得有流程来保证了。

[wodemyworld]

项目嘛，只有“呵呵”最适合他

[greatghoul]

大部分时间，大家讲走读只是走形式而已，忙起来上面就会觉得这件事没有意义，然而跳过这一步的结果是后果是你买单。

哥们儿难道在华为么

[saturn]

业务繁忙、时间紧迫，能够作为代码质量低下的理由吗？能作为不遵守流程的理由吗？？？唯有从源头开始，提高大家的责任心、提升个人基础技能着手。

胡萝卜+大棒。

[fly2never]

pull-request,合并到主分支之前必须review

[darasion]

有没有好点儿靠谱点儿的成熟的流程可以借鉴呢？

[meta]

我见到的大多数国内软件公司都是这种情况，设计人员、开发人员、测试人员和维护人员的比例是0:100:0:100。
至少在我的行业里是这样。

[jesse_luo]

@greatghoul 同问啊……难道在我司么……

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

问题是要提高所有人的重视程度，要不然这种不关绩效的事情肯定是呵呵的……

[wang2191195]

相当靠谱+1，很多隐藏的BUG，能够被code review的同学看出来。。。表示自己实习的时候体会到了。。。

[gfreezy]

@wang2191195 除非review的人做的内容和被reveiw的内容一样，否则光靠两只眼睛根本看不出逻辑错误，最多也就是语法层面，或者是代码风格层面上的的问题，而这种类型的问题一般属于优化，也就是让代码可读性更好点，对于减少bug的作用没有想象中的那么大。

[cqust1]

相当靠谱

[wang2191195]

@gfreezy 他们会脑补流程 对于边界值什么的 肯定有好处的~

[gfreezy]

@wang2191195 其实我们每次合并前都必须发pull request，然后别人review后才可以合并。对代码质量的提高还是很有帮助的，一遍review看不懂说明要么逻辑过于复杂，要么函数名字没取好。