[OT]关于代码的管理
fuyu0123456789
alexliyu2012
在 11-8-24，fuyu0123456789<fuyu012...@163.com> 写道：
> --
> 来自: python-cn`CPyUG`华蟒用户组(中文Python技术邮件列表)
> 发言: pyth...@googlegroups.com
> 退订: python-cn+...@googlegroups.com (向此发空信即退!)
> 详情: http://code.google.com/p/cpyug/wiki/PythonCn
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> 强烈: 建议使用技巧: 如何有效地报告Bug
> http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
>
--
娱讯（厦门）文化传播有限公司 李昱
电话： 0592-5166918
传真： 0592-5166755
E-mail：l...@eiimedia.cn （Work)
E-mail：alexli...@gmail.com (Personal)
QQ: 939567050
地址：厦门市禾祥东路138号鸿运大厦裙楼4楼
FoxMessire
呵呵，人数较少的话，你就有点像消防员了，哪里冒烟都要你
要注意系统风格、界面、设计上的统一。这样也方便后继的工作
我念书的时候给联想做过项目，6人，1年，8个较大的子系统，需求超复杂，且变动频繁，很折磨人
代码管理可以用svn之类的，缺陷跟踪bugzilla。没有专门测试人员的话就让开发根据需求自测
从coder像管理者转变，还是要跳出coder的思维，要从大方向综合考虑，没必要考虑模块的功能代码怎么实现
以上愚见，希望有帮助！
FoxMessire
limodou
要几个人主要看手头的工作有多少，都需要什么样的人来做，自已有没有能力做下去。如果时间进度可以自行安排，自已也有能力做，倒也不一定要很多人。但如果工作比较多，更希望有些人专门做一块，可能随着分工，需要的人就会更多一些。
5-6的代码量一个人差不多也可以搞定。当然如果什么都做，人多一些分工明确一些可能更好。但一旦进人就要想清楚，你和他们的工作分工和定位，不然不好管理。
--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://code.google.com/p/uliweb/
My Blog: http://hi.baidu.com/limodou
jamiesun
王光
Zoom.Quiet
> 个体和交流胜于过程和工具。
- 我们也承认后者很重要
敏捷宣言里说的很明白
> 我也曾经很热衷于各种工具，但后来我真正发现很多事情做的不够好其实是因为沟通交流不到位。
>
- 问题是,在充分沟通后,团队良好的協同习惯,你总得有称手的工具固化下来
- 否则,人员一流动,很容易冲没的
所以,包含优秀管理思想的轻便工具,比团队内部痛苦的反复摸索要靠谱的多
- 因为,工具,都是靠谱经验的凝聚,,,
> 在 2011年8月24日 下午12:21，limodou <lim...@gmail.com>写道：
>>
>> 2011/8/24 fuyu0123456789 <fuyu012...@163.com>:
>> > 刚来新的部门的时候，部门里面什么都是人工来做的。
>> > 慢慢的，我做出许多自动化的系统来自动计算和生成各种报告，还有规范工作流程的系统，提高个人工作效率的小工具，等等等等。
>> >
>> > 东西一个一个的做出来，问题就来了，首先是来不及做，所以现在又招了一个人。后来部门的老板升VP了，手下又多出几个部门，可能计划都要推行这些系统，工作量肯定会上来。
>> >
>> > 我们到目前为止，大概做了30多个系统，大的大概有4000到5000行的代码量，小的也就100多行（多亏是Python，要用其他语言，一定远远不止！）总的代码量在5万到6万行。随着用这些系统的人越来越多，对现有系统的改进要求源源不断的提出来，要求做新的系统的要求也不少。而且有些系统之间还有联系。还要整合。
>> > 我们现在是2个人做这些事情。
>> >
>> > 我想问的是这个工作量和代码量，到底需要多少人来管理？人手的分工是怎么样？有什么好的系统或者方法来高效的进行管理吗？没在软件公司做过，一直都是自己野路子在干，自己有些编码动手能力，但是一牵扯到管理就菜了，都不懂。
>> > PS：今早从上班到现在，加上老板，有5个人来和我讨论问题，一上午又过去了，根本没写几行代码，很怀念过去简单的日子啊。
>> >
>>
>>
>> 要几个人主要看手头的工作有多少，都需要什么样的人来做，自已有没有能力做下去。如果时间进度可以自行安排，自已也有能力做，倒也不一定要很多人。但如果工作比较多，更希望有些人专门做一块，可能随着分工，需要的人就会更多一些。
>>
>> 5-6的代码量一个人差不多也可以搞定。当然如果什么都做，人多一些分工明确一些可能更好。但一旦进人就要想清楚，你和他们的工作分工和定位，不然不好管理。
...
--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/
Zhang Jiawei
如果你能力超强，欢迎独裁。
交流，讨论什么的，最浪费时间了。
--
X.C Sam
���ҹ�ͬ����ʵ��������˲��٣�
�����������ǿ����ӭ���á�
����������ʲô�ģ����˷�ʱ���ˡ�
�� 2011��8��24�� ����9:10��Zoom.Quiet <zoom....@gmail.com>д ����
- ����Ҳ���Ϻ��ߺ���Ҫ
����������˵�ĺ�����
> ��Ҳ��������ڸ��ֹ��ߣ��������������ֺܶ��������IJ�������ʵ����Ϊ��ͨ��������λ��
>
- ������,�ڳ�ֹ�ͨ��,�Ŷ����õąfͬϰ��,���ܵ��г��ֵĹ��߹̻�����
- ����,��Աһ����,�����׳�û��
����,���������˼�����㹤��,���Ŷ��ڲ�ʹ��ķ�������Ҫ���Ķ�
- ��Ϊ,����,���ǿ���������,,,
...
> �� 2011��8��24�� ����12:21��limodou <lim...@gmail.com> ���
>>
>> 2011/8/24 fuyu0123456789 <fuyu012...@163.com>:
>> > �����µIJ��ŵ�ʱ��������ʲô�����˹������ġ�
>> > ����ģ�����������Զ�����ϵͳ���Զ��������ɸ��ֱ��棬���й淶�������̵�ϵͳ����߸��˹���Ч�ʵ�С���ߣ��ȵȵȵȡ�
>> >
>> > ����һ��һ��������������������ˣ�������������������������������һ���ˡ��������ŵ��ϰ���VP�ˣ������ֶ���������ţ����ܼƻ���Ҫ������Щϵͳ���� �����϶���������
>> >
>> > ���ǵ�ĿǰΪֹ���������30���ϵͳ����Ĵ����4000��5000�еĴ�������С��Ҳ��100���У������Python��Ҫ���������ԣ�һ��ԶԶ�� ֹ�����ܵĴ�������5��6���С���������Щϵͳ����Խ��Խ�࣬������ϵͳ�ĸĽ�Ҫ��ԴԴ���ϵ��������Ҫ�����µ�ϵͳ��Ҫ��Ҳ ���١�������Щϵͳ֮�仹����ϵ����Ҫ��ϡ�
>> > ����������2��������Щ���顣
>> >
>> > �����ʵ�������������ʹ�������������Ҫ�����������?���ֵķֹ�����ô����ʲô�õ�ϵͳ���߷�������Ч�Ľ��й�����û�������˾����һֱ�����Լ� Ұ·���ڸɣ��Լ���Щ���붯������������һǣ��������Ͳ��ˣ���������
>> > PS��������ϰൽ���ڣ������ϰ壬��5�����������������⣬һ�����ֹ�ȥ�ˣ���ûд���д��룬�ܻ����ȥ�����Ӱ���
>> >
>>
>>
>> Ҫ��������Ҫ����ͷ�Ĺ����ж��٣�����Ҫʲô�����������������û����������ȥ�����ʱ���ȿ������а��ţ�����Ҳ������������Ҳ��һ��Ҫ�ܶ��ˡ������ �����Ƚ϶࣬��ϣ����Щ��ר����һ�飬�������ŷֹ�����Ҫ���˾ͻ���һЩ��
>>
>> 5-6�Ĵ�����һ���˲��Ҳ���Ը㶨����Ȼ���ʲô�������˶�һЩ�ֹ���ȷһЩ���ܸ�á���һ�����˾�Ҫ�������������ǵĹ����ֹ��Ͷ�λ����Ȼ���ù� �?
--
������, Pythonic! �����,���ӱ¹�!���ݲ���,ʮ����!
��: http://about.me/zoom.quiet
������: http://creativecommons.org/licenses/by-sa/2.5/cn/
--
����: python-cn`CPyUG`�����û���(����Python�����ʼ��б�)
����: pyth...@googlegroups.com
�˶�: python-cn+...@googlegroups.com (��˷����ż���!)
����: http://code.google.com/p/cpyug/wiki/PythonCn
����: ����б�! �ǻ�����! http://wiki.woodpecker.org.cn/moin/AskForHelp
ǿ��: ����ʹ�ü���: �����Ч�ر���Bug
http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
--
����: python-cn`CPyUG`�����û���(����Python�����ʼ��б�)
����: pyth...@googlegroups.com
�˶�: python-cn+...@googlegroups.com (��˷����ż���!)
����: http://code.google.com/p/cpyug/wiki/PythonCn
����: ����б�! �ǻ�����! http://wiki.woodpecker.org.cn/moin/AskForHelp
ǿ��: ����ʹ�ü���: �����Ч�ر���Bug
http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-cn.html
pansz
> 不敢苟同。
> 如果你能力超强，欢迎独裁。
> 交流，讨论什么的，最浪费时间了。
>
正因为交流和讨论，浪费时间，所以才需要工具。正因为要独裁，所以才需要工具。
举个简单例子：假如存在一个编码规范，要求所有人遵守，如果不靠工具，那么每来一个新人，就得宣读一遍，介绍一遍，尝试N遍。然后他还未必掌握。
如果靠工具，扔一个自动检查工具，然后一句话：这玩意检查通过的代码才能提交！解决完毕。然后整个世界清静了。
zong
郁夫
如果企业的IT不定位在管理层级，哪可是够苦的。
Zhang Jiawei
何况，这么搞太扼杀创造力了。大牛的代码岂是什么自动检查工具可以理解的。
--
pansz
> 恐怕这么做的结果是，提交不了代码。
>
> 何况，这么搞太扼杀创造力了。大牛的代码岂是什么自动检查工具可以理解的。
你干脆说 google 无大牛算了。google 是代码审查最严格的公司之一。
jamiesun
pansz
> 并不是完全反对工具，也不是把工具和交流对立起来。
> 重要的是，如何去选择，还要不停去探索更有效的方式。
任何行为，过犹不及，这基本是废话，正如吃饭是好，吃多了总归要撑死。
"过度"交流跟"过度"工具，都不好，这本身根本无需讨论。
但是工具的价值在于它能够更完备的传达一种“执行力”。
管理者的决策本来需要N个人花N多时间去贯彻，但是使用工具可以使他们得到完整贯彻的同时，解放你的一部分人力资源。——所以工具的运用对于一项成熟的决策来说可以加强其执行力。
同样是N项决策，你对其中几项使用工具，能够空出一部分管理人员来使你其他的决策得到更好的贯彻。最终，使你全部决策的执行力达到更好。因而，工具本身是为决策服务的，它是贯彻执行力的办法，前提是你没有足够多的人手来贯彻你的决策。
如果你能够养大量的管理人员，亲力亲为的去交流，去贯彻和执行所有的管理决策，那你确实是可以抛弃工具。不过你付出的人力资源成本也非常高昂。
一个不成熟的决策前期，需要修补和改进，沟通交流是最好的办法，但是当它成熟走上正轨，用工具去固化执行力，解放管理人员来进行新的决策与执行，确实是被证明最有效的办法之一。
Zhang Jiawei
审查最严格，我看还是 code review 做的最严格吧，至于工具，不必当真，查查基本语法错误也凑合了，再高级的，还是要靠肉眼。
--
pansz
> 审查最严格，我看还是 code review 做的最严格吧
code review 的中文就是 代码审查 。
很多代码审查工具都是 google 做了流传出来（或者没有流传出来）的。C/Java/Python都有。
何洋
Rujia Liu
> 这样的会议听起来很好，但是感觉很难存在啊。我刚参加工作，基本上每周要开2-3次打酱油的会议。。。
看公司管理了。我们公司的会议几乎全部是这样。以前我给部门开例会的时候，就被老板批评过，认为效率不够高（虽然我只开了10分钟）
- Rujia
赖勇浩
> 恐怕这么做的结果是，提交不了代码。
>
> 何况，这么搞太扼杀创造力了。大牛的代码岂是什么自动检查工具可以理解的。
我们使用 review board 强制人肉审查，
但也有 pylint 强制执行代码规范。
--
web site：http://laiyonghao.com
twitter: http://twitter.com/laiyonghao
OnMyWay
高深的大牛是对架构,对需求的准确把握, 这些用文字即可表达.
工具并不是用来检查代码的, 是规范你检查代码的. 如果你要提交代码,需要leader做一个code review,如果他在数据库上没有记录，那么你是提交不了的。
在 2011年8月25日 下午12:56，Zhang Jiawei <gho...@gmail.com> 写道：
--
提供定制Clearcase脚本服务。
lu_zi_2000
��ʵ����һ��������˵,����淶��Ҫ,����Ҳû��Ҫ�����Ϲ淶�����ij̶�.
һ����������Ҫ�Ķ�����ʵ�Ǽܹ�,�����,���㷨,������,��Щ������ĺ���,д
�������ֻҪ��Ѱ��Ϊ�?�Ĺ淶,����ϸ������������������ �ַ�ʽ,�ͺ���.
��˵�淶����,��Ȼ�ǹ淶,���кܶ������ԵĶ���,������������Ա����ô��,��
��������������ʹ�õĵ����Ҳ��ô����,���Dz������Ĺ淶, ������������
���Ĵ�����,����Ҳ�ܺ�.
����������˵�Ľ���,����淶,Ҫ���ıȽϿ?��,������˶����Խ��ܵ�,����
Ҫ��,����ǿ��.ֻҪ�γ��Լ��Ĵ�����,�ͺ���.
�ù����������,���Ϲ�������鷳��������,�ο�����.
On 2011��08��26�� 10:26, OnMyWay wrote:
> ������ύЩϡ��ŹֵĴ���, ��ô��"��ţ"��ı�߾���.
>
> ����Ĵ�ţ�ǶԼܹ�,�������ȷ����, ��Щ�����ּ��ɱ��.
>
> ���߲����������������, �ǹ淶��������. �����Ҫ�ύ����,��Ҫleader��һ��code review,���������ݿ���û�м�¼����ô�����ύ���˵ġ�
>
> �� 2011��8��25�� ����12:56��Zhang Jiawei <gho...@gmail.com> ���
>> ������ô���Ľ���ǣ��ύ���˴��롣
>>
>> �ο�����ô��̫��ɱ�������ˡ���ţ�Ĵ�������ʲô�Զ���鹤�߿������ġ�
>>
>> �� 2011��8��25�� ����10:06��pansz <pan.s...@gmail.com>���
>>> 2011/8/25 Zhang Jiawei <gho...@gmail.com>:
>>>> ���ҹ�ͬ��
>>>> �����������ǿ����ӭ���á�
>>>> ����������ʲô�ģ����˷�ʱ���ˡ�
>>>>
>>> ����Ϊ���������ۣ��˷�ʱ�䣬���Բ���Ҫ���ߡ�����ΪҪ���ã����Բ���Ҫ���ߡ�
>>>
>>> �ٸ������ӣ��������һ������淶��Ҫ�����������أ�������ߣ���ôÿ��һ�����ˣ��͵����һ�飬����һ�飬����N�顣Ȼ����δ�����ա�
>>>
>>> ����ߣ���һ���Զ���鹤�ߣ�Ȼ��һ�仰����������ͨ��Ĵ�������ύ�������ϡ�Ȼ����������徲�ˡ�
Zhang Jiawei
肉眼是第一位，工具不能告诉你一个排序算法的时间复杂度。肉眼可以。
Zhang Jiawei
至于你说的工具，最多叫做 syntax checker.
--
Zhang Jiawei
Rujia Liu
log，发现问题找人改，也可以用reviewboard把code review贯彻得更细。
可能你所指"工具"并不包含reviewboard这样的？
2011/8/26 Zhang Jiawei <gho...@gmail.com>:
pansz
> 我觉得你理解的"工具"的范围和前面几位有所不同。同样是肉眼去看，可以规定每个人提交之前叫谁谁谁过去用肉眼看，也可以让谁谁谁每隔一段时间自己去检查commit
> log，发现问题找人改，也可以用reviewboard把code review贯彻得更细。
>
> 可能你所指"工具"并不包含reviewboard这样的？
可能他不能理解 reviewboard，或者象 todo-list, checklist 之类的东西也是工具。肉眼审查这事，一般是需要发个
checklist 之类的东西的，这玩意也是工具。
Zhang Jiawei
1. 和你的branch做绑定，看到每一个人的每一次change list.
2. 可以每两周发起一次review, 邀请不同的人，甚至公司的架构师来查看代码。还可以看到每个受邀者，在这个工具上停留的review时间。
3. 可以在没有开发环境的机器上，直接用网页来code reivew, 还可以在那个网页上编辑review的意见。留下意见以后，可以会自动发一个邮件通知写代码的人。收到邮件的人可以再次回复这次的意见。
4. 可以只看和上一个review请求之间不同的代码段。
5. 它是web的，真 tm 牛阿，只要你愿意，你可以在喜马拉雅上做code review阿！
还有很多好处我也记不全，如果你不知道什么是crucible, 你也可以去google。
领导很喜欢这种的东西，洒家最近还因为这种东西，在公司邮件里被整个开发部门的美国总教头点名批评：为啥你被邀请了，但是review时间是0呢？你看那几个架构师，他们都花了2个小时review你的code了。
What's a fucking day !
但是这种收费的商业工具没有在领导付钱以前告诉他们这种东西不能干什么。他们不能干什么呢？
他们不能在网页上在函数间做跳转，你没看错，真的不能。所以他们既不能看一个被调用函数里面写了什么，也不能看一个函数被哪些外部方法调用。你需要自己肉眼去搜索跳转函数，我猜没几个人有这种耐心，于是code review是在没有上下文的情况下进行的。甚至因为上述第4点优势，你往往在当前的类文件里看到的只是变更部分，没错，连当前的文件都看不到它整个是长啥样子。
而且他是两周一次的，天知道两周前我看了神马，我还能记得多少。对了，它还是web的，这意味着，我需要点击，刷新，等待，点击，刷新，等待，点击，刷新，等待。这根本没有我用编辑器或者ide的流畅感啊？我甚至对字体背景色前景色的控制力都被剥夺了。不光是我，架构师们唯一一次在他们的机器上安装开发环境的机会也被剥夺了。他们以前既不写代码，以后也不用了，他们只需要点开浏览器，像看纳市指数那样去看代码，也许他们真的开了两个tab在这样做，一边是纳指，一边是代码呢！他们更有理由只需要画画示意图，描述一下文字就领取高薪了，或许做代码审查的时候，还有机会做一手股票，赚他一点外快吧。
好吧，就算上述种种你全都不同意。但是，不能运行代码的code review工具到底又有什么用呢？你完全是用人脑在冥想别人的代码阿？你没有机会去设一设断点，跑一跑测试用例，验证你的意度啊。这种破东西带来的后果是啥呢？
第一，是我这样，每一天对每一个code change 都习惯去diff一下的一线程序猿感到莫大的沮丧，是阿，我多么细致的每天，每一个早上都在做code review啊，我有机会在别人写下一段错误代码的第一时间就发邮件通知，而不是等到那些拉屎拉尿的印度佬两周以后把事情全搞混以后再收拾残局啊。
第二，那些其实只是被迫着挟持来做code review的人和那些真的想做code review但是实在觉得web based code review tool太烂的人，他们只是在那里每隔几秒钟动一下鼠标以此通知crucible增加 review 的时间，因为这个 review 时间领导很重视噢，如果是0的话，会挨骂哦。其实这太脑残了，我告诉他们，你可以直接点击那个时间，虽然这一点并不明显，而且那个显示review时间的地方在网页上长的像一个lable而不是inputbox, 但是如果你点一下，会有惊喜噢，NND, 那个脑残终于发觉这是一个可以编辑的label, 还是 ajax call 的。 于是他和我一样，直接填入了一个两小时，去公司楼下遛弯侃大山了。好吧，欺骗领导是不对的，但是谁让我们这么没有责任心，况且工具还这么的不给力呢。
好吧，这就是我为什么不理解 reviewboard 是个什么玩意了，我的专业意见是，别花里胡哨，老老实实搭你的环境，装你的编辑器，IDE, 好好用你的肉眼和脑子去做 code review， 每天都要做，每个 change list 都要 diff, 发现谁拉屎谁撒尿，走过去骂他，指着 diff 骂， 让他把屁股擦干净再干活。等两周？你自己都被大便掩埋了。还有，责任心和敬业态度。工具不能取代这些东西，没有这些东西，各种的作弊可以绕过工具，但是有了这些东西，不需要那些花里胡哨的工具， 在web based XXX出来以前，操作系统就已经写完了。
为什么我在工具上的 review 时间是 0， FUCK !
--
limodou
你报怨了半天，其实并不见得是code
review不好，正如你说的，你也在做，而且做得更可能认为更好。更多还是你们公司的管理方式和你的行为方式不符。要么你摆理由说服别人按你的方式去做，我相信，别人一样有很多理由说现行的方式有许多好处。其实每种方法并不见得都是完美的，有时，用不同的方法来取悦不同的人可能是最理想的，但现实好象并不这样。要么你只能接受了。否则你永远处于冲突之中。
zhao shichen
呆痴木讷，君子四德
Zhang Jiawei
但是在这里，我只想传达一种声音，告诉大家什么是对的，如你所说，这个是我的意见，看官自己判断。
--
Wei guangjing
> 我没什么冲突，我以我的方式干活。 如果是在公司里，面对的是领导，我知道说什么也没用。所以他有他的要求，我有我的方式。
>
> 但是在这里，我只想传达一种声音，告诉大家什么是对的，如你所说，这个是我的意见，看官自己判断。
我想真正的原因是你并不热爱你们写的代码;-)
去<http://codereview.appspot.com/>看看，就会知道有效的web方式的code
review是怎么样的了（这个系统是python语言的发明人Guido开发的），在上面找找和Go语言相关的code
review，你就会发现code review是多么的有效，这些开发人员是多么的热爱他们的代码;-)
--
vcc
Rujia Liu
你说的问题，包括看不到上下文、间隔太长、不流畅等问题都是因为你们公司把这个用来**代替**而非**补充**传统的code
review。review过程中发现的问题是多种多样的饿，并不是每种都需要开IDE，加断点调试。而且不同人的侧重点也不一样，有些人注重代码组织、设计模式这些东西，有些人注重逻辑严密性，有些人注重运行效率。并不需要每个reviewer都对代码进行全面、细致的review。
架构师不装IDE是你们公司自己的问题，我认为不开发程序的架构师不是好架构师。但这也不代表架构师要花大把时间在IDE跟前。他们有其他事情要做，至于你所描述的，闲得code
review的时候还开一个tab炒股，甚至"只需要画画示意图，描述一下文字就领取高薪"，我觉得正是因为你们管理失策的后果，怪不得code
review工具。架构师要是只画图，描述一下文字，必然误事。
2011/8/26 Zhang Jiawei <gho...@gmail.com>:
> 你也不用意度我到底我能不能理解reviewboard这种东西了，在你告诉我之前，我的确不知道，所以我去goole了，再然后，我扫了第一眼搜索结果的标题：web
> based code review tool. 一下子就被恶心到了。噢，原来就是我们公司用的，类似 crucible
> 那样的东西吧。领导说这东西有多强大呢？他们可以：
> 1. 和你的branch做绑定，看到每一个人的每一次change list.
> 2. 可以每两周发起一次review, 邀请不同的人，甚至公司的架构师来查看代码。还可以看到每个受邀者，在这个工具上停留的review时间。
> 3. 可以在没有开发环境的机器上，直接用网页来code reivew,
> 还可以在那个网页上编辑review的意见。留下意见以后，可以会自动发一个邮件通知写代码的人。收到邮件的人可以再次回复这次的意见。
> 4. 可以只看和上一个review请求之间不同的代码段。
> 5. 它是web的，真 tm 牛阿，只要你愿意，你可以在喜马拉雅上做code review阿！
> 还有很多好处我也记不全，如果你不知道什么是crucible, 你也可以去google。
> 领导很喜欢这种的东西，
>
Rujia Liu
Zhang Jiawei
长话短说，再次表态：有效的code review有两点: 1. 绝对是基于编辑器而不是web的。 2. 最早最及时的。
这个和我是否热爱我们公司的代码没关系。即使我在开发go, 我也不会喜欢他们现在这种方式，同样的缺点，我在前文所述，一样也存在，不因为他们是 go 就能说服我。同时也不因为 go 有这样 code review 方式，就说明每一个人都需要这种方式来 code review, 这个系统只是存在，我更相信，很多人没有使用。
如果要说服我，反驳我所述的负面状况。
--
Zoom.Quiet
>> 我没什么冲突，我以我的方式干活。 如果是在公司里，面对的是领导，我知道说什么也没用。所以他有他的要求，我有我的方式。
>>
>> 但是在这里，我只想传达一种声音，告诉大家什么是对的，如你所说，这个是我的意见，看官自己判断。
>
> 我想真正的原因是你并不热爱你们写的代码;-)
- 嗯嗯嗯,这么说就有点伤人了
- 不过,从字里行间看得出,对于代码,整个公司只是视作绩效工具,而不是数字资产
- 就如同,我们爱国,可这国家是否爱我们?
- 代码是辛苦写出来的,但是有时,明知这么写要死,但是上面就要这么写,,,
- 长期这么来,没人爱明知是垃圾的代码了,,,
- 当然 成功学 的会吼,那是你不爱,真爱的话,会不惜一切代价改进它的!
- 问题是,这个不惜代价的后果,不是底层码农可以承受的
- 而中层以上,根本不想承担这种代价
所以,各种乱象出现了,,,
- 这时,工具另外一个重要作用才被所有人接受:
- 唯一相对客观的质量衡量数据来源
- 自动化测试/编译/部属 等等SCM 工具的客观过程品质数值
- 可直接替换原先的主观绩效
- 程序可以拿这说事儿,拒绝外部乱来的命令
- 高层也有个相对靠谱并容易理解的开发成本概念,少拍头
当然,一切,事先得充分沟通,理解这些工具的作用...
没想到这一线索持续这么长时间,
- 看来沟通还是工具,在日常中,是怨念凝聚地哪,,,
>
> 去<http://codereview.appspot.com/>看看，就会知道有效的web方式的code
> review是怎么样的了（这个系统是python语言的发明人Guido开发的），在上面找找和Go语言相关的code
> review，你就会发现code review是多么的有效，这些开发人员是多么的热爱他们的代码;-)
>
系统是这个: rietveld - Code Review, hosted on Google App Engine - Google
Project Hosting
http://code.google.com/p/rietveld/
可部署到 GAE 中和 bitbucket.org 等等项目托管服务关联
> --
> vcc
--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/
Zhang Jiawei
不能运行代码的code review工具到底又有什么用呢？
Rujia Liu
> Rujia 同学，如果我出来反驳你，很多拜神教的fans,
> 又会冲出来说我，所以我也不想多说什么，但是我们基于文字讨论的基础是看清楚，想明白对方在说什么。我给你加粗我的原文，其它的暂且不一一反驳, 太累：
>
> 不能运行代码的code review工具到底又有什么用呢？
> 你完全是用人脑在冥想别人的代码阿？你没有机会去设一设断点，跑一跑测试用例，验证你的意度啊。
> 所以我没有说一定需要，好不好。
你在web里没有机会去设端点，但是有机会在IDE里设，因此我提倡把web作为IDE的补充而非代替。
既然你也认为不一定需要，那么就可以在那些不需要的时候改用web。
limodou
> 呵呵，看来你是有阴影了，因为管理层对工具的误用（比如：用工具产生的指标评价业绩）。所以说工具是双刃剑，看你怎么用了。
>
> 你说的问题，包括看不到上下文、间隔太长、不流畅等问题都是因为你们公司把这个用来**代替**而非**补充**传统的code
> review。review过程中发现的问题是多种多样的饿，并不是每种都需要开IDE，加断点调试。而且不同人的侧重点也不一样，有些人注重代码组织、设计模式这些东西，有些人注重逻辑严密性，有些人注重运行效率。并不需要每个reviewer都对代码进行全面、细致的review。
>
> 架构师不装IDE是你们公司自己的问题，我认为不开发程序的架构师不是好架构师。但这也不代表架构师要花大把时间在IDE跟前。他们有其他事情要做，至于你所描述的，闲得code
> review的时候还开一个tab炒股，甚至"只需要画画示意图，描述一下文字就领取高薪"，我觉得正是因为你们管理失策的后果，怪不得code
> review工具。架构师要是只画图，描述一下文字，必然误事。
>
+1
bhuztez
1. 直接在编辑器/IDE里 review，而不是非要到浏览器里才行
2. 每次push之后，会自动regression test
On 8月26日, 下午3时29分, Zhang Jiawei <ghos...@gmail.com> wrote:
> Rujia 同学，如果我出来反驳你，很多拜神教的fans,
> 又会冲出来说我，所以我也不想多说什么，但是我们基于文字讨论的基础是看清楚，想明白对方在说什么。我给你加粗我的原文，其它的暂且不一一反驳, 太累：
>
> 不能运行代码的code review工具到底又有什么用呢？
> 你完全是用人脑在冥想别人的代码阿？你*没有机会*去设一设断点，跑一跑测试用例，验证你的意度啊。
>
> 所以我没有说一定需要，好不好。
>
> 在 2011年8月26日 下午2:52，Rujia Liu <rujia....@gmail.com>写道：
>
>
>
>
>
>
>
> > 呵呵，看来你是有阴影了，因为管理层对工具的误用（比如：用工具产生的指标评价业绩）。所以说工具是双刃剑，看你怎么用了。
>
> > 你说的问题，包括看不到上下文、间隔太长、不流畅等问题都是因为你们公司把这个用来**代替**而非**补充**传统的code
>
> > review。review过程中发现的问题是多种多样的饿，并不是每种都需要开IDE，加断点调试。而且不同人的侧重点也不一样，有些人注重代码组织、设计模式这些东西，有些人注重逻辑严密性，有些人注重运行效率。并不需要每个reviewer都对代码进行全面、细致的review。
>
> > 架构师不装IDE是你们公司自己的问题，我认为不开发程序的架构师不是好架构师。但这也不代表架构师要花大把时间在IDE跟前。他们有其他事情要做，至于你所描述的，闲得code
> > review的时候还开一个tab炒股，甚至"只需要画画示意图，描述一下文字就领取高薪"，我觉得正是因为你们管理失策的后果，怪不得code
> > review工具。架构师要是只画图，描述一下文字，必然误事。
>
> > 2011/8/26 Zhang Jiawei <ghos...@gmail.com>:
> > 严正: 理解列表! 智慧提问!http://wiki.woodpecker.org.cn/moin/AskForHelp
Zhang Jiawei
如果我使用编辑器或者IDE, 他们已经很全面很给力的支持了我的一切需要或者不需要的状况，那么我为什么还多此一举去选择一个有可能在某个时刻让我情何以堪的东西呢？
--
Rujia Liu
> 是不是可以这么说：
> 1. 直接在编辑器/IDE里 review，而不是非要到浏览器里才行
> 2. 每次push之后，会自动regression test
意思不太一样。自动测试一般是作为持续集成（Continuous integration）的一部分
- Rujia
Rujia Liu
> 既然你依然要我想明白，那我就说得再明白一点。
>
> 如果我使用编辑器或者IDE,
> 他们已经很全面很给力的支持了我的一切需要或者不需要的状况，那么我为什么还多此一举去选择一个有可能在某个时刻让我情何以堪的东西呢？
这么跟你说吧，你可以自己给你的IDE写一个插件，把你的review传到服务器上，这样既利用了IDE的优势，也利用了code review
system的优势。如果没有这个system，你的review打算写到哪里呢？口述？这个我不推荐，因为失去了一个回顾的功能：你无法让程序员或者谁谁谁通过以前的code
review获取经验。
如果你自己开发一个小服务器把review提交到这个服务器，那你也在用工具，只不过是自己创造了工具。人家叫web-based，没说是web-only，你可以让你的IDE集成它的功能。你自己和往常一样的去做code
review，而其他没有装IDE的人至少也可以进行一些其他类型的code review。
- Rujia
Zhang Jiawei
我会直接打开我的编辑器或者IDE， 在那个烂代码上面这么写：
// jiawzhang REVIEW: tom, please check null here.
if (name.equals("zhang") {
xxxx, blablabla
}
然后提交代码，tom 那个傻孩子，他只要养成一个习惯，check out 代码以后 grep tom * -r 就可以知道，自己该干吗了。我们时常就是把问题搞的太花里胡哨了，原始朴素的特性和谨慎的做加法是避免复杂的第一要素。如果你有一个 SCM 工具，你为什么还要一个 web-based, 他们反正都在服务器上嘛。
类似花里胡哨的工具还有一下这些，如果诸位不明白是干吗的，可以去google一下，以后碰上了又想用，三思后行：
crucible, jira, fisheye, hudson
有时候想想，这些工具存在的唯一价值，不过是赚一些二流的以业务导向为主的技术公司的钱，因为他们对自己惶恐，对工具迷恋和迷信。
--
pansz
> 你也不用意度我到底我能不能理解reviewboard这种东西了，在你告诉我之前，我的确不知道，所以我去goole了，再然后，我扫了第一眼搜索结果的标题：web
> based code review tool. 一下子就被恶心到了。噢，原来就是我们公司用的，类似 crucible
实际上你并没有理解这里面的概念。——例如你认为：因为工具不能解决所有问题，因此工具就是无用的，应当摒弃的。
而我想表达的是：工具是用来解决你的一部分问题，从而解放人力去解决剩下的那些必须要人力去解决的问题。
在 code review 这个例子中，我们自己最常用的是一张纸，或者是用电子/web形式表达的一个文档，上面写的不是代码，而是，你做审查时可能需要注意的一些事项。这些提示信息有助于你更好的做审查，仅此而已，也就是说，在我们的应用中，你可以选择你喜欢的任何工具去查看代码，只是你可以通过这些工具启发你的结论而已（OK，它看起来仅仅是个“工具书”，不过工具书也是工具）。而我们的经验表明，审查者对这个玩意的反馈是正面的，因为在某些时候，这些玩意能提示他们从哪些方面去审查代码。
重要的不是你用什么工具，而是你用工具解决什么问题。工具从来都不是用来解决全部问题的。正如自动测试从来都只能解决一部分的测试，不能解决全部的测试需求。
假定你需要贯彻：“所有代码不能有编译警告”这个制度，工具是不是能起很大作用？因为一个自动构建工具就可以很好的显示这个事情。
假定你需要贯彻：“必须要肉眼审查才能提交代码”这种制度，工具就没多大意义了，因为没有什么机器人能知道你是否究竟真的审查了。
就工具的运用，举个现实生活中的例子：
超市商品中打印有条码，条码实际上表达的就是一串数字，在付款的时候，由收银员手输这些数字会比较麻烦，而且容易出错，而使用条码扫码器能够提高工作效率。这是工具的非常典型正面应用，但是，对零售现金的清点却无法使用工具完成，必须由收银员手工完成，因为工具无法帮她解决所有的问题。只能解决一部分问题。
回到 scm 的问题上来：SCM 是不是工具？同样是，利用 SCM 直接进行交流，虽然经常被认为是对 SCM
的滥用，但是，这也是可行的一种形式，并且很肯定的是：SCM 这个“工具”帮助了你。你和 tom 通过 SCM 工具沟通了，你们的 code
review 用好了 SCM 这个工具。
然后，你打算继续反感工具？那么，抛弃你的 SCM 吧。
Zhang Jiawei
原始朴素的特性和谨慎的做加法是避免复杂的第一要素
--
limodou
> 好吧，我告诉你我会杂么干这件事情。
>
> 我会直接打开我的编辑器或者IDE， 在那个烂代码上面这么写：
>
> // jiawzhang REVIEW: tom, please check null here.
> if (name.equals("zhang") {
> xxxx, blablabla
> }
>
> 然后提交代码，tom 那个傻孩子，他只要养成一个习惯，check out 代码以后 grep tom * -r
> 就可以知道，自己该干吗了。我们时常就是把问题搞的太花里胡哨了，原始朴素的特性和谨慎的做加法是避免复杂的第一要素。如果你有一个 SCM
> 工具，你为什么还要一个 web-based, 他们反正都在服务器上嘛。
>
> 类似花里胡哨的工具还有一下这些，如果诸位不明白是干吗的，可以去google一下，以后碰上了又想用，三思后行：
>
> crucible, jira, fisheye, hudson
>
> 有时候想想，这些工具存在的唯一价值，不过是赚一些二流的以业务导向为主的技术公司的钱，因为他们对自己惶恐，对工具迷恋和迷信。
>
把code review的结果作为注释放到代码中我不认为很好。但有可能IDE可以做到将某行的code
review自动关联和显示，这样就方便了。就象code.google, github一样，可以在代码行的边上看到code
review的结果。
Zoom.Quiet
> 不得不再次加粗，其他我就不一一回复了，太累，真的太累。
>
> 原始朴素的特性和谨慎的做加法是避免复杂的第一要素
>
- 真正累的是沟通!
- 改变任何人任何一点小习惯,都要付出艰辛的努力
- 而且,即使改变一时,无法坚持一世
- 協同好习惯,非常容易被随大流冲毁
- 比如说,你食了太多亏,相信的: "原始朴素的特性和谨慎的做加法是避免复杂的第一要素"
- 并不能简单的复制到其它人头脑中
- 反复反复反复,进行解释,最TMD累了!
- 所以,其它人就体验到,一个靠谱的无压迫感的小工具,可能立即就改变了整个团队的行为模式!
- 因为工具,包含了过往的经验
- 无须口舌,规定下来,不这么作不给工资!
- 从反抗,到无奈,到习惯,再到发现其中的理念
好的开发习惯,这么推广,可能是最有效的,,,
当然,归根到底,是因为大家虽然用了相同的词语,但是,内心对其理解完全不同哈:
- 工具
- 协同
- 流程
- IDE
- 代码质量
...
不过,能有空在这儿吐糟,已是种幸福了,太多其它程序猿,可能从来没有意识到自个儿的开发过程不是最高效的...
> 在 2011年8月26日 下午4:29，pansz <pan.s...@gmail.com>写道：
>>
>> 2011/8/26 Zhang Jiawei <gho...@gmail.com>:
>> >
>> > 你也不用意度我到底我能不能理解reviewboard这种东西了，在你告诉我之前，我的确不知道，所以我去goole了，再然后，我扫了第一眼搜索结果的标题：web
>> > based code review tool. 一下子就被恶心到了。噢，原来就是我们公司用的，类似 crucible
>>
>> 实际上你并没有理解这里面的概念。——例如你认为：因为工具不能解决所有问题，因此工具就是无用的，应当摒弃的。
>>
>> 而我想表达的是：工具是用来解决你的一部分问题，从而解放人力去解决剩下的那些必须要人力去解决的问题。
>>
>> 在 code review
>> 这个例子中，我们自己最常用的是一张纸，或者是用电子/web形式表达的一个文档，上面写的不是代码，而是，你做审查时可能需要注意的一些事项。这些提示信息有助于你更好的做审查，仅此而已，也就是说，在我们的应用中，你可以选择你喜欢的任何工具去查看代码，只是你可以通过这些工具启发你的结论而已（OK，它看起来仅仅是个“工具书”，不过工具书也是工具）。而我们的经验表明，审查者对这个玩意的反馈是正面的，因为在某些时候，这些玩意能提示他们从哪些方面去审查代码。
>>
>> 重要的不是你用什么工具，而是你用工具解决什么问题。工具从来都不是用来解决全部问题的。正如自动测试从来都只能解决一部分的测试，不能解决全部的测试需求。
>>
>> 假定你需要贯彻：“所有代码不能有编译警告”这个制度，工具是不是能起很大作用？因为一个自动构建工具就可以很好的显示这个事情。
>> 假定你需要贯彻：“必须要肉眼审查才能提交代码”这种制度，工具就没多大意义了，因为没有什么机器人能知道你是否究竟真的审查了。
>>
>> 就工具的运用，举个现实生活中的例子：
>>
>> 超市商品中打印有条码，条码实际上表达的就是一串数字，在付款的时候，由收银员手输这些数字会比较麻烦，而且容易出错，而使用条码扫码器能够提高工作效率。这是工具的非常典型正面应用，但是，对零售现金的清点却无法使用工具完成，必须由收银员手工完成，因为工具无法帮她解决所有的问题。只能解决一部分问题。
>>
>> 回到 scm 的问题上来：SCM 是不是工具？同样是，利用 SCM 直接进行交流，虽然经常被认为是对 SCM
>> 的滥用，但是，这也是可行的一种形式，并且很肯定的是：SCM 这个“工具”帮助了你。你和 tom 通过 SCM 工具沟通了，你们的 code
>> review 用好了 SCM 这个工具。
>>
>> 然后，你打算继续反感工具？那么，抛弃你的 SCM 吧。
...
Zhang Jiawei
还有，如果我看到一个有责任心的程序员在代码里写了一个一个注释，里面有自己的名字，然后加TODO， 我会大赞。
因为其他他很朴实的知道搜索优于导航的概念，而且很有责任心，知道自己在干什么，以后要干什么。
我的观点是尽量在代码里留下任何东西， 因为你以后要做的仅仅是 grep
--
Wei guangjing
> 比起整一套很专业的web based code review tool,
> 我觉得这么做很朴素，很好，双方都方便。我们这个年代鼓励文档进代码都已经达成共识了，接受 review 进代码，并不那么难，如果你觉得不好，给出理由。
> 一个review而已，没有严重到要说好或者不好。
>
> 还有，如果我看到一个有责任心的程序员在代码里写了一个一个注释，里面有自己的名字，然后加TODO， 我会大赞。
> 因为其他他很朴实的知道搜索优于导航的概念，而且很有责任心，知道自己在干什么，以后要干什么。
>
> 我的观点是尽量在代码里留下任何东西， 因为你以后要做的仅仅是 grep
强烈建议在代码中加上看代码的签到信息，全场HOLD住，很强大。
Zhang Jiawei
如果我是独裁者，我可以很方便的给程序猿们洗脑，强迫他们接受我认为的高效。
西德和前苏之所以这么强大，是因为独裁社会有强大的独裁者和高效统一的执行能力。独裁者一个正确的决策，第二分钟就会被强力的执行。啥么民主，啥么沟通，纯是浪费时间嘛！苹果就是这样的吧。
只可惜比较致命的是，独裁者不能始终保持正确，同时独裁模式也不能保证源源不断的诞生继任者吧。
至于你说的，工具强迫接受，在我们这里，更可能发生的是利用工具造假，关键还是人心的问题。如果每个人真心的接受独裁者的观点，不需要这么多的解释，这个效率可以多么的高阿。
--
Zoom.Quiet
> 是阿，可惜我不是领导，我不是独裁者阿。
>
> 如果我是独裁者，我可以很方便的给程序猿们洗脑，强迫他们接受我认为的高效。
>
> 西德和前苏之所以这么强大，是因为独裁社会有强大的独裁者和高效统一的执行能力。独裁者一个正确的决策，第二分钟就会被强力的执行。啥么民主，啥么沟通，纯是浪费时间嘛！苹果就是这样的吧。
>
> 只可惜比较致命的是，独裁者不能始终保持正确，同时独裁模式也不能保证源源不断的诞生继任者吧。
>
> 至于你说的，工具强迫接受，在我们这里，更可能发生的是利用工具造假，关键还是人心的问题。如果每个人真心的接受独裁者的观点，不需要这么多的解释，这个效率可以多么的高阿。
>
- "更可能发生的是利用工具造假" ~ KAO! 及时找下家吧，这种环境，你就是上帝也没招的,,,
..
--
Zhang Jiawei
没有哪个高层会真正关心代码，因为商业模式和垄断地位在那里，不要烂到网站打不开，钱还是源源不断的。
熙熙攘攘，皆为利来，赚份工资，养家糊口而已。
各位再见，我下班。
>> >> 实际上你并没有理解这里面的概念。----例如你认为：因为工具不能解决所有问题，因此工具就是无用的，应当摒弃的。
>> >>
>> >> 而我想表达的是：工具是用来解决你的一部分问题，从而解放人力去解决剩下的那些必须要人力去解决的问题。
>> >>
>> >> 在 code review
>> >>
>> >> 这个例子中，我们自己最常用的是一张纸，或者是用电子/web形式表达的一个文档，上面写的不是代码，而是，你做审查时可能需要注意的一些事项。这些提示信息有助于你更好的做审查，仅此而已，也就是说，在我们的应用中，你可以选择你喜欢的任何工具去查看代码，只是你可以通过这些工具启发你的结论而已（OK，它看起来仅仅是个"工具书"，不过工具书也是工具）。而我们的经验表明，审查者对这个玩意的反馈是正面的，因为在某些时候，这些玩意能提示他们从哪些方面去审查代码。
>> >>
>> >>
>> >> 重要的不是你用什么工具，而是你用工具解决什么问题。工具从来都不是用来解决全部问题的。正如自动测试从来都只能解决一部分的测试，不能解决全部的测试需求。
>> >>
>> >> 假定你需要贯彻："所有代码不能有编译警告"这个制度，工具是不是能起很大作用？因为一个自动构建工具就可以很好的显示这个事情。
>> >> 假定你需要贯彻："必须要肉眼审查才能提交代码"这种制度，工具就没多大意义了，因为没有什么机器人能知道你是否究竟真的审查了。
>> >>
>> >> 就工具的运用，举个现实生活中的例子：
>> >>
>> >>
>> >> 超市商品中打印有条码，条码实际上表达的就是一串数字，在付款的时候，由收银员手输这些数字会比较麻烦，而且容易出错，而使用条码扫码器能够提高工作效率。这是工具的非常典型正面应用，但是，对零售现金的清点却无法使用工具完成，必须由收银员手工完成，因为工具无法帮她解决所有的问题。只能解决一部分问题。
>> >>
>> >> 回到 scm 的问题上来：SCM 是不是工具？同样是，利用 SCM 直接进行交流，虽然经常被认为是对 SCM
>> >> 的滥用，但是，这也是可行的一种形式，并且很肯定的是：SCM 这个"工具"帮助了你。你和 tom 通过 SCM 工具沟通了，你们的 code
>> >> review 用好了 SCM 这个工具。
>> >>
>> >> 然后，你打算继续反感工具？那么，抛弃你的 SCM 吧。
..
--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/
limodou
> 比起整一套很专业的web based code review tool,
> 我觉得这么做很朴素，很好，双方都方便。我们这个年代鼓励文档进代码都已经达成共识了，接受 review 进代码，并不那么难，如果你觉得不好，给出理由。
> 一个review而已，没有严重到要说好或者不好。
>
> 还有，如果我看到一个有责任心的程序员在代码里写了一个一个注释，里面有自己的名字，然后加TODO， 我会大赞。
> 因为其他他很朴实的知道搜索优于导航的概念，而且很有责任心，知道自己在干什么，以后要干什么。
>
> 我的观点是尽量在代码里留下任何东西， 因为你以后要做的仅仅是 grep
>
为什么不好，就是因为代码审查更多的是过程性的东西，不是最终的结果。而代码中如果过程性的东西太多，就好象一个程序改了好几次，那么你是把每次修改的东西都注释保留呢？（这样会造成代码越来越长，而且大量的非有效的代码或文本）还是删除无用的，过时的注释代码，通过在提交日志中进行说明，为什么要删除，为什么要修改。通过diff，通过提交日志来了解变化的过程呢？
我也很难说这两种到底哪种好，我个人倾向于第二种。一方面代码更干净，更有效。另一方面与版本工具相结合，也很容易了解变化的情况。更何况许多代码不是孤立的，而是有关系的。比如变更集，利用版本工具和日志感觉更有效。
而且对于我个人，我也不喜欢别人在我的代码里留下许多讨论性的东西，因为它们不是代码，更何况是不是有问题还不一定呢，这个需要沟通的，中间性的东西。
Kabie
Zhang Jiawei
显而易见的东西留下意见，过程留于讨论即可。
Zhang Jiawei
我也就是提供一种方案，具体问题具体变通吧。
Zhang Jiawei
并无拒绝之权利，挨骂是有的。
jamiesun
在 2011年8月26日 下午5:44，Zhang Jiawei <gho...@gmail.com> 写道：
> 并无拒绝之权利，挨骂是有的。
> 在 2011-8-26 下午5:36，"Kabie" <kabi...@gmail.com>写道：
>
>>
>> ......这是制度的缺陷而已吧......如果被邀请审查和你无关的部分那完全就应该拒绝掉啊......
>>
>> 只有当你是这个模块的维护者的时候才有参与审查的必要性:
>> 1. 可以看到其他人的工作会对你的代码产生怎样的影响
>> 2. 可以及时发现其他人的代码会怎样受到你的代码的影响
>>
>> 如果你很熟悉相关的代码的话别人犯了什么错立刻就能发现......
>> 而如果在审查之前还得先从头了解整个架构的话完全就是在浪费时间吧。。。
>> ......review又不能代替测试......反正只要re-view一遍就好了......