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