病来如山倒，继女朋友嫌我代码烂分后手，就生病了，高烧了一个周末，外加上需求压身，中间接近2个周没有提升自我了
“重构”对于我来说只听过，没做过，作为一个刚刚入职的小白来说，写完需求代码都是一个挑战，更别提去优化代码了，我放心，领导也不放心我。哈哈哈哈哈哈。
在进入新的项目时，新的项目进行了一次基础的代码重构，但是抽调了3个高级研发，而我则是继续负责基本需求开发，重构跟代码review一样，需要发现问题，才能指出问题，改正问题。所以说需要了解项目，了解项目的痛点，才能去改正它。那到底是什么原因导致了重构，什么原因导致了项目需要重构呢？
1. 为什么需要重构呢？
项目老化：
从老的项目成员那里听到的重构的原因无非就是项目存在的问题，架构不合理，代码无法复用，写个功能只能进一步破坏现在的代码结构。代码不停地在堆砌。如果没有人为代码的质量负责任，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本。
技术迭代
代码重构也是对程序员的查漏补缺行为，比如刚刚开始写代码我只会用成员变量作为标志位，后面使用回调，在会后面使用Inten，使用viewmodel等来进行通讯，来优化代码习惯。对于设计模式的使用也是如此。
2.重构主要是做什么呢？
重构就是把代码重新写一遍吗？并不是的！重构分为大重构和小重构。 大重构分为：系统，模块，代码结构，类与类之间的关系，手段有：分层，模块化，解耦，抽象等等。 小重构分为：类，函数，变量等代码级别的重构，比如函数名，变量名等等，更类似于平时的代码Review
那我怎么判断是要大重构和小重构呢？如果我知道重构我肯定早就重构了，最可怕的是我不知道自己不知道。这样问题就一直存在。 日常开发中如果一直写闭环代码，那么代码就会一直堆砌，有问题也很难发生，避免发生大重构的方法就是经常进行小重构，避免进行小重构的方法就是写出尽量好的代码。我在重构的项目遇到的最多的，就是代码没有解耦，调用一个公共方法，不是在底层模块，那我为了调用这个方法，要么是把代码复制一份，在我的模块里，要么就是我的代码，转移模块，使我能够调用这个方法。不管怎么样，都是将代码的耦合性变严重，代码复用性降低。
3.怎么样降低耦合性呢？
3.1. 封装与抽象 封装和抽象可以有效地隐藏实现的复杂性，隔离实现的易变性，给依赖的模块提供稳定且易用的抽象接口。
3.2. 中间层(接口)
引入中间层能简化模块或类之间的依赖关系
3.3模块化 模块化就是一些重复的轮子，类似于密码校验和安全，所有的业务可以共用一个，隐私弹窗模块的UI也可以共用。减少不必要的开发和维护。
最重要的是像目前学习的设计模式，都是为了解决这个问题。基于接口而非实现编程、单一职责、依赖注入、多用组合少用继承等，都有助于减少依赖，减低耦合。
