标签归档:代码审查

如何让代码审查更具人性?

最近,我一直在读有关代码审查最佳范例的文章。我注意到这些文章的关注点是找到 bug,而忽略了代码审查其他的部分。用建设性、专业的问题沟通方式?不相关!只要识别出所有的 bug,剩下的部分会水到渠成。

现实中的代码评审

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

京东资深架构师代码评审才诗

架构师说, 用20个字描述代码评审的内容, 自省也省人。由于是一字一含义, 不连贯, 为了增强趣味性, 每句都增加对应的歪解。只是对常见评审的描述, 不尽之处,欢迎补充!

如何做有效的代码审查?我有这些建议

往往代码评审过程中,评审者(Reviewer)往往会过于关心旁枝末节,而忽视主要问题,也就是所谓的自行车棚效应。在批准价值百亿的核电站的建设提案中,专家们往往会浪费大量时间纠结于厂内自行车棚(bikeshed)的颜色;因为核电站太大、太复杂,“专家们”未必真懂,但总不能不说话啊,那就从无关痛痒的自行车棚挑毛病吧。

代码审查与重构的5个层次

统一的代码风格规范是团队开发的重要要素之一。代码规范的统一有利于代码的阅读维护,有利于代码的“集体所有制”。试想,如果团队中每个人都使用自己的一套代码规范,那整体的代码风格就可谓“百花争放”,最后的结果就是代码越来越混乱,且难以阅读维护。我们项目中统一的代码风格概括来讲有如下几个方面: