在这篇文章里，我们可以见到许多有意思的编程风格，又没有精神为之一振的感觉，仿佛里面的例子就在自己身上，或者离自己很近。其实，对于文档、代码的评审，也是有诸多风格可言的，我这里列举一些有意思的典型：
一坨屎型评审
阅读文档、代码的时候，这些东西在自己眼里就是一坨屎：“我这么高智商的人都看不懂，明显是你有问题！”。
这样的人有一个他自己相当认可的世界观，凡是和这个世界观相冲突的无论对错的事务，必须强力排斥。这样的人眼中容不下复杂的东西，复杂对他的智商而言是一种侮辱，他会选择下结论的方式来拒绝自己对文档或代码的进一步阅读；对于和自己预期不一致的设计和实现，必须升级为人身攻击，挥舞狼牙棒子痛骂一顿，最后得出的结论就是，“很明显，这个人创造的东西是一坨屎，这个人也是一坨屎。”
这样的评审表述有：
“这里体现了一个问题，你考虑问题太缺乏全面性和深入性”
“这里写的太烂了，请重写”
“这是什么，我看不懂，和我的实现方式不一样，请改到我的那种实现方式上去”
“我没法再看下去了，到处是问题，以至于我没给你写几条评审意见，请好好阅读 XXX 规范文档！”
……
到处放炮型评审
这些评审者思考一个问题的时候，想得非常全面，全面到病态，但是非常浅层次，他们像领导一样指出你的文档或者代码到处都布满了你少考虑到的东西，但是只给你看的时候，一律点到即止，绝不深入展开。相信你一边自惭形秽，一边会对他们崇敬有加：“领导就是领导（老员工就是老员工），就是见多识广”。
譬如，你设计了这样一个方法：
public void storeAsFile(Data data, String path)
他会给瞬间抛出无数个问题：
把数据存储为文件，磁盘已经满了怎么办？没有权限怎么办？存储到一半的时候发生故障了怎么办？写文件的时候断电了怎么办？写文件写到一半的时候突然发现磁盘不够用了怎么办？写的时候性能怎么样？大家都在写文件，文件会不会有很多碎片？路径过长怎么办？一个文件夹下文件过多怎么办？文件名有操作系统不接受的字符怎么办？……
OMG，这个世界太复杂，我的大脑太简单。或许，大师你的设计文档可以写到辞海那么厚。
只捡芝麻型评审
这类评审人员有一个共同的特点，不深入代码或文档，显著的、设计上的问题、深入的和充满意义的问题一律不关注（事实上，他们也挑不出那样的问题），只看那些拼写、语法、格式之类的问题。这些问题严格来说都可以列为问题，但是这些问题的一个共同特点就是，都是一些非常简单和鸡肋、次要的问题，或者是公司或团队某些无良人士自己定义的某些无聊规范上的问题，并且是不深入业务、设计和实现，完全可以找出来充数的问题。
有一些领导远离了技术很多年，但他们依然可以用如此方式的评审来证明自己：“瞧，别看我现在不设计编码了，但是我掌握的技能依然炉火纯青，我依然可以挑出你代码里面几百个毛病来！”，于是他们一样让你崇敬有加：“领导就是领导（老员工就是老员工），就是做事细致”。这些问题包括：
“这个单词的一个字母大小写错误”，“这个 tab 格式要换成四个空格”，“这行注释上面为什么多空了一行？”，“这个地方的注释语句少了句号！”，“这个变量名还不够清晰”，“这个包下面没有增加一个包说明文件”，“这个类的注释量太少，需要增加到 XX%”，“这个 for 循环可以改写成 while 循环，代码看起来会更简单”，“这里 final 和 static 关键字的顺序写错了”……
好吧，看起来，一个再简单的实现，你也可以被批得体无完肤。
吞吞吐吐型评审
他们在思考问题的时候，确实有自己的想法，但是碍于关系、面子、资历、辈分，无法充分和一针见血地表达自己的态度和观点，而是选取了一种话说一半、唯唯诺诺的方式：
“可能是我的见识短浅，我觉得这里似乎可以考虑一下文件不存在的场景，您看是否可以？”，
“此处仿佛存在一个未曾考虑到的场景，请指教”
“建议此处考虑存在的空指针异常”
……
这样的评审意见其实相对于之前说到的几种，要显得实际和有效，但是有一种让人起鸡皮疙瘩的感觉，而且由于评审时过于谨慎和惶恐，评审效率和表述深度都很难保证，评审意见中堆砌了大量的客套话。
对于代码和文档的评审，我有这样的几个建议：
1、评审是一个交流和学习的过程，大家都是平等的，不要鄙视别人，更不要鄙视自己。
2、有不合理、欠考虑的地方要指出，精彩的设计、优秀的想法也要鼓励，评审不是只挑毛病。
3、不要担心和害怕犯错！所有的软件过程都是带来产品和团队进步的过程，为了担心一个可能的错误，扼杀了自己的思维火花，就太不值得了。
4、就事论事，争论是值得鼓励的，但是不可以上升到人的层面上来。
你还见识过什么样的牛叉的评审风格，你还有什么想法，和我分享一下如何？
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
又是转载不标明作者和出处的。赤裸裸的剽窃。