这是一个创建于 4340 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题。
想提高一批人对写出可靠代码重要性的意识。
但是找不到什么好办法，各种业务忙起来之后什么单元测试什么代码评审什么敏捷什么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
winnie2012 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