代码审查与重构的5个层次

   最近一直在从事一款iOS的app的开发工作。为了提高团队整体的代码质量，从项目开始我就一直担负着代码审查重构的工作。在这期间发现了很多问题，也吸取了很多教训。今天将自己的思路总结一下，整理出了代码审查重构由高到低的5个层次。

第一个层次：业务架构的审查重构

   这是最高层次的代码审查重构。其实，这个阶段的审查并未真正涉及到具体的代码实现，而是针对客户需求，对相应的业务逻辑的设计进行审查，目的在于使业务逻辑架构的设计与用户需求保持精确一致。这里审查所谓的业务架构可以从两个层次讨论：首先是审查复杂且完整的业务逻辑的架构，比如支付相关的业务逻辑架构，导航，map，语音相关的业务等等。这个层次的审查需要我们充分了解相关的业务知识，进而审查业务架构的合理性与准确性。以支付为例，我们需要熟悉支付方式以及支付的整个流程，另外还有其中涉及的一些关键问题。最终确保我们的业务逻辑的架构设计符合这一系列的需求。

   其次，审查简单的单个功能点的业务逻辑设计实现，例如用户的注册与登录功能。我们需要确保这些业务逻辑的设计完全符合UX的设计，并最终符合用户需求。

第二个层次：代码架构的审查重构

   这个层次的审查针对的是项目中采用的具体的架构模式，目的在于审查代码是否符合架构模式。在我们目前的项目中采用的是mvvm架构模式，因此在这个层次的代码审查的时候应注重审查代码是否遵循了mvvm的基本原则。

   View部分：其中包含了view组件以及ViewController主要的功能应在于处理界面的显示，而不应有任何的业务逻辑的处理；

   ViewModel部分：应主要负责业务逻辑的处理，并不涉及任何页面的展示逻辑。

   Model部分：应主要负责业务数据模型的建立，使用它可以根据业务逻辑建立相应的业务数据。

   另外涉及到各部分之间的交互通信，项目中我们采用了RxSwift，因此应遵循其相应的语法规则与使用习惯。

   最后涉及到项目中引入的依赖注入的框架SwInject，也要符合其使用规范，最大限度的消除依赖。

   总之，在这个层次的代码审查重构的时候，我们应始终把焦点关注在代码是否符合我们项目中所采用的架构模式。无论app开发还是web开发，其实都是一个道理。

第三个层次：设计模式的审查重构

   这个阶段主要针对的是面向对象开发中的类之间的组织结构以及类自身行为属性的设计，这可能就会涉及到一些设计模式的使用。通过使用设计模式，可以使我们的代码更加的可复用，可扩展以及可测试。这是我们这个阶段进行设计模式的审查重构的目的。然而设计模式的过度使用也会使代码陷入“万恶的深渊”，提前设计与设计过度同样不可取。

   因此设计模式的审查重构时应注重审查：

   （1）代码应尽量保持简单，只有在必要的时候才使用设计模式，避免过度设计与提前设计。

   （2）设计应遵循面向对象编程的SOLID原则。

   （3）使用规范化的设计模式的“术语”编写，如设计模式中类的命名等相关“术语”应标准化，规范化。

   （4）使用结构型设计模式进行类的组织结构设计。这其中包括：Composite, Decorator, Adapter, Bridge, Facade, Proxy, Flyweight。

   （5）使用行为型设计模式进行类方法的设计, 进行封装变化，对象做为参数的封装，对象间通信，类间解耦合。包括：Strategy, State, Template method, Visitor, Command, Memento, Observer, Mediator, Iterator, Interpreter, Chain of responsibility。

   （6）使用创建型设计模式进行类型的创建初始化。它包括：Factory method, Abstract factory, Builder, Prototype, singleton。

