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