敏捷开发：代码Review

热情高涨

代码走查作为一种流程形式，起初大家的参与热情非常高涨。

因为，自己可以学习到别人一些巧妙的思想，自己的代码和习惯都暴漏出来。

这个过程中不断地吸收和改正。

但是。。。。。。

我们一开始组织的代码走查是一个很重的会议形式。

参加的人有写这段代码的人（小菜）、比较有经验的开发（大佬）

如果为了再隆重一些，请一些领导也参与其中。

但是。。。。。。

我上面提过了，会议很重，协调时间这个事情就是一个很费时间的事情。

还有就是，大家恨不得对每一句代码都发表自己的意见，往往非常的细枝末节。

导致会议时间经常在2小时以上，3小时时间就一般不得不停止。

大家都很累，再就是效果如何呢？

如果小菜自律性不够，甚至没人进行监督，这次的审查的代码不是都会修改。

因为有一些确实太过于鸡蛋挑骨头，根本改不动。

热情褪去

不知不觉中，这种方式慢慢褪去。代码走查成为了一个优先级、频次都不高的活动。

有很多原因，上面说的形式太重是一个，还有就是大家都很忙了，没有进行持续跟进导致效果不佳。

但是。。。。。。

也都知道代码走查对一些新人来说，成长史毋庸置疑的。收获也是毋庸置疑的。

慢慢大家也都放下了。只是每次项目迭代中作为一个硬性要求执行一次罢了。

痛

我们小组里面只有我还有一个刚毕业一年多的女生。

在我们组内的一个项目中，我总是以任务重为由，没有进行代码走查。这个持续了很长时间。

一个字 —— 懒

在处理客户反馈的问题时候，我突然发现，她写的代码确实出现了比较粗心的失误。

我心一想，长达3个月的时间都没有对她的代码进行任何关注。

于她于我于项目，都是极其不好的。我这块做得太自私了。

改

于是我在gitlab上加上了 【合并请求权限】，逼迫她去仔细思考自己的代码，逼迫我必须去看她写得每一行代码。

合并请求权限

提交合并请求

代码走查

其中有规范、命名、优化、风格、bug

......

收获

是的，这些时间付出是有价值的。是潜移默化的。很多时候我们为了Review一个问题点，讨论20分钟。

一方面深入挖掘她当时的思路：是知识面问题？还是偷懒？还是知道这样后期再优化？

另一方面，也把我的想法和思路进行交流。有几次是我认知就是错误的，通过讨论发现了更好的实践。

其实代码Review真的是一种非常好的实践，我们不能以我们过来的人的眼光看待新人。

他们有他们的优点，当然他们也很可能会犯错。我们使用一点时间，就能把这个问题给找到，对我们对他们都是一件好事。

再加上，代码review也是把团队和部门甚至公司的制度流程以及规范进行一种培训。只是换了一种方式。

至少我觉得我是有收获的，通过几次交流，成员也说明自己确实有收获。

刚刚进入社会，刚刚入行的软件工程师们，不都是自律能力非常强的。都有惰性。

通过这样的形式，让她感知提升，增加自信心，所以后期很多时候她都会把一些好的想法，反过来给反馈给我，我觉得确实是。于是我就偷偷回去改我的代码。

这也是一种沟通渠道，我觉得很多时候软件就是在解决沟通问题。如何让沟通做得有价值，有效率。

进

有了收获，我依然想进行再一步的精进。找到一本书，能完全肯定我们现在做的事情是一种有价值事情的书籍。

《代码整洁之道》 《重构2》

规定时间里阅读完一章，找出系统中不好的，并按其思想进行修改。或者系统中已经这样做的，找出来分析一下。时间不用很长。

从命名规范、函数分解、同一抽象层次分层、硬编码、效率、类、模块、甚至文件夹构成

为什么要做这些？

首先，我们先不去追踪复杂的效率问题，先解决简单功能实现，后期有人能看懂的问题。

这些实践容易，并且效果明显。有效果，我们就喜欢更深层次提升，再深入提升，就会自然而然晋升到了性能层面。

现在我觉得我和成员的一些讨论都在讨论执行效率。因为代码的命名、分层已经潜移默化养成了习惯。

有了成就感，就有了动力，有了动力，再去研究就会更加主动一些。

我也因此偶尔再总结一下，确实好的代码，令人心旷神怡，赏心悦目。更有读下去的冲动，甚至更有模范的冲动。

K.I.S.S 原则、单一职责、多用组合少用继承、最少知道原则等

很多时候，功能很简单，我们却写得天花乱坠。

我幻想了一下，如果我们的客户他喜欢编程，非要看源代码实现呢？如果他看到源码实现如此简单优美，心中如何感慨？

有时，我也时不时小结一下。

    新人需要我们的指导，才能避免一些弯路；

    我们也需要不断回炉锻造；

    对代码多一些敬畏和欣赏~