o6z说code review

ozzzzzz在agilechina上 写道

下面是我关于code review的论述。

code review其实就是发现code里面的疑问，并标注下来。

code review的三个原则：尽快；随时随地随手；非正式更有效。虽未（所谓）尽快就是要趁代码还是热的时候就code review。所谓随时随地随
手，就是只要有时间，有地方，有精力就code review，并且应该随手就做；就如同你扫完地随手就把笤帚放回原位一样。所谓非正式更有效，就是要
多注重平时这些随处存在的非正式的code review，而绝不是依靠把代码积攒起来，大家板起面孔，正襟危坐的code review会议。

具体的几个方法和注意事项：
1、写完就code review。
2、写的时候也code review。其实很多时候我们写代码的时候就有写不好的感觉，有这个感觉就标记下来。代码注释就是用来做这个的，而不是用了（来）
解释代码的。我经常上（说）好代码没有注释，也有这个意思。
3、问别人问他（题）的时候，就code review。
4、商量做接口的时候，也code review。
5、每日必在下班前作一个全天的code review。有些组织坚持每日建造，可以结合起来。
6、争论最终的解决依靠测试更有效。
7、code review关键在于标注问题，而不是对问题分类，更不是对问题划分优先级。这些是code review的后续工作，当然这些工作也必
须有专门的方法和约定进行解决。
8、code review要不预设范围，不要说我要找一个多线程的错误，我要找一个代码命名错误。
9、鼓励互相code review，但是以此和由此得出的成果作惩罚和奖励的依据。
10、定期对code review工作进行review是必要的。
11、注重工具的应用。比如注释的改变，并不会造成一次新的构建，具备这样功能的构建和集成工具是必要的。
12、注重 code review的实际效果，避免落入形式主义。其实在国内我发现，很多组织的code review会议都是在够过场，当然有些组
织更过分成了纯粹的扯淡会议，更加有一些堕落到一群人攻击另外一群人的手段。

oz老大的错别字老多了……

评论

5 楼 photon 2009-12-23  

我说怎么看不着了，原来跑agileChina去了

4 楼 yuan 2009-12-18  

不转了，帖子蛮精彩：https://groups.google.com/group/agilechina/browse_thread/thread/3765a500c7024f9e

3 楼 yuan 2009-12-17  

ozzzzzz 写道

然后我再说说code review的事情。本身这篇文章里面就很杂乱，所以大家应该充满了疑问。比如工具和算法的问题，老庄混的时间久，自然上来就看
到了问题所在。其实也就是工具的适用范围的问题，这个问题其实也是一个我们看待问题的根本体现。以后我肯定要专门的谈一下，这个坑不得不挖，因为这个问
题很需要深入的专门论述。这里我也就是说说跟我相关的论述有关联的部分。我在前面提到，需要对所有有疑惑的地方做出标记。如果马上就有人说了，这样会丧
失关注点。实际上恰恰相反，这样才可能建立起关注点。你有了一个疑惑，但是你完全没有必要当时就解决它。而是要等等你跟原作者仅仅沟通或者其他
code review者沟通，或者自己随后的专门确认后，在对问题做出类型判断，随后是应该采取的关注程度的判断，解决优先性的判断等等。工具的作用
应该发挥在哪里呢？是主动的利用某种高深的算法自动化的帮助我们大家发现问题所在吗？依我看不是。工具最大作用应该是跟踪这些标记，依照我们的简单设定
判断这些标记，通过我们提供的简单算法筛选这些标记。也正是因为有这些工具，我们才感做出大量的标记。而也是因为我们可以很容易的制造和找到能够支持工
作的这些工具，我们才会采用这样的方式。其实在我看来，我们这些做软件化了太多的时间为别人服务，而我们恰恰是应该花点时间为我们自己做点软件了。这些
小的工具，本身就是随手搞个脚本就搞定的。而之所以IBM这些人搞了那么多的臃肿的怪物还那么有市场，很大程度上就是因为有很多企业存在大量的不合格的
从业人员。而这些企业妄图依靠某种神奇的工具，神奇的方法（现在就是scrum）方法，叫这些不够格的人能够做出够格的事情。我不相信有这种可能，我劝
大家也别相信。

2 楼 yuan 2009-12-17  

ozzzzzz 写道

