写在前面的话
话说我为什么突然想写这篇文章呢？是有前奏的，在一次项目的重构的过程中，让我发现，代码的质量无法保证，后期的bug各种花样，测试精疲力竭，抱怨开发，开发抱怨项目负责人。来回的踢皮球！有人说，框架构建的时候，不会控制代码规范吗？严格控制编码校验吗？比如前端js,html，css等代码检查工具，通过这些不就控制啦吗？话虽如此，但是，这些工具也不是万能呢？前期开发，是团队的配合，每个人都好自己的特色以及自己的代码风格，这样又去怎么去控制呢？近期的项目重构一直到测试，暴露各种问题！代码各种不严谨等等，这样让我想到了软件工程的一种CodeReview，如果在给测试之前进行一次CodeReview,避免太多问题，控制代码质量，又减少bug。下面让我进入CodeReview，本人是小白，写的不好，心里吐槽下把！
CodeReview是什么？
CodeReview的目的是一种通过复查代码提高代码质量的过程，尽早发现潜在缺陷与BUG，降低修复成本，同时促进团队内部知识共享，帮助更多人更好地理解系统,也已经成为软件工程中一个不可缺少的环节。
Code Review简介
我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客：
- Code Review的目的 :凡事知其然还要知其所以然,我们首先需要知道什么是Code Review和我们使用它的目的是什么。a).Code Review是一种用来确认方案设计和代码实现的质量保证机制,通过这个机制我们可以对代码、测试过程和注释进行检查。b).Code Review主要用来在软件工程过程中改进代码质量,通过Code Review可以达到如下目的:在项目早期就能够发现代码中的BUG ;
帮助初级开发人员学习高级开发人员的经验,达到知识共享 ;避免开发人员犯一些很常见,很普通的错误 ;保证项目组人员的良好沟通 ;项目或产品的代码更容易维护. - Code Review的前提: 需要了解Code Review的概念和Code Review将做什么? 如果连这些不知道，那么对项目成败和代码质量的重要程度,可能就会是应付了事。如果你明白了这些，那么可以进行就显得有意义。a).是否已经正确的build(build的目的使得代码已经不存在基本语法错误,避免浪费时间，如果连编译不通过，那有必要code review 啦)。b).代码执行时功能是否正确 (开发人员或质量人员负责该代码的功能的正确性，如果连正确性不能保证，何来code review) 。c).Review人员是否理解了代码 (做复查的人员需要对该代码有一个基本的了解,其功能是什么,是拿一方面的代码,涉及到数据库或是通讯,这样才能采取针对性的检查 )。d).开发人员是否对代码做了单元测试(如果连功能模块到没有测试通过，就去code review，那么浪费时间去测试的bug，没有心情看代码质量啦，劳心劳力，还没有结果。)
- 那Code Review到底需要做什么 ：a).完整性检查(Completeness)。b). 一致性检查(Consistency)。c).正确性检查(Correctness)。d).可修改性检查(Modifiability)。f).可预测性检查(Predictability)。g).健壮性检查(Robustness)。h).结构性检查(Structuredness)。i).可追溯性检查(Traceability)。j).可理解性检查(Understandability)。k).可验证性检查(Verifiability)。
关于CodeReview的一些原则
架构/设计/常规
1.单一职责原则
- 一个类只能干一个事情，一个方法最好也只干一件事情。比较常见的违背是一个类既干UI的事情，又干逻辑的事情，这个在低质量的客户端代码里很常见。
2.行为是否统一
- 缓存是否统一。
- 错误处理是否统一。
- 错误提示是否统一。
- 弹出框是否统一。
- ……。
3.代码污染
- 代码有没有对其他模块强耦合。
4.重复代码
- 应该抽取。
5.开闭原则
6.面向接口编程
7.健壮性
- 是否考虑线程安全。
- 数据访问是否一致性。
- 边界处理是否完整。
- 逻辑是否健壮。
- 是否有内存泄漏。
- 有没有循环依赖。
- 有没有野指针。
- 是否检查了数组的“越界“错误。
- ……
8.错误处理
9.改动是不是对代码的提升
- 新的改动是打补丁，让代码质量继续恶化，还是对代码质量做了修复。
10.效率/性能
- 关键算法的时间复杂度多少？有没有可能有潜在的性能瓶颈。
- 客户端程序对频繁消息和较大数据等耗时操作是否处理得当。
代码风格
1.可读性
- 衡量可读性的可以有很好实践的标准，就是 Reviewer 能否非常容易的理解这个代码。如果不是，那意味着代码的可读性要进行改进
2.命名
- 命名对可读性非常重要
- 是否跟系统属性命名造成冲突
- 英语用词尽量准确一点，必要时可以查字典
3.函数长度/类长度
- 函数太长的不好阅读
- 类太长了，检查是否违反的 单一职责 原则
4.注释
- 恰到好处的注释,不是注释越多越好
5.参数个数
- 不要太多，一般不要超过 3 个