【主题】关于做代码以及文档review的一些问题

   [TopLanguage] 邮件组中关于主题讨论的较完整摘录。

   “>”开头的行或段是发件人对前文回复的引用。
   【杨威利】 --发件人
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

【主题】关于做代码以及文档review的一些问题

========================================================================================
【杨威利】

我是一家小公司的技术经理。针对员工月报收集上来的反馈，我刚给所有人发了以下一封邮件。我想拿出来大家讨论，具体执行上不知道各位有什么好的建议和想法？
-----------------------------------------------------------------------------------------------------------------
Hi,
当前我陆续接到一些关于review的建议和意见。有认为review过于浪费时间的，有认为review流程过于复杂的，有认为review寻找协助人比较麻烦等等。
这说明在当前实施中大家对于review是做什么，为什么要做，以及怎么做还存在着理解上的误差，这也正是当前我们review的效率比较低，效果比较差的原因。而正是因为它效率低，效果差，反过来又引起了review无用论，再次进一步降低了它的效率和效果。我认为有必要专门就此问题作一个澄清。

1，我想所有人都应该非常清楚我们当前是在做一个商业项目，我们在做一个商业产品。产品质量对于它的价值以及生命力有多重要，我想不需要我再赘述。
提两个问题，当前你们觉得我们产品的质量问题是过多了还是过少了？我们在为提高产品质量上花费的代价是过多了还是过少了？请仔细思考下整个公司，也包括你们为此付出了多少。
关于上述两个问题，我回头会和徐总一起整理个报告。我相信因为质量问题我们公司的损失数字会让所有人触目惊心的。

2，一个基本的常识，我想你们所有人也都知道。系统的bug，无论是软件或者硬件在它的生命周期从设计、实现、测试、维护中越早期发现，它的修复代价越低，而这个代价是呈数量级上升的。
如何来做到尽量在早期发现尽可能多的问题？只有一点，就是越在早期越是要增加投入以及提高质量意识。假如有的选择，我宁可在初期花费5倍以上的资源去改进，也不会愿意在末期花费10倍甚至100倍去收拾残局。不知道你们感想如何？
当然，前提是这里所谓的5倍以上的资源是起到效果的，而不是敷衍了事，纯粹走走流程而已。至于如何让它不沦为无效的流程，这需要所有参与人员的共同努力。

3，提高产品质量的途径有很多。review只是其中一种手段，也是整个质量体系环节上重要的一环。从应用正式程度上分为：pair work，review，inspection。在正式实施过程中，我要求的也是pair work和review结合，并不是强制要求review。但是无论采用哪种形式来做，目标都是一样的。那么目标是什么？
       1）在项目早期就能够发现代码中的BUG
       2）帮助初级开发人员学习高级开发人员的经验，达到知识共享
       3）避免开发人员犯一些很常见，很普通的错误
       4）保证项目组人员的良好沟通
       5）项目或产品的代码更容易维护

那么这些目标的实现能够为提高产品质量的目的起到什么作用？解决什么问题？
       1）寻找缺陷或者潜在缺陷，包括需求分析、设计、编码、测试等
       2）确保整个程序设计的一致性，包括需求与设计，设计与实现，实现与测试，以及程序各个模块之间接口的一致性
       3）设计、编码的质量，包括可测量的（功能，性能，可靠），与非可测量的（可读，可维护，可扩展，安全）；尤其后者基本上只能靠开发人员的质量意识和责任心，以及类似review的人工手段来保证。
请在任何时候都不要认为实现了前者作为开发人员的责任就已经完成了，我们要的是一个优秀的产品，不是一个玩具。
请思考一个问题，假如你觉得你的设计、实现、测试做的好，那么为什么好，何以证明？假如差，为什么差，何以证明？你达到了上述的多少包括可测量行和非可测量性指标？请不要告诉我，它能用了而已。

4，为什么会有当前的问题？请你们任何一个人告诉我，什么时候人类漫不经心敷衍的做一件事时，这件事情会完成的很成功？那么是事情本身错了，还是别的？
在上周我发了两封邮件，分别是我对于一个文档以及一份代码的检查结果。结果并不如人意，至少并没有让我感觉到review起到了它的作用。

