如何做好Python代码的Code Review

上周应百度工程效率部的邀请，在公司内做了一个关于Python Code Review的分享。

关于Code review这个话题，我有一些自己的体会。

最早实践code review，大概是在2000年前后。当时在清华的教研组里面做863项目。code review的方式主要是互相看看代码，然后将修改的建议写在一个临时的文件中，比如 “ **文件的**行，建议修改成为**"。这是一种相对原始的reveiw方式，也就是没有很好的工具支持的方式。据我了解，目前在中国不少公司里还是采用这样的review方式。

2010年在腾讯，赶上公司大力推动code review。据说是当时吴军和朱会灿两位大神到腾讯，很震惊于腾讯居然没有严格的code review。据说即通原来做的是不错的，但是我所在的腾讯网确实没有硬性要求。虽然公司大力推动，但是到我2011年离开的时候，code review也没有非常严格的执行。也不知道现在腾讯那边的情况如何。

2012年底来到百度，感觉百度的code review工具链做的还是很不错的。有code review的工具，可以很容易的在提交的代码中插入批注；也很容易追踪代码的修改；包括严格的权限机制，没有经过owner review的代码根本无法提交。这么好的工具链是我在之前的经历中从来没有遇到的。于是BFE团队也在几年中一步步的实施了越来越严格的review制度。

虽然公司提供的工具不错，但是能否发挥效力，还要看各个团队的执行。作为公司python good coder考试的二审，我也确实发现了不少的问题。很多一审通过的代码，还存在大量的问题；我也和一些同学沟通过，发现在他们的团队中，根本没有code review。不理解，不重视，不知道怎么做，这是code review中存在的主要问题。这也是我为什么愿意出来分享的原因。

关于封面配图：

我几乎立刻就想到使用”八里桥之战“这张图。1860年的这场战役中，虽然大清的将士奋勇冲锋，但是仍然惨败，中方伤亡一万多人，而对方只伤亡十多人。在这处战役之后，就是大家都感觉非常痛心的火烧圆明园。落后就要挨打，这是中华民族用100多年来学到的教训。

在软件开发领域，我希望用这段历史来提醒大家：和那些先进的公司相比，我们也好像是拿着落后兵器的那一方，还在依靠我们的体力、而不是脑子在工作。在体力领域，人和人的差距不过是十倍以内；而在软件开发领域，差距可以达到几十倍、上百倍。所以除了加班加点，我们更需要学习先进的理念和方法，努力提高工作效率。

谢谢关注微信公众号 章老师说

教育、学习、思考、实践，为了一个更好的中国