可维护软件10个原则
1.编写短小的代码单元
短小的代码单元易于理解、测试以及重用
拥有单一职责的代码单元会尝试做多件事情，也会拥有多项职责。由于单一职责的代码只实现了一个独立的任务，所以会更加容易测试和分析、重用。
实现方式：将职责的不同的代码块提取成单独的方法；
- 不要牺牲可维护性来优化性能，所有的性能优化需要使用可靠的性能测试来证明，并且需要证明性能优化措施真的有效果；
- 统一团队中的格式化约定，保持编写短小的代码单元并遵守这些约定；
- 当似乎可以重构，但是并没有什么实际意义的时候，需要重新思考整个系统的架构；
2.编写简单的单元代码
分支点越少，代码单元越容易被修改和测试；
代码总会从某一点开始变得异常复杂，以至于修改代码变成了一件高风险并且耗时的任务。
解决方法：
- 如果嵌套的if-else 是几乎不想关的代码块——提取方法；
- 使用多态来代替条件判断（可能导致接口泛滥，需要在可扩展性和简洁性之间做出选择）；
- 使用谓语句代替嵌套的条件语句：判断条件是否可以替代为一个返回Boolean的方法，return语句是一个方法等；
- 解决复杂领域业务问题的唯一途径，就是通过简单的代码来一直保持对它们的控制；
将一个负责方法拆分成几个独立的负责度并不会降低整体的Macabe复杂度，但会更容易理解
3.尽可能消除重复代码
解决方法：
- 提取方法
- 提取父类重构
4.保持代码单元的接口简单
应该将四处分散的数据封装到一个专门的对象中——Martin Flower
方法参数不能超过4个，超过4个需要将多个参数提取成对象，较少的参数可以让代码单元更加容易理解和重用
5.分离模块之间的关注点
在一个复杂并且紧耦合的系统中事故无可避免；
典型举例：一个功能大而全的类，代码中随处都存在对该类的调用，随着该类的继续增长，代码逐渐变得难以理解和维护。修改的时候畏手畏脚；
耦合是类层面的问题，对一个紧耦合类调用的次数越多，这个类的体积应该越小；
解决方法：
- 根据不同关注点拆分类：当一个类在承担超过一个职责的时候，对类进行拆分；
6.架构组件松耦合
高内聚：独立的组件可以单独进行维护；
组件之间应该是松耦合的，清晰地被隔离开，只有几个很少的接入点，并且互相共享有限的信息。
这样方法的实现细节可以被隐藏起来，从而使得系统更加的模块化；
- 多扇入，少扇出
7.保持架构组件之间的平衡
构建封装边界是设计软件架构的重要技能；
平衡的组件可以帮助定位代码，并且允许独立对组件进行维护；
平衡：指的是各个组件体积大小几乎一致，
好处：它让查找和分析代码变得更加容易，隔离了维护所带来的影响，并且分离了维护职责；
8.保持小规模代码库
代码的复杂度会会持续的增加，直到它超过维护人员的能力；
拥有小型的代码，项目和团队是成功的一个因素；
大型项目的弊端：
项目体积和项目风险之间有强烈的关联关系，一个大型项目会导致大型团队、复杂的设计以及长时间的项目周期；
大型项目在相关利益人和团队成员之间出现了更加复杂的沟通和写作，很难看清软件设计的整体情况，并且在项目过程中会出现大量的需求变更。这些都增加了质量下降、项目延期以及失败的可能性。
解决方法：
1.控制需求蔓延，去除对业务或者用户没有增加相应价值，反而增加了系统复杂度的功能；
2.功能标准化：程序的行为和交互方面保持一致。第一：避免多个地方实现基本相同、但又略有区别的功能；
第二：功能标准化有利于重用已有的代码；
3.重用代码，重构已有代码
4.使用第三方类库
9.自动化开发部署和测试
想要保持代码简洁，请先保证测试进度条是绿色的。——JUnit格言
- 自动化测试让测试可以重复，比手动测试节约很多时间
- 自动化测试会让开发更有效率
- 自动化测试让代码行为可预测
- 测试是被测试代码的一种说明文档
- 编写测试能让你编写更好的代码
10.编写简洁的代码
编写简洁的代码是专业开发人员的职责所在；
- 不要编写单元级别的代码坏味道
- 不要编写不好的注释
- 不要注释代码
- 不要保留废弃代码
- 不要使用过长的标识符名称
- 不要使用魔术变量
- 不要使用未正确处理的异常
将原则变为实践！
低层级（代码单元）原则要优先于高层级（组件）原则！（优先把低层次代码重构好）
对每次提交负责，保证每次提交的代码都是符合规范的