重构，是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。也可以理解为在保证功能不变的前提下，利用设计思想、原则、模式、编码规范等理论来优化代码，修改设计上的不足，提高代码质量。
保持代码质量处于一个可控状态，不至于腐化到无可救药的地步。也可以锻炼一个人的代码能力，并且是一件非常有成就感的事情。
重构大致可以分为大规模高层次的重构和小规模低层次的重构。大规模高层次的重构包括对代码分层、模块化、解耦、梳理类之间的交互关系、抽象复用组件等。小规模低层次的重构包括规范命名、注释、修正函数参数过多、消除超大类、提取重复代码等等编程细节问题。
重构，是一个持续的过程，是开发必不可少的部分，应该融入到日常开发中。
大规模高层次的重构难度比较大，需要组织、有计划地进行，分阶段小步快跑，时刻让代码处于一个可运行状态。小规模低层次重构，应该随时随地的去做。
单元测试是由开发者编写的一个类或者函数，用于测试自己编写的代码逻辑是否正确。
单元测试能够有效的发现代码中的bug和代码设计上的问题。是测试驱动开发可落地执行的改进方案。
单元测试应该覆盖各种输入、异常、边界情况，并将其翻译成代码。
单元测试本身就比较繁琐，技术挑战不大，且很多代码是和业务代码重叠，所以导致很多开发人员不愿意去写。另一方面是项目任务紧、导致单元测试半途而废。
解耦能够保证代码松耦合、高内聚，是控制代码质量的有效手段。使复杂的代码具有较好的可读性、可维护性。
将模块与模块、类与类之间的依赖关系画出来，根据依赖关系图的复杂性来判断是否需要解耦重构。
给代码解耦的方法有：封装与抽象、中间层、模块化、以及一些其他的设计思想与原则。
命名的关键是能准确达意。可以适当的选择短一些的命名方式。命名中也可以使用一些耳熟能详的缩写。
可以借助类的信息来简化属性、函数的命名。
不要使用生僻的、不好读的英文单词来命名，明敏概要符合项目的统一规范，不要用写反直觉的命名。
接口：前缀带“I”或者后面代“Impl”；抽象类：前缀带“Abstract”或不带前缀。
注释的目的就是让代码更容易看懂。注释要包含以下三个方面：做什么、为什么、做么做。或者包含“如何用”等信息。
注释并非越多越好，注释些的尽可能全面、详细即可。函数内部可以相对减少一些注释，来提高代码的整洁性。
函数的代码行数不要超过一屏幕。类的话，根据业务需求划分即可。
尽量不要超过IDE显示的宽度。但要保证代码的整洁。
对于比较长的函数，为了让逻辑更加清晰，可以在两个业务模块之间增加空行来进行分割。比如变量的定义和变量的赋值之间可以用空行进行分割。
缩进是为了保证代码的整洁，两格缩进可以节省空间。
大括号放在定义的后面，这种方式可以节省代码行数，使代码看起来更整洁。大括号另起一行的话，前后括号可以垂直对齐，代码块分割一目了然。
保证代码在团队、项目中的统一。
更小的单元块，是为了在代码阅读过程中，能够从整体往细节一步一步查看。让阅读代码的人能够屏蔽掉细节，从整体了解业务，
如果参数数量过多，可以将参数封装成对象。
尽量避免使用boolean来作为参数进行逻辑判断，尽量避免根据参数是否为null来控制逻辑。这种情况下建议拆成两个函数分别进行处理。
函数也要满足单一职责原则。
减少if-else、switch-case嵌套。可以通过去掉多余的if-else、使用continue、break、return等关键字、调整执行顺序、将嵌套逻辑封装成函数调用等。
减少魔法数字的使用，尽量使用常量定义。
增加代码可读性。
遵循统一的编码规范，通过Code Review来督促执行，提高代码质量。
