评审的艺术——谈谈现实中的代码评审

曾经写过一点关于代码评审(code review)的文章,比如这篇这篇,现在觉得关于它的认识又有了不少更新。软件工程的技术和实践分成两部分,一部分是和书本知识一致的,大约占一半,这部分基本上在大学里就可以学,自学只要方法得当、刻苦努力也可是途径;但是第二部分来自于实际团队、经验,内容通常无法从书本当中获得,而且难说对错,不同的人和不同的经历造就了不同的认识。代码评审就是第二部分颇具槽点,可以大加讨论的典型。

代码评审是展现个性和性格的途径

我本人特别反对一种颇为常见的观点,就是 “一个良好运作的项目,不同的人,应该写出一样的代码”。我非常理解这种观点的初衷,一个良好规范约束的团队中 [……]阅读全文

继续说说 “在家办公”

我在几年前写过一点对于在家办公的理解,经过最近几年的感受,时不时地需要在家办公,零零散散陆陆续续有了一些新的感受。

首先要明确的是,团队的支持是最重要的。需要一个宽松的团队氛围,能够获得足够的信任,这些都是软基础。如果同事和上司不信任,这件事情是不可能办成的。对于那些把员工视为不可靠、不安全因素的公司,在家办公也是难以实现的。

开发环境。以往我一个不愿意在家办公的重要原因是,我的开发环境都部署在 desktop 上面,从家里无论是通过 Microsoft Remote Desk 还是 NoMachine 之类的连接(我还试过一些别的持有图形界面连接的方式),都不够理想,一顿一顿的,写代码很难受 [……]阅读全文

文档那些事儿

还记得在 2008 年我做毕业设计的时候,自己心里有一个朦朦胧胧的概念,大概是说,要规范,制度上有标准,流程上有遵循。于是噼里啪啦整了软件工程十项文档,再加上一些辅助性文档就有了下面这个清单。我以为那样的全面会带来更好的评价,但是老师说,“太多了”,我很困惑,难道文档全面、综合,而且完备,这不好么?

image

在 Amazon 有一个大家都知道和反复自黑的事情。所有 team 都用 wiki 来记录和维护项目、产品有关的事情,但是绝大多数 wiki 的内容都是过时的和不准确的。有几次和其他互联网公司的朋友讨论过这个话题,大家都付诸呵呵一笑,原来大家都差不多。这让我思考,是不是文档这样的东西,和代码不同,它更容易过时,它

[……]阅读全文

扒一扒知乎上的帖子——“为什么有些大公司技术弱爆了?”

helpless

知乎上看到一个热帖,我觉得很有意思,叫做 “为什么有些大公司技术弱爆了?”。我刚看到标题的时候,先入为主和刻板偏见了一下,正如同第一个回答一样,我皱了皱眉头,产生了对题主的鄙视之情;但是很快,读完帖子以后,我却立场明确地站到题主一边了。正如同里面有位回答:

看题目以为是题主傻逼,看了正文发现真的是公司傻逼。

上面这种情况其实发生的概率挺低的,但是我觉得这回是真的发生了。

但是令我感到遗憾的是,各式各样的回答里面,大部分居然都跳出来 “教育” 题主,表态这个世界就不是完美的,表态要妥协要接受这样的事实,要无奈地咽下这个现实的苦果。这个大面积出现的观点,太不正常了吧?

比如这样的话:

写好代码是

[……]阅读全文

这样的傻事,其实并不遥远

最近有这样一条热门微博

content

这样的故事真是精彩。最后一句“ 我想那是我此生唯一写垃圾代码的心安理得的一次机会了”,我明白至少作者还是有追求的。

任何 KPI 要合理都是无比困难的,这里的故事看起来有些极端,但就是一个简单地拿“ 代码量” 数据统计来量化绩效指标的办法。这样的恶果公司最终会自己承担。

我曾经在这篇文章里面谈到过,统计指标是有价值的,但是如果设置这些量化指标给程序员套限,则是违背客观规律的行为。我称它们为反软件、反人类的。

我所见到的量化的指标皆是如此。程序员本来就是在利用死板的代码和数据,创造一些工具,完成一些重复性和可以预期的劳动

[……]阅读全文

在家办公,你还有多远?

WFH

先上一段全球最著名的“ 在家办公” 的公司——37Signals 的宣传视频(最近他们网站变成了 Basecamp;他们有一本书《Rework》让我很喜欢,当时甚至还写了摘录,他们去年出的书《Remote》居然已经有人翻译了放在网上,感兴趣的话可以去简书看一看):

在家办公是一个经常被讨论的话题。当然,在很多软件公司甚至是一个禁忌的话题。但是,越是这样的话题,越有趣,不是吗?

对于绝大多数软件公司来说,无论算不算具备浓厚工程师文化的公司,在家办公(work from home)都应当是一个不可以缺少的组成部分。我不相信尝试把软件资产锁在公司大

[……]阅读全文

不同团队的困惑

team

小 S 是一名新员工,他和很多踌躇满志的大学毕业生一样,实习+工作,他来到了一家非常对口自己爱好的公司,来到了一支温暖的团队 A,这支 30 人的大团队由老员工和新员工混合组成,年龄结构复合,有男有女,有从二十几岁到四十几岁的程序员,做的视频编解码项目。整个项目组的成员都是视频编解码领域的能手或专家,最多的有 10 年的相关经验,也有几项专利,小 S 觉得这样的人应该很耐得住寂寞,有很深的造诣。

有一位导师手把手地带着他学习和进入项目,陪他一起吃饭,和他聊天,给了他公司内部通用的学习材料。于是他很快上手,最开始有一些疑惑,但是小 S 积极地去询问问题,导师和同事都很乐于帮助他,于是他进步很快。公司有一个专门帮

[……]阅读全文

几种华丽无比的开发方式

work 不要被我的标题骗了。我可不是来宣扬什么模型驱动开发,或者什么测试驱动开发的,那些都弱爆了。今天我要说的,是几种看起来激动人心、华丽无比,但是可以让程序员们痛苦不堪的开发方式,特别适合那些热衷于折磨虐待程序员的项目经理和产品经理们。当然,掌握以后,偷偷用就好了,请不要来感谢我。

 

进度驱动开发(SDD,Schedule Driven Development)

这是在国内最为流行的开发方式,大家心照不宣,口口相交,代代相传,我只是把它写下来而已。它最华丽的地方在于,可以百分之百,甚至百分之二百地压榨程序员的劳动力。

需要实现哪些需求?用什么技术?用什么平台?项目采用什么流程管理?这些

[……]阅读全文

对几个软件开发传统观点的质疑和反驳

why 下面这些观点都是程序员在教科书上、在编码规范里、在正统的软件工程流程里流传开来的,帮助了许多人在程序员启蒙期间养成了良好的习惯、原则。对许多人(包括曾经的我)来说,似乎是理所当然的。但是随着阅历的增长,视角在变化、看法也在变化,曾经的好恶现在都可能大翻身了。

为代码写足够的注释,让代码易于理解

“ 所有程序员都会写自己看得懂的代码,但只有优秀的程序员才写大家看得懂的代码。” 这话没错,但是——

  1. 什么才是“ 大家看得懂” 的定义?我有必要让我的 C++代码对于一个月前才明白指针和引用区别的初学者简单易懂么?
  2. 更重要的

[……]阅读全文

过度工程

prj 过度工程,最初我知道这个词是在 Rod Johnson 的《J2EE Development without EJB》,随着阅历地增长,渐渐发现书中熟悉的场景也在身边再现了。

 

敏捷、还有设计模式,给一个团队带来了什么?

我之所以把这两个词放在一起讲,是因为我要说一件显而易见的事情,可是这样一件事情很多人又不愿承认。

团队,是有风格个性的;团队,也是有能力强弱的。不管你承认不承认,整体来说,我见过的绝大多数团队都还远不是精英团队,因此相对于某些公司成功的案例来说,我们有很多事是不适合做的。

敏捷强调了主动性,强调了沟通,事实上并不是身边所有的团队都能做好敏捷管理的,譬如一支

[……]阅读全文

Process and Corporate Culture

1 Corporate culture is not only a concept that a company uses to attract talents, but also a spirit and method running through the management. Here, I'll talk about the process, which reflects the characteristics and culture of a company as well.

As we all know, a small company cannot handle com

[……]阅读全文

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

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

 

一坨屎型评审

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

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

[……]阅读全文

代码评审鲜为人知的好处

code_review 代码评审究竟有什么好处?

在前期发现问题,提高软件质量,降低软件成本。

事实上,代码评审的好处远不止这些。有些项目经理或者开发人员不愿意多提评审,Coding 的过程包含的内容非常丰富,如果只把一个字符一个字符地敲代码叫做 Coding,未免悲哀了一点。优秀的项目,编码阶段实际敲代码的时间不会很长;优秀的程序员,大部分时间都用来思考了。

 

我来说说代码评审其它鲜为人知的好处,兴许能改变某些同学的看法呢。

 

增加阅历,学习别人代码的可贵之处

和英语学习是一个道理,如果只听一种纯正口音的英语,英文反而不容易学好,我们需要阅读各种营养的代码,广泛阅读能帮助开阔眼界,积累一些好的

[……]阅读全文

back to top