设计模式——规范和编码

1、重构的目的:为什么要重构（why）？

重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。
为项目而言，重构可以保持代码质量持续处于一个可控状态。不至于腐化到无可救药的地步，对于个人而言，重构非常锻炼一个人的代码能力，并且是一件非常有成就感的事情。他是我们学习的经典设计思路，原则，模式，编程规范等理论知识的练兵场。

2、重构的对象:重构什么（what）？

按照重构的规模可分为大规模高层次的重构和小规模低层次的重构。
大规模高层次重构，包括对代码分层、模块化、解耦，梳理类之间的交互关系、抽象复用组件等，这部分利用的更多的比较抽象、比较顶层的设计思想、原则、模式。
小规模低层次的重构包括规范命名、注释、修正函数参数过多、消除超大类、提取重要代码等等编程细节问题，主要是针对类，函数级别的重构。
小规模低层次的重构更多的是利用编码规范这一理论知识。

3、重构的时机:什么时候重构（when)？

建立持续重构意识，把重构作为开发必不可少的部分，融入到日常开发中，而不是等到代码出现很大问题的时候，再大刀阔斧的重构。

4、重构的方法:如何重构（how）?

大规模高层次的重构难度比较大，需要组织有计划的进行分阶段的小步快跑，时刻让代码处于一个可运行状态。而小规模低层次，随时随地都可以重构。

5、什么是单元测试？

单元测试是代码层面的测试油研发自己来编写，用于测试自己的代码的逻辑的正确性，单元测试顾名思义是测试一个单元，有别于集成测试。这个单元一般是类或函数，而不是模块或者系统。

6、为什么要单元测试？

写单元测试的过程本身就是码code review和重构的过程，能有效地发现代码中的bug和代码设计上的问题，除此之外，单元测试是对集成测试的有力补充，还能帮助我们快速熟悉代码，是TDD可落地执行的改进方案。

7、如和编写单元测试？

针对代码设计各种测试用例，以覆盖各种输入异常边界情况，并将其翻译成代码，可以利用一些测试框架来简化单元测试的编写。
①尽量繁琐，但不耗时。
②放低代码质量要求。
③覆盖率作为衡量单元测试质量唯一标准是不合理的。
④测试不要依赖被测代码的具体实现逻辑。
⑤单元测试框架无法测试，多半是因为代码的可测性不好。

8、单元测试为何难落地执行？

单元测试本身比较繁琐，技术挑战不大。
研发比较偏向快糙猛，同意应开发进度井导致单元测试的执行虎头虎脑。

9、什么是代码的可测试性？

所谓代码的可测试性就是针对代码的编写，单元测试的难易程度，对于一段代码如果很难为其编写单元测试或者单元测试，写起来很费劲，需依靠单元测试框架中很多高级的特性。那往往就意味着代码设计的不够合理，代码的可测试性不好。

10、编写可测试性代码的有效手段。

依赖注入是编写可测试性代码的最有效手段，通过依赖注入，在编写单元测试的时候可以通过mock的方式依赖外部服务。

• 常见的测试不友好的代码。
  ①代码中包含未决行为逻辑。
  ②滥用可变全局变量
  ③滥用静态方法
  ④使用复杂的继承关系。
  ⑤高度耦合的代码

11、解耦为何如何重要？

过于复杂的代码往往在可读性，可维护性都不友好。偶保证代码，松藕和高内聚是控制代码复杂度的有效手段，代码高内聚松耦合也就意味着代码结构清晰，分层模块化合理，依赖关系简单，模块和类之间的耦合小，那代码整体的质量就不会差。

12、代码是否需要解耦？

间接的衡量标准很多，看修改代码是否签一发而动全身，直接的衡量标准是把模块与模块，类与类之间的依赖关系画出来，根据依赖关系图的复杂性来判断是否需要结合重构。

13、如何结合代码 “解耦”？

给代码的方法有封装与抽象，中间层，模块化以及一些其他的设计思想与原则，比如单一职责原则，基于接口而非实现编程。依赖注入，多用组合少用继承，迪米特法则等。

14、编码规范

①命名:命名关键是能够准确达意，可读，可搜索，统一规范
②注释:让代码更容易老董“做什么、为什么、怎么做”。
③类函数:代码行数不超过50行，一行的长度不超过ide显示的宽度，一行代码限制100个字符。
④善用空行分割单元块

15、编码技巧

将复杂的逻辑提炼成函数和类。
通过拆分多个函数或将参数封装对象的方式来处理参数过多的情况。
函数中不要使用参数来做代码执行逻辑的控制。
函数设计要职责单一。
移除过深的嵌套层次，去掉多余的if else,使用continue等来提前退出嵌套。