但是，我的失望只会对于实施review的人，而不是review本身。

5，来自你们的建议和意见还是有效果的。至少说明了我们在review这个环节当前做的并不好，或许我们有一些流程或者方法上可以有所改进来改善review的效率，接下来我会考虑具体规划一些人物角色以及review过程的详细规则。我们也需要一些硬性的指标来保证review的质量，这也是昨天我要求从今开始所有的review结果都必须抄送给我的原因，由我来抽查结果。

6，在过去的一年里，我也在看到所有人的进步。从最初的完全无序的模式，到我们逐步引入backlog规划个人时间、module test、review和inspection、daily meeting、product owner角色、以及周会recheck等。虽然每个环节上我们都
还不是做的很完美，但是至少我们都已经开始逐步适应和熟悉这些流程。当前对于其中一些甚至全部都不是很理解为什么，或者执行的不够好也是正常的。任何事情或者是事情处理流程的适应都是需要一个过程的，不可能一蹴而就，这也是我把这些流程和定义逐步引入的原因。
不要奢望一步就走到完美，但是也不要放弃尽量把我们的工作或者生活往完美方向发展。这就是我想对各位说的，包括你们也可以这么去理解MT、review、daily meeting等。我们公司以及我们团队当前距离世界上的优秀公司和优秀团队距离都还很遥远，这是差距也是机会。你可以想象一下我们的生存危机，也可以想象一下我们可以有的提升空间。

最后，请各位也可以同样思考一下对于MT以及其他工具的理解，你真的是在测试我们产品本身吗？还是只是为了过一下MT的流程而已？质量的提高不是一句口号，是由你的日常工作累计组成的。如何提高产品质量，降低为质量保证的成本，才是我们引入这些工具和方法的意义所在。

你不能无视它背后的意义和利益的前提下，去衡量为此的付出。


========================================================================================
【Zoom. Quiet】

杨威利 ?!?!? 好名字哪!
不过,你使用的手段太激化了,,,要改革不要革命哪,,,
作 review 或是 TDD 得有先决条件的:
0. 高层支持不?
1. 成员意识水平到不?
2. 有对应的工具/系统/流程支持不?
3. 大家有时间来作不?

如果有任何一条达不到,那就没谱!

review 不应该是一刀切的统一进行的哪,,,针对过程的各个关键环节,在工件流传到下一阶段时,进行 review 才有用的,,,
而且,应该用对应的手段进行成制度化的檢驗,,,
推荐使用 ARCI分析矩阵:
 http://wiki.woodpecker.org.cn/moin/UsageArciMap
来识别出关键节点,,,

一般最佳体验在:
- 立项review,通过立项评审委员会,对项目各个环节进行 计划方面的 review,确认危机,给出指导,分配资源
 - 不吻合要求的,不允立项,不得进行;
- 结项review,根据立项报告,在结项委员会上,逐一核对交付工件,确保做对,做完,
 - 不吻合承诺的,结项失败,没有奖金,进行下一版本开发,,,
- 开发阶段,好象只有单元测试间隙好 review,,,
 - 进行 team review, 只有相互熟悉工作内容的同一小组成员,才有可能接受 review
 - 只有通过全体其它成员的 review 后,才可以入正式分支仓库
,,,

等等,总之,任何打破现行模糊温情的开发流程的行为,都是不得好死的,得精心统计和准备来落个好死,,,


========================================================================================
【caijimin】

我和楼主有非常相似的感受，出现的问题，从大的方面来说，包括责任心、自我提升的意愿等等，你的邮件给我感觉是，只有你满腔热血，别人都很冷漠、敷衍了事，这也说明要建立一个积极高效的团队是多么困难，过激的语言和行动带不来你想要的结果，甚至会带来相反的结果。

1、如何让员工保持积极的工作态度，公司提供了什么样的环境和前景？ 一味抱怨别人不努力没有用，还会给自己的情绪带来不好的影响。人的思想、意识转变是非常缓慢的，甚至无论你怎么灌输、引导都不起作用。不要幻想短时间有极大的提升，从小的方面着手，持续改进。

2、具体到review，不少书和文章都讲到如何去进行，你也可以根据具体的情况，做出实际可行的步骤，关键是让人看到确实有效果。


=====================================================