代码重构［iOS开发］

最近接手一个做了一年的老项目，拿到代码后仔细一看，发现存在比较多的问题：

1.没有使用svn、或 git 进行管理，所有更改都在本project上，其中问题显而易见，需求在不断添加或者修改的时候，很多都会被悄无声息的被砍掉，没有分支、版本的概念。

2.使用到了诸多优秀的第三方库资源，但是没有使用CocoaPods进行管理，这就存在一个第三方库资源升级、再配置的问题；

3.业务与UI混杂，项目在设计的初期以及开发的过程中，没有进行合理的规划统筹，每个viewController中塞入其需要实现的业务，导致MVC中C一端极度庞大，随便都是上千行代码，维护代价太高；

4.随便使用notification，倒不是说notification机制不好，用的恰当，事半功倍，但是当我打开主界面看到viewDidLoad中注册了多达二十多个notification时，实在无法直视，想要骂娘；

5.却少封装与模块化，正如第3点中提到，业务跟随页面走，可能是相同的业务员，在不同的页面中却多次出现，繁琐，升级修改也很麻烦。

6.函数命名不明晰，很多业务处理方法，用到一些诸如nextXXX、doXXX、finishXXX的命名。词不达意，不深入函数内部看具体操作，很难看懂这一步是要做什么。

7.却少文档和注释，由于第6点原因，一些页面、函数不去看内部，无法知晓是干嘛用的，还没有必要的注释和说明。

基于以上发现的问题，意识到在一个项目的设计、开发阶段 整体的架构和架构的思想的重要性。没有好的架构，只跟着需求走，东边填一块，西边加一笔。等到项目比较复杂时，新的需求添加很麻烦，老得功能升级修改更是复杂。

接手了这个项目后，也开始思考如何在一个项目的结构的设计，这个虽然看过了一些相关的知识、也看多一些优秀的第三方库文件的结构，但是如何在自己项目开发中贯彻这些优秀的方法和思想才更重要。

一、一些基本思想

1.工作分块细化：无论是怎样复杂的业务流程，对其进行尽可能的分割细化，细化的过程也是对业务的每一步的理解，是对一个业务流程的量化，通过对业务的分块细化，也能分析出一个业务工作量有多大。具体到每一个函数只做一件事情，贯彻 Do One Thing Only 的思想

流水线的工作模式是现代工业崛起的核心，而此工作模式也是基础对工作的具体化、分步。同时对工作的细化分块也可以对应到项目的WBS中，管理起来也变得明晰。

2.小功能注意封装，大功能注意模块化：基于对工作进行了合理的分块和细化后，要对业务进行合理的封装和模块化，降低功能模块之间的耦合，可以实现对单个业务流程、功能点的测试。贯彻 高聚合、低耦合的思想。

电脑在流水线的组装，有了模块化的主板、机箱、外设后，组装也就变得简单，可以进行单元化的测试和升级。

3.项目文件结构分层要明晰：还是分类模块化的思想，应用在项目文件的管理中，根据项目具体情况或按照功能、或按照页面进行分层管理，不要使一个文件变得过于庞大，贯彻 大项目小文件 的思想。

记得以前看UNIX设计思想有提到 大项目小文件 这个思想，越是庞大的项目功能，其中的文件越是要具体和足够细化。

4.命名可读化：对于文件或者函数的命名最好能够达到“看其名知其意“的效果，而不用进入到文件或者函数中去看处理逻辑。除此之外也要添加必要恰当的注释。保证模块化的功能的使用顺畅。

---

二、实际工作

基于现在能够理解和用的思想的指导下，对该项目进行了重构工作，前后耗时三周时间，今天算是完成了第一阶段的重构。

1、结合项目设计文档对原来项目进行重新拆分，业务流程进行独立化，对业务和UI进行分离抽象。

2、使用cocoaPods、git管理项目，记录工作内容，也是纪录自己学习的过程。

3、业务功能分块细化、模块化业务，对文件进行拆分、重新命名，提高代码利用率。

4、废弃大量使用notification的逻辑，改用block、delegate等模式，使项目更加明晰、便于以后的升级。

5、建立项目的文件系统，对模块化的业务流程生成对应的逻辑文档。

---

三、对以后工作的指导意义

以后新开展一个项目时，要合理的设计、运用好项目的命名、架构、文件管理结构、文档4大系统。

在项目开发过程中，要不断的停下来对过去的工作进行思考，新加一个功能的时候先思考，如何更好的接入到已有的逻辑中。螺旋式的工作进度中，让自己对项目的管理的思想和方法更加成熟。