在我看来根本问题并非什么敏捷的问题，而是思想方法的问题。说白了就是有没有独立思考能力的问题。而且如果是有机会我到时想找个合适的方式跟大家交流一
下如何进行独立思考的。别的国家的人不在我考虑范围内，就说咱们中国人这个方面就特别欠缺。比如我们可以谈谈军队训练为什么要以齐步走开始，并且不分国
内国外都是这个讨论。这样类似的问题，叫大家都拿出自己的看法来，然后大家各自讨论，经过几个回合。然后在讨论其他问题，又几个回合。等形成某种习惯，
就不会只是凭感性而不喜欢动脑筋推理判断了。

实际上很多人根本形成不了自己的观点，就是人云亦云。不讲逻辑，根本就是没经过思考，单纯的感性认识。于是最终走向教条化或者经验化，而不能认识到事物
后面其实都是存在某种规律的。就比如为什么军人要强调勇敢不怕死，而猎人就不强调。这些事情都是存在其最初产生的背景的客观原因的。你不知道这些原因，
随大流的以为这些是必然，是必须的军人素质，那就注定会在相关的场合失败。

当然我不否认存在天才，并且我也认识几个天才，但是我相信绝大多数人不是天才。这些人都是要经过相关的专业训练，掌握某些专门的技巧，并且熟练运用某种
方式，才可能成为某个方面的专门人才。而现在我在这个论坛看到的，往往是入行才几年，仅仅是经过某个培训和认证就宣称自己敏捷了。也许你们相信这种事情
存在，但是绝对不相信。而且我认为，如果敏捷这么简单，软件开发这么容易学习，这个职业本身就没什么必要说是高技术职业，我们人不是上面专业人士。要说
痛心疾首，这个事情才是我所痛心疾首的。

而就如同我所担心的，你很容易的就落入了gigix的陷阱，根本就不知道现场管理或者说lean里面的清扫是在说些什么。真的事情不像表面看起来那么简
单。当然这个文章可能是IBM的要求的软文，但是写软文也太差了，基本的概念和逻辑都搞的这么混乱，而且事实和依据都漏洞百出，我实在不知道这种文章有
什么必要叫好。而你说有些地方可能比他们更差，所以这些东西对这些人还是有效的。但是事情往往不是那么回事，因为你从开始就不建立一个正确的世界观，往
往是会越走越混乱，越来越失败。最终所谓的水平提高，就只能单纯的依靠运气。当然我相信运气好的人确实存在，不过我也相信99%的人都是运气不好和不那
么好的。

而走向正确的开始就是要有一个虚心的态度。我这里说的虚心，并不是要你搞什么什么崇拜，也不是叫你对别的说明人低三下四，而是抛弃成见和思想中的想当
然，保内心排空。然后对任何观点和方法，都精心进行一次逻辑的推理和预演，然后在得出结论。这么多当然对很多人来说是麻烦的，因为他们往往相信他们所谓
的"常识"。然而恰恰是这些常识在阻碍他们的进步，也正是这些常识在阻碍他们对事物背后的规律的探索。而且在软件开发这个新兴的职业里面，这些事情显得
更加重要。我们这个行业现在还没有形成那些常识性的东西，我们也没有什么资格形成常识性的东西。一切还是要从独立思考和大胆思辨开始。

我在做个提示，这个文章充满谬误，根本就不知道code review为何物。并且后面yuezhang的看法更加是走得太远。比如说"以及code
review不涉及功能性检查和性能分析"则完全是胡闹的做法，可以说任何的问题只要是你发现的就都应该做出标注。为啥会如此，随后还需要有什么手段配
合。不如此就又会有什么问题。你们可以从这里开始思考。

1 楼 yuan 2009-12-17  

后面跟帖也蛮有意思的，其中：

张磊 写道

呃，我不是敏捷高手，但是看到文章开头就已经觉得有点smell了。。。不知道作者是否成功实践过pair programing。。。

记得刚接触敏捷的时候，挺反感“敏捷”这个词的，讨论问题的时候总喜欢屏蔽掉这个词。对于敏捷实践过程中存在的问题也是存在很多的怀疑。

然而，我现在反而更像“保皇派”了。遇到好多做敏捷开发的，觉得敏捷嘛，拥抱变化嘛，那些实践也未必是对的嘛，未必适合国情，未必适合团队嘛。觉得守破离嘛，就直接破了离了得了，总想自己拉架子再发明一套敏捷方法。呜呼，很多敏捷实践他们压根就没用好没用对，浅尝则止，就说实践不好了。最佳实践只是摆设么？不学跑真的可以飞么？没有巨人的肩膀，真的可以自创武功么？

没有针对任何人都观点，只是有感而发，貌似跑题了。。。。

我也不是高手，可以算连门都没入，但我和这位张磊也有相同的感受。