 | 1 sinxccc Dec 22, 2012 相当靠谱。 另外不管忙到什么地步，其他所有的繁文缛节都可以丢，但代码 checkin 之前一定要经过两个或者两个以上人的 code review。追究责任的时候可以连 reviewer 一起追究。 |
 | 3 qiukun Dec 22, 2012 先画 NS 图 |
 | 4 xuwenhao Dec 22, 2012 @gfreezy 说得没错，no silver bullet，或者说 no free lunch，不考虑客观规律，直接来个进度第一，然后各种规律不遵守，加什么都是扯淡 |
 | 5 surfmanjoe Dec 22, 2012 @darasion 进度第一和大干快干100天提前完成任务一个性质，然后就做俯卧撑。 |
 | 6 tremblingblue Dec 22, 2012 正在经历的坑爹项目，连人都要被耗疯，平时写代码都会想多点再想细点，但现在想到就写，根本容不得一点重构或者反思的时间。更别说单元测试，review了。简直就是奢望。 |
 | 7 laihj Dec 22, 2012 走读本身是靠谱的，但贵团队是这种状况， ”各种业务忙来之后什么单元测试什么代码评审什么敏捷什么QA什么什么的，几乎就一下子不起作用了“ 估计最后走读也会就成什么什么之一吧 |
 | 8 kylefeng Dec 23, 2012 靠谱，如果比较懒就得有流程来保证了。 |
 | 9 wodemyworld Dec 23, 2012 项目嘛，只有“呵呵”最适合他 |
 | 10 greatghoul Dec 23, 2012 大部分时间，大家讲走读只是走形式而已，忙起来上面就会觉得这件事没有意义，然而跳过这一步的结果是后果是你买单。 哥们儿难道在华为么 |
 | 11 saturn Dec 23, 2012 业务繁忙、时间紧迫，能够作为代码质量低下的理由吗？能作为不遵守流程的理由吗？？？唯有从源头开始，提高大家的责任心、提升个人基础技能着手。 胡萝卜+大棒。 |
 | 12 fly2never Dec 23, 2012 pull-request,合并到主分支之前必须review |
 | 13 darasion OP 有没有好点儿靠谱点儿的成熟的流程可以借鉴呢？ |
 | 14 meta Dec 23, 2012  2 我见到的大多数国内软件公司都是这种情况，设计人员、开发人员、测试人员和维护人员的比例是0:100:0:100。 至少在我的行业里是这样。 |
 | 15 < href="/member/jesse_luo" class="dark">jesse_luo Dec 23, 2012 |
 | 16 wang2191195 Dec 23, 2012 相当靠谱+1，很多隐藏的BUG，能够被code review的同学看出来。。。表示自己实习的时候体会到了。。。 |
 | 17 gfreezy Dec 24, 2012 @wang2191195 除非review的人做的内容和被reveiw的内容一样，否则光靠两只眼睛根本看不出逻辑错误，最多也就是语法层面，或者是代码风格层面上的的问题，而这种类型的问题一般属于优化，也就是让代码可读性更好点，对于减少bug的作用没有想象中的那么大。 |
 | 18 cqust1 Dec 24, 2012 相当靠谱 |
| 19 wang2191195 Dec 24, 2012 @gfreezy 他们会脑补流程 对于边界值什么的 肯定有好处的~ |
| 20 gfreezy Dec 24, 2012 @wang2191195 其实我们每次合并前都必须发pull request，然后别人review后才可以合并。对代码质量的提高还是很有帮助的，一遍review看不懂说明要么逻辑过于复杂，要么函数名字没取好。 |
| 22 darasion OP 会不会有这种情况出现： 大家都不懂，或者因为不想改变的缘故，最后以某种有缺陷的传统做法当成好的做法推广；并且如果出现了更好的代码实现，大家都偏见的认为这种实现是有害的。然后将好的东西消灭在萌芽之中了。。。 |
 | 24 E2gCaBAT5I87sw1M Dec 25, 2012 rails这方面好点，一开始就是敏捷 |
 | 25 kneep Dec 26, 2012 via iPhone 其实可以参考开源软件的模式，一个模块能力最强的人每天就review各个小弟提交上来的patch |
Select Language