第四个层次：最优算法的审查重构

   这个层次的代码审查重构针对的是代码算法的使用，主要审查面向对象类中方法的算法设计实现。这里说的算法的使用并非一定要使用那些经典的算法，例如排序算法，查找算法等，而指的是使用合理的数据结构进行时间与空间最优化的代码编写，不分配不必要的空间，尽量设计时间复杂度更低的的代码段。总之，设计更为高效的代码段。

第五个层次：语言与代码规范的审查重构

   这是最后一个层次，也是最为细节性的层级：代码的编写。在这个层次上，代码审查以及重构时应注重语言的最佳实践与代码风格的规范。

   首先，语言最佳实践的审查与重构。

   代码编写首先应符合使用的编程语言的语法规范，除此之外，我们还应该努力践行编程语言的最佳实践，比如尽量使用语言已提供的库中的API，避免重复建造轮子。我们项目中采用的是swift语言，在涉及到集合类的遍历处理的时候，我们不应该自己编写for in loop来实现遍历的功能，而应使用集合类的从sequenceType中继承而来的foreach方法，通过闭包的方式讲要处理的行为变量传人，从而实现遍历处理的功能。

   其次，代码风格的规范的审查与重构。

   统一的代码风格规范是团队开发的重要要素之一。代码规范的统一有利于代码的阅读维护，有利于代码的“集体所有制”。试想，如果团队中每个人都使用自己的一套代码规范，那整体的代码风格就可谓“百花争放”，最后的结果就是代码越来越混乱，且难以阅读维护。我们项目中统一的代码风格概括来讲有如下几个方面：

   （1）命名：使用帕斯卡命名法命名类名，即名称中每个单词首字母大写，采用形容词+名词的形式；驼峰法命名函数与属性，即名称中除第一个单词首字母小写外，其他单词首字母均大写。函数命名采用动词+名词的组合形式。属性命名采用形容词+名词的形式。通过使用有意义的命名，使属性与函数通过名称可以自我表达，从而取代注释。

   （2）函数：保证每个函数的单一功能性，让每个函数只做一件事情。采用“To”方法编写函数，就是将函数分步编写，使每个步骤单独成为一个新的函数。函数参数个数应尽量减少，可以封装在一起的尽量封装起来。

   （3）避免重复：应避免代码的随处拷贝，拷贝是重复的根源之一。应将可复用的部分提取出来，供不同的使用者调用。

   （4）代码一致性：一致性可以使代码更整洁美观。项目中为了保持一致性，我们需要一些约定俗成的事情，例如命名规则，要不要使用宏定义等等。

   （5）去除魔幻数：不应在代码中硬编码一些数据，比如：expectedValue = actualValue*5 + 20，类似这种代码，没人能看明白代码中的5和20是神马意思。我们可以使用宏定义或者创建静态属性的方式实现，定义成为可被理解阅读的代码。

   （6）封装条件表达式中的条件判断：代码中的条件表达式中如果有很多的条件判断时，对于阅读代码的人来说，很难读懂到底为了判定什么东西设立的这些条件。将条件表达式中的条件判断封装成为一个单独的方法，并命名一个有意义的名称，可以极大的提高代码的可读性。

   （7）函数异常处理：保持代码的安全性，需要时刻注意异常的处理。异常处理分为两个部分，首先是空值的判定，避免程序因空值造成的crash。空值判定主要包括函数参数的空值判定以及内部局部变量的空值判定；其次是异常的处理，比如io异常等等。

   （8）单元测试：单元测试的重要性相信大家都应该清楚，只是鉴于开发进度压力，往往被忽视。对于小型并不复杂的项目而言，可能单元测试的作用没有完全体现出来，但是对于复杂度很高，团队规模较大的项目而言，单元测试就无比重要了。我目前所做的项目，复杂度非常高，团队规模也很大，并且需要与欧美团队协同开发，因此保证单元测试的代码覆盖度非常重要。因此，应保证每段代码都应被单元测试覆盖。

   （9）多线程并发处理。开发中会经常涉及到多线程的问题，因此多线程的并发处理需要高度重视，很多问题就是由于多线程并发造成。