代码走查做为一种流程形式,起初你们的参与热情很是高涨。git
由于,本身能够学习到别人一些巧妙的思想,本身的代码和习惯都暴漏出来。编程
这个过程当中不断地吸取和改正。函数
可是。。。。。。gitlab
咱们一开始组织的代码走查是一个很重的会议形式。性能
参加的人有写这段代码的人(小菜)、比较有经验的开发(大佬)学习
若是为了再隆重一些,请一些领导也参与其中。优化
可是。。。。。。编码
我上面提过了,会议很重,协调时间这个事情就是一个很费时间的事情。3d
还有就是,你们巴不得对每一句代码都发表本身的意见,每每很是的细枝末节。code
致使会议时间常常在2小时以上,3小时时间就通常不得不中止。
你们都很累,再就是效果如何呢?
若是小菜自律性不够,甚至没人进行监督,此次的审查的代码不是都会修改。
由于有一些确实太过于鸡蛋挑骨头,根本改不动。
不知不觉中,这种方式慢慢褪去。代码走查成为了一个优先级、频次都不高的活动。
有不少缘由,上面说的形式过重是一个,还有就是你们都很忙了,没有进行持续跟进致使效果不佳。
可是。。。。。。
也都知道代码走查对一些新人来讲,成长史毋庸置疑的。收获也是毋庸置疑的。
慢慢你们也都放下了。只是每次项目迭代中做为一个硬性要求执行一次罢了。
咱们小组里面只有我还有一个刚毕业一年多的女生。
在咱们组内的一个项目中,我老是以任务重为由,没有进行代码走查。这个持续了很长时间。
一个字 —— 懒
在处理客户反馈的问题时候,我忽然发现,她写的代码确实出现了比较粗心的失误。
我心一想,长达3个月的时间都没有对她的代码进行任何关注。
于她于我于项目,都是极其很差的。我这块作得太自私了。
因而我在gitlab上加上了 【合并请求权限】,逼迫她去仔细思考本身的代码,逼迫我必须去看她写得每一行代码。
其中有规范、命名、优化、风格、bug
......
是的,这些时间付出是有价值的。是潜移默化的。不少时候咱们为了Review一个问题点,讨论20分钟。
一方面深刻挖掘她当时的思路:是知识面问题?仍是偷懒?仍是知道这样后期再优化?
另外一方面,也把个人想法和思路进行交流。有几回是我认知就是错误的,经过讨论发现了更好的实践。
其实代码Review真的是一种很是好的实践,咱们不能以咱们过来的人的眼光看待新人。
他们有他们的优势,固然他们也极可能会犯错。咱们使用一点时间,就能把这个问题给找到,对咱们对他们都是一件好事。
再加上,代码review也是把团队和部门甚至公司的制度流程以及规范进行一种培训。只是换了一种方式。
至少我以为我是有收获的,经过几回交流,成员也说明本身确实有收获。
刚刚进入社会,刚刚入行的软件工程师们,不都是自律能力很是强的。都有惰性。
经过这样的形式,让她感知提高,增长自信心,因此后期不少时候她都会把一些好的想法,反过来给反馈给我,我以为确实是。因而我就偷偷回去改个人代码。
这也是一种沟通渠道,我以为不少时候软件就是在解决沟通问题。如何让沟通作得有价值,有效率。
有了收获,我依然想进行再一步的精进。找到一本书,能彻底确定咱们如今作的事情是一种有价值事情的书籍。
《代码整洁之道》 《重构2》
规定时间里阅读完一章,找出系统中很差的,并按其思想进行修改。或者系统中已经这样作的,找出来分析一下。时间不用很长。
从命名规范、函数分解、同一抽象层次分层、硬编码、效率、类、模块、甚至文件夹构成
为何要作这些?
首先,咱们先不去追踪复杂的效率问题,先解决简单功能实现,后期有人能看懂的问题。
这些实践容易,而且效果明显。有效果,咱们就喜欢更深层次提高,再深刻提高,就会天然而然晋升到了性能层面。
如今我以为我和成员的一些讨论都在讨论执行效率。由于代码的命名、分层已经潜移默化养成了习惯。
有了成就感,就有了动力,有了动力,再去研究就会更加主动一些。
我也所以偶尔再总结一下,确实好的代码,使人心旷神怡,赏心悦目。更有读下去的冲动,甚至更有模范的冲动。
K.I.S.S 原则、单一职责、多用组合少用继承、最少知道原则等
不少时候,功能很简单,咱们却写得天花乱坠。
我幻想了一下,若是咱们的客户他喜欢编程,非要看源代码实现呢?若是他看到源码实现如此简单优美,心中如何感慨?
有时,我也时不时小结一下。
新人须要咱们的指导,才能避免一些弯路; 咱们也须要不断回炉锻造; 对代码多一些敬畏和欣赏~