敏捷开发:代码Review

热情高涨

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

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

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

但是。。。。。。

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

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

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

但是。。。。。。

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

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

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

大家都很累,再就是效果如何呢?

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

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

热情褪去

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

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

但是。。。。。。

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

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

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

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

一个字 —— 懒

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

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

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

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

合并请求权限

提交合并请求

代码走查

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

......

收获

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为什么要做这些?

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

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

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

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

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

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

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

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

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

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

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

    对代码多一些敬畏和欣赏~
posted @ 2020-01-05 12:58  K战神  阅读(1927)  评论(2编辑  收藏  举报