谈谈代码检视（一）

code review

工作以来一直从事软件类工作，在软件开发中，代码检视是其中一项工作。但是实际上你经常会听到下面的一些陈述。

• 代码检视就是浪费时间

• 项目这么紧，我没有这么多时间来代码检视
• 版本发布已经延期了，可是我的搭档还没有检视我的代码
• 他竟然检视出来一些代码风格的问题让我改

如果把问题深入下去，本质上可以分解为2大问题

• 觉得没有用

• 就是不会做

本篇先说觉得没有用的问题，我想这类人可能没有在项目中真正吃过亏。

举个例子，你写了几千行代码，接着项目结束，这时候产品上线了，在开始几个月里由于业务量小（用户量，吞吐量），并没有什么问题暴露，但是3个月或者半年之后，业务量上来了，出现了一些严重问题，这个时候，老大把你从新项目中叫回来定位一下，你看着自己半年前写的代码，自己也没有什么头绪，因为代码从来没有自我检视和给他人检视过，加上代码没有什么注释，毫无规范性，只有机器读的懂，你吭哧吭哧连续通宵了好几天，才算回忆起了自己的代码逻辑，总算定位并且解决了问题，如果你善于总结，你可能会有点什么想法了。

代码并不是只给机器读的，如果代码写出来能够让人或者对此业务和你差不多熟悉的人读的明白，清楚，进而还能提供一些反馈意见，对你将来维护这部分代码，那可是功德无量的事情。

很多开发人员图省事，图快，形成了代码可以编译，可以运行就认为事情已经圆满完成了，殊不知给自己埋了大坑，给测试人员，后续的维护人员埋了巨大的坑。

前面我写过一篇 《生产者和消费者》，提到过，全栈工程师 的概念，我相信将来必定会往此方向发展，也就是说，开发人员不仅仅只是写代码（前端，后端代码全包），还能自己单步调试，代码评审，拉别人一起来代码评审，单元测试，系统测试，甚至集成验证。

我认为代码除了编译，可运行外，还得考虑可测试，易读，易维护，而这些就需要编码和设计层面就考虑到，在设计阶段考虑可测试性，可维护性，可靠性，在编码时候能够遵照设计和编码规范进行。

觉得没有用，还有心理方面的因素，在小时候的教育中，我们上学的每天会有家庭作业，然后老师会检查我们的家庭作业，很多时候，我们就会害怕老师，因为我们大部分时候会得到负向反馈，作业中的更正点的反馈，还有评分/评语。如果把写代码比喻成完成作业，很明显，我们完成作业后就希望不要有人指指点点，不要有人评审自己的代码，进而得出觉得没有用的结论，目的就是你们TMD不要对我（我写的代码）瞎BB。

归根到底分析，实际上还是开发人员对自己写的代码没有信心，想想看，如果你的水平和老师一样，你还会担心老师的评语和评分吗。老师给你反馈（无论正面反面），你是可以和老师交流甚至反驳的，事实上老师也是希望帮助你，而你自己是帮助了自己。

​其实觉得没有用的观点是站不住脚的，只是人们还是急功近利，只看到眼前的利益（项目进度），没有看到几个月后的灾难。对于新员工，这么想我觉得没有问题，但如果老员工（吃过亏的人）和研发经理也这么想，那就要好好看下这样的人是不是从来不总结和思考的。

下一篇我重点谈谈，代码检视如何做的问题

我的微信公众号：瓦力工坊
我的微信：jhhuawei