Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

那些牛叉无比的评审风格,你,属于哪一种?

Posted on 02/16/201206/23/2019 by 四火

1 在这篇文章里,我们可以见到许多有意思的编程风格,又没有精神为之一振的感觉,仿佛里面的例子就在自己身上,或者离自己很近。其实,对于文档、代码的评审,也是有诸多风格可言的,我这里列举一些有意思的典型:

 

一坨屎型评审

阅读文档、代码的时候,这些东西在自己眼里就是一坨屎:“我这么高智商的人都看不懂,明显是你有问题!”。

这样的人有一个他自己相当认可的世界观,凡是和这个世界观相冲突的无论对错的事务,必须强力排斥。这样的人眼中容不下复杂的东西,复杂对他的智商而言是一种侮辱,他会选择下结论的方式来拒绝自己对文档或代码的进一步阅读;对于和自己预期不一致的设计和实现,必须升级为人身攻击,挥舞狼牙棒子痛骂一顿,最后得出的结论就是,“很明显,这个人创造的东西是一坨屎,这个人也是一坨屎。”

这样的评审表述有:

“这里体现了一个问题,你考虑问题太缺乏全面性和深入性”

“这里写的太烂了,请重写”

“这是什么,我看不懂,和我的实现方式不一样,请改到我的那种实现方式上去”

“我没法再看下去了,到处是问题,以至于我没给你写几条评审意见,请好好阅读 XXX 规范文档!”

……

 

到处放炮型评审

这些评审者思考一个问题的时候,想得非常全面,全面到病态,但是非常浅层次,他们像领导一样指出你的文档或者代码到处都布满了你少考虑到的东西,但是只给你看的时候,一律点到即止,绝不深入展开。相信你一边自惭形秽,一边会对他们崇敬有加:“领导就是领导(老员工就是老员工),就是见多识广”。

譬如,你设计了这样一个方法:

public void storeAsFile(Data data, String path)  

他会给瞬间抛出无数个问题:

把数据存储为文件,磁盘已经满了怎么办?没有权限怎么办?存储到一半的时候发生故障了怎么办?写文件的时候断电了怎么办?写文件写到一半的时候突然发现磁盘不够用了怎么办?写的时候性能怎么样?大家都在写文件,文件会不会有很多碎片?路径过长怎么办?一个文件夹下文件过多怎么办?文件名有操作系统不接受的字符怎么办?……

OMG,这个世界太复杂,我的大脑太简单。或许,大师你的设计文档可以写到辞海那么厚。

 

只捡芝麻型评审

这类评审人员有一个共同的特点,不深入代码或文档,显著的、设计上的问题、深入的和充满意义的问题一律不关注(事实上,他们也挑不出那样的问题),只看那些拼写、语法、格式之类的问题。这些问题严格来说都可以列为问题,但是这些问题的一个共同特点就是,都是一些非常简单和鸡肋、次要的问题,或者是公司或团队某些无良人士自己定义的某些无聊规范上的问题,并且是不深入业务、设计和实现,完全可以找出来充数的问题。

有一些领导远离了技术很多年,但他们依然可以用如此方式的评审来证明自己:“瞧,别看我现在不设计编码了,但是我掌握的技能依然炉火纯青,我依然可以挑出你代码里面几百个毛病来!”,于是他们一样让你崇敬有加:“领导就是领导(老员工就是老员工),就是做事细致”。这些问题包括:

“这个单词的一个字母大小写错误”,“这个 tab 格式要换成四个空格”,“这行注释上面为什么多空了一行?”,“这个地方的注释语句少了句号!”,“这个变量名还不够清晰”,“这个包下面没有增加一个包说明文件”,“这个类的注释量太少,需要增加到 XX%”,“这个 for 循环可以改写成 while 循环,代码看起来会更简单”,“这里 final 和 static 关键字的顺序写错了”……

好吧,看起来,一个再简单的实现,你也可以被批得体无完肤。

 

吞吞吐吐型评审

他们在思考问题的时候,确实有自己的想法,但是碍于关系、面子、资历、辈分,无法充分和一针见血地表达自己的态度和观点,而是选取了一种话说一半、唯唯诺诺的方式:

“可能是我的见识短浅,我觉得这里似乎可以考虑一下文件不存在的场景,您看是否可以?”,

“此处仿佛存在一个未曾考虑到的场景,请指教”

“建议此处考虑存在的空指针异常”

……

这样的评审意见其实相对于之前说到的几种,要显得实际和有效,但是有一种让人起鸡皮疙瘩的感觉,而且由于评审时过于谨慎和惶恐,评审效率和表述深度都很难保证,评审意见中堆砌了大量的客套话。

 

对于代码和文档的评审,我有这样的几个建议:

1、评审是一个交流和学习的过程,大家都是平等的,不要鄙视别人,更不要鄙视自己。

2、有不合理、欠考虑的地方要指出,精彩的设计、优秀的想法也要鼓励,评审不是只挑毛病。

3、不要担心和害怕犯错!所有的软件过程都是带来产品和团队进步的过程,为了担心一个可能的错误,扼杀了自己的思维火花,就太不值得了。

4、就事论事,争论是值得鼓励的,但是不可以上升到人的层面上来。

 

你还见识过什么样的牛叉的评审风格,你还有什么想法,和我分享一下如何?

 

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 从 DCL 的对象安全发布谈起
  2. 代码评审鲜为人知的好处
  3. 评审的艺术——谈谈现实中的代码评审
  4. 运行时动态增加枚举类型
  5. 再议单例模式和静态类

1 thought on “那些牛叉无比的评审风格,你,属于哪一种?”

  1. 四火 says:
    12/04/2012 at 9:57 AM

    又是转载不标明作者和出处的。赤裸裸的剽窃。

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme