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

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

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

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

时间投入上的权衡

time management

时间管理被很多人忽略了。被忽略的一个原因是,我们被洗脑洗得太久,读到的鸡汤文太多,觉得一个人的主观努力程度扮演了过度重要的作用。事实上,这里有两个问题,一个是如何评价目标的达成,特别是人一生这个大的范围内的评价,鸡汤文中总把一个人在事业上的“成功”列为最大的目标,但实际我觉得这只对一部分人成立;另一个是,即便这个目标成立,主观努力依然被高估了——或者说,主观努力当然重要,而且对于大多数人来说,天赋并无法起到决定性作用,但是,许多人的主观能动力是类似的,结果却大相径庭。这里面,除了主观努力和先天天赋以外,明显还有别的因素在起作用,而时间管理就是其中之一。

几年前写过一点关于时间的 文字 ,不过都是

[……]阅读全文

文档那些事儿

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

image

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

[……]阅读全文

写给实习生的第一天

intern

实习生(intern)和新员工有所区别。实习生仿佛一个长达 12 周(三个月)的面试,一起工作,一起解决问题。在最后有答辩和 debrief meeting 讨论结果。可能通过了,最后公司给 offer;也可能没有通过。即便给了 offer,还要面临双向选择,有可能实习生不理 offer,继续求学或者去别的公司,当然也可能选择到别的团队。

我的习惯是,见面的第一天,这些内容是必须要交代清楚的:

1. 近视和远视。

你会在接下去的时间里遇到大量的问题,也要去解决大量的问题,有的问题解决会让你获益很长时间,但是大多数问题解决也只是帮助当时的那个你。我们尽量选择一个平衡点,既要为了完成项目,解决那些无趣,但是又

[……]阅读全文

研发团队的角色和构成

software engineer

以下都来自我的经历,带有主观评价,但是尽量保持平直的论述。

在我工作的第一家公司的时候,一个典型的研发团队是这样组成的。我的经验也只是到 4 年前,现在也许早就不一样了呢。

项目经理,这个角色是不断在换的。项目经理当然是只跟着项目走,这和团队经理(Team Leader)是不一样的。当然,Team Leader 也往往在不同的项目里面兼任项目经理。基层的项目经理也可能会编码,但是不管参与不参与编码,工作压力都不小。

SE(System Engineer,相当于现在大多数公司的产品经理)负责从市场部门等地方承接需求,然后做“系统性设计”,这个系统多数指的是业务系统,也指有时候软件系统。之前我在 一篇文

[……]阅读全文

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

helpless

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

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

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

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

比如这样的话:

写好代码是

[……]阅读全文

手滑的故事

slippery

最近看到这篇文章 《小伙伴们手滑集》,觉得感慨很多,强烈推荐大家阅读。比如这样的例子:

UPDATE 没有 WHERE 条件

而我则经历过 delete 没有写 where 条件的惨剧,这个惨剧是某些 case 下面代码调用触发的,不是手动执行 SQL 发生的。

还有臭名昭著的,我没有经历过,但是我有不止一个同事干过这样的事情:

rm -rf

都只是手稍稍地温柔地“滑了一下”而已嘛……

这些事情我觉得一下子很亲切,似乎全世界的软件工程师都是如此得同一。

出的事故多了以后,变得战战兢兢,如履薄冰,尤其是回车键这样的敲击,似乎总是带着颤抖落指。

还有这篇文章 《让自家系统瘫痪,这事我也干过》,讲了一个关于使用 tr

[……]阅读全文

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

最近有这样一条 热门微博

content

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

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

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

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

[……]阅读全文

进阶过程:程序员做项目的独立性

project 第一阶段:编码机器

这是最低级的阶段,程序员拿到详细设计文档,上面连许多方法接口都定义好了。重构一些代码,写一些实现,调用一些既定的 API,然后花许多时间在各种各样的场景测试上面。从做的工作上看,这都不能算程序员,最多,只是编码技巧卓越的码农而已。因为它几乎扼杀了一切创造力,但是这很常见,比如在一些对日外包公司,就是如此。

第二阶段:独立的实现者

程序员得到的只是粗略的设计文档,也许注明了外部接口的清单,还有框架和基础设施的 API,需求已经澄清清楚,接下去要做的就是发挥聪明才智把软件实现设计好,把代码写好,测试通过。这项工作可以在安静和独立的环境中完成,因为没有什么是不够明确的,那些本不清楚

[……]阅读全文

几种华丽无比的开发方式

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

 

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

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

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

[……]阅读全文

《Rework》语句摘录

37signals《Rework》是让我有所感触的一本书,推荐阅读。作者是 37signals 的创立人 Jason Fried 和 DHH(没错,此人正是 RoR 的作者)。37signals 有两本书,除了这本,还有一本叫做《Getting Real》。

整本书都在做 37signals 价值观的宣扬,37signals 是一家颇为特别的公司,小,但是非常酷,有一些想法令人叫绝。他们做的东西,用他们自己的话来说叫做“web-based collaboration apps for small business”,整个公司只有 35 名员工,遍布世界各地,产品优秀,RoR 名声在外。

我喜欢做大事的大公司,但是更喜欢那些做大事的小公司

[……]阅读全文

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

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

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

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

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

[……]阅读全文

解雇专业的运维人员吧

mt 在很多情况下,运维占到软件成本的大块,专业的运维人员更是不好找。这样的人需要熟悉操作系统、网络以及数据库。而运维又是一件很苦逼的事情,成了算是软件写得好,研发团队的功劳;败了就得彻夜坚守岗位提供支持,不可控的因素太多。是上游团队的软件质量太差吗?

我在 09 年的时候曾经到过局方,呆了挺长一段时间,既是开局,也做运维的工作,和运维的工程师朋友一起蹲机房、守夜、切设备,知道其中无比的苦楚。很多情况下,版本的更迭、割接,都要在凌晨完成,需要仔仔细细地测试;不幸失败了还需要立即回滚,然后陪着项目组等领导骂,等新版本或者补丁到来,再重复熬夜的这段过程……

不如大胆一些,解雇你那些抱怨不止、喋喋不休的运维

[……]阅读全文

工作压力的问题

1 程序员的工作是紧点好还是松点好?

对个人的影响

有人说紧点好,理由是可以从中学到东西,这是一种压力驱动式的学习方式;也有人说松点好,可以有大把的时间去闲逛、打酱油。前一种人至少是上进的、积极的,只是兴许是由于教育体制和软件大环境的原因,已经失去了许多主动性,非得要环境逼迫的压力下才能去学习、去分析和解决问题。

其实,大部分刚毕业的程序员都属于前一种,他们至少是努力着去提升自己,设法去写出好的代码,有一种追求卓越的愿望。但是,我们从来的教育都是这样,喂食—— 吃食,喂食—— 吃食…… 到了大学,喂食的情况少了,于是颓废、

[……]阅读全文

过度工程

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

 

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

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

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

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

[……]阅读全文

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

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

 

一坨屎型评审

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

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

[……]阅读全文

代码评审鲜为人知的好处

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

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

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

 

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

 

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

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

[……]阅读全文

Good Surroundings For Programmer

surroundings Programmers are those who work on creation, and they’re simple, hard-working and careless about dressing. They really need some special conditions to help to exhibit their creativity, since the very work is easily affected by environment.

1. Comfortable chairs. Programmers can keep a good sitting p

[……]阅读全文

我们的时间去了哪里?

clock 做一个大型的 WEB 项目已有近两年,兄弟姐妹们总在忙忙碌碌中度过,看似很充实,可是当每个版本结束,我想我们又完成了一件大事,可是紧张的项目周期加上持续的加班,客户和一线还是对版本质量不满意。看到完成的作品时,我总有一种感觉:投入了相当大的人力,团队成员也兢兢业业,按说时间应该绰绰有余才对,可是实际上为什么我总觉得版本紧张,我们的时间怎么那么容易就被消耗掉了?

 

内耗之事

不可否认当一个团队人数越来越大,就越需要流程来约束人、管理人,可是团队越大,就越容易产生沟通、交流的内耗,尤其是流程产生的内耗。项目经理或者团队 Leader 能够及时识别出这样的内耗,就显得尤为重要。

流程的内耗,比

[……]阅读全文

功能、模块质量和非功能性测试

prj 但凡面向终端用户的产品,产品做大了以后,几乎都要涉及到基线能力和定制能力的划分。任何一个优秀的产品,都要经历从相对无序到有序的逐步成熟的过程。产品的发展总是要经历不断的阵痛,可是时间长了,我还是总免不了思考:好吧,就算产品最初匆忙和艰辛的时期已经过去,就算现在基线能力的建设已经迈入正轨,可是为什么我们的直接客户,定制团队还是那么辛苦?

 

有多少功能是真正值得去完成、真正被用户所需要的?

据一位定制的兄弟说,其实这个比例只有 8%,我相信数据也许是不准确的,但不管数据的有效性有多少,至少,大家都在问,产品的定位是一个厚实的门户,有太多的功能需要完成,可是真正给客户使

[……]阅读全文

back to top