代码整洁—代码维护

代码维护的几点

相信读者经常会遇到各种不满意的代码，既然遇到了，你是袖手旁观，还是动手修改呢？原作者认为修改烂代码应该有以下几个分类，在此总结自己的学习笔记，以警戒自己日后的代码，尽量写出优质代码。

随时的进行模块内部的重构

我想作者的意思是将一个类里面的重复使用的代码，抽离出成为方法，这里我只是贴出作者的例子，以便自己随时回来观看

可以看出作者运用了as的快捷键，将一些变量、逻辑抽离出为能单独调用的方法~

模块级别的重构

强调了在涉及模块之间的重构，要尽量一次只做一次的重构，不要操之过急，避免因为改动过多，而变的事倍功半，因为有时候模块间的耦合度比较高，难免会出现隐藏的小bug，稍不留神，容易考虑不周吧。

• 删除没有用到的代码，避免后来的开发人员误解
• 从业务层面，去剥离方法，进行模块分类
• 从功能层面，抽离出来，使其在改动上不会互相影响
• 修改方法的逻辑
  这里作者强调了单元测试的重要性，但是本人所在的公司，没有这个观念，自己也不太会单元测试，只是会简单的测试而已，所以我这里引用原作者的观念吧，别说我抄袭，我后面会贴上原帖的地址。
  

为什么要创建单元测试？

一方面，这类重构因为涉及到具体代码逻辑的修改，靠集成测试很难覆盖所有情况，而单元测试可以验证修改的正确性。

更重要的意义在于，写不出单元测试的代码往往意味着糟糕的设计：模块依赖太多或者一个函数的职责太重，想象一下，想要执行一个函数却要模拟十几个输入对象，每个对象还要模拟自己依赖的对象……如果一个模块无法被单独测试，那么从设计的角度来考虑，无疑是不合格的。

还需要啰嗦一下，这里说的单元测试只对一个模块进行测试，依赖多个模块共同完成的测试并不包含在内-例如在内存里模拟了一个数据库，并在上层代码中测试业务逻辑-这类测试并不能改善你的设计。

工程级别的重构

这是影响最大，级别最高的重构吧，一般如果在此阶段的重构的话，最好就是能放下手头的工作，停下来专心做重构啦~

• 大概就说将公用代码提取出来作为公用引用库，放到android里面来说，应该就是uitls库，ui库，httpuitls库等
• 业务拆分，应该是android里面的对不同逻辑的模块，进行分类封装
• 养成良好的代码习惯，如果你不是处女座，看到自己不知不觉地写了上千行的代码，那你就要好好停下来思考，是不是自己哪里可以重构一下拉

作者的一些重构tips

• 如果某个模块几乎不改动，或者没有新的需求的，就没有重构的必要性
• 重构相对写代码更难些，还得多练，嗯，我自己也是，哈哈
• 重构时间不定，有长有短，也要看公司的容忍程度，像我公司就没有时间给你重构
• 作者再三提示：删除无用代码是提高代码维护性的最有效方式！！！
• 单元测试

作者的一次提升代码效率的经验

主要是讲述作者优化一个项目的经历，很厉害，这里就不多说，自行看原文

此为我参考以下文章的总结，如要仔细学习，还请看原创的文章：
关于烂代码的那些事（下）