代码写得是真优雅呀！

工作多年后，越发觉得代码整洁真的是太紧张了！尤其是在团队开发中，写出优雅工整的代码，能让同事更乐于跟你相助。
下面，将通过定名、类、函数、测试这四个章节,使我们的代码变得整洁。

1.为什么要保持代码整洁?

不整洁的代码随着时间的增长而增长时,生产力会随之降低. 导致的结果就是:

• 代码不易扩展或扩展轻易引发其他题目
  
• 步伐崩溃
  
• 加班
  
• 增长公司成本(加人) 甚至可能造成公司倒闭 一图胜千言
  

1.1 以是从一开始就要保持整洁
以是在一开始就要写整洁的代码,假如有不整洁的代码就要及时的整改. 绝对不要有以后再改,以后再说的想法， 因为！

1. later equal never

复制代码

想想是不是这个道理,你有多少以后再说、以后再改的东西都抛诸脑后了.
假如是肯定要做的事情,那就趁早做!
1.2 怎样写出整洁的代码?

那么现在的题目就是,怎样的代码才算是整洁的代码呢:

• 可读性要高: 代码要像散文一样优雅易读,见码知意
  
• 拒绝重复代码
  
• 满足设计模式原则
  
  
  
  • 单一职责
    
  • 开闭原则
    
  • 里氏替换原则
    
  • 依赖倒转原则
    
  • 接口隔离原则
    
  • 迪米特法则
    
  • 合成复用法则
    
  
  

2.定名

好的定名可提高代码的可读性,让人见码知意, 降低明白成本,提高效率, 减少加班。
2.1 不好的定名方式

• 没有任何意义的定名方式
  

1. public interface Animal {
2.     void abc();
3. }

复制代码

现在我们有一个动物的接口, 里面有一个方法abc(),看了让人一头雾水, 调用这个方法的人也完全不知道这个方法是干什么的,因为他的定名毫无意义
有意义的定名方式:

1. public interface Animal {
2.     void cry();
3. }

复制代码

我们将方法名定名为cry(喊叫,呼唤),调用的人就知道这个方法的作用是什么了。
以是定名肯定要有意义且让人见码知意。

• 定名前后不一致 这种情况体现在明显是同一行为,但是却有不同的定名,前后不一致,让人造成混淆.
  

1. public interface StudentRepository extends JpaRepository<AlertAll, String> {
2.     Student findOneById(
3.             @Param("id") String id
4.     );
6.     List<Student> queryAllStudent(
7.     );
9. }

复制代码

上面两个方法都是查询 xxx, 但是定名一会叫 query 一会叫 find,这种情况应该加以规范,保持一致, 修改后:

1. public interface StudentRepository extends JpaRepository<AlertAll, String> {
2.     Student findOneById(
3.             @Param("id") String id
4.     );
6.     List<Student> findAll(
7.     );
9. }

复制代码

• 定名冗余 体现在定名有很多没必要的成分在里面, 而且这些"废话"并不能资助区分它们的区别, 例如在变量定名中添加了 Variable 这个词, 在表名中添加了 Table 这个词.以是定名中不要出现冗余的单词 , 而且提前约定好定名的规范.
  

1. // 获取单个对象的方法用get做前缀
2. getXxx();
3. //获取多个对象用list做前缀
4. listXxxx();

复制代码

3.类

整洁的类应满足一下内容:

• 单一职责
  
• 开闭原则
  
• 高内聚性
  

3.1单一职责

类应该短小,类或模块应有且只有一条加以修改的理由 , 假如一个类过于庞大的话,那么说明它承担的职责过多了。
优点:

• 降低类的复杂度
  
• 提高类的可读性
  
• 提高系统的可维护性
  
• 降低变更引起的风险
  

   怎样判定类是否足够短小?
  通过盘算类的职责来判定是否够短小,类的名称描述其全责, 假如无法为某个类命以准确的名称, 这个类大概就太长了, 类名越暗昧,可能拥有越多的职责.
职责过多的例子,可以看到以下类有两个职责:

1. public abstract class Sql {
2.     // 操作SQL的职责
3.     public abstract void insert();
6.     // 统计SQL操作的职责
7.     public abstract void countInsert();
9. }

复制代码

将统计的职责抽取到另一个类

1. public abstract class CountSql {
3.     public abstract void countInsert();
5. }

复制代码

3.2 开闭原则

开闭原则: 面向修改关闭, 面向扩展开放.
面向修改关闭意味着增长新的逻辑不会修改原有的代码,降低了出错的可能性.
面向扩展开放则是提高了代码的可扩展性,可很轻易的增长新的代码逻辑.
不满足开闭原则的例子:

1. public abstract class Sql {
2.     public abstract void insert();
3.     public abstract void update();
4.     public abstract void delete();
5. }

复制代码

假如我们现在要新增查询的操作,就必要修改Sql这个类,没有做到面向修改关闭
重构后:

1. public abstract class Sql {
2.     public abstract void generate();
5. }
7. public class CreateSql extends Sql {
9.     @java.lang.Override
10.     public void generate() {
11.         // 省略实现
12.     }
13. }
16. public class UpdateSql extends Sql {
18.     @Override
19.     public void generate() {
20.         // 省略实现
21.     }
22. }

复制代码

当我们要增长删除方法时可以很轻易的扩展.
使用大量的短小的类看似比使用少量庞大的类增长了工作量(增长了更多的类),但是真的是这样吗? 这里有一个很好的类比:
   你是想把工具归置到有很多抽屉、每个抽屉中装有定义和标记精良的组件的工具箱呢, 还是想要少数几个能任意把所有东西扔进去的抽屉?
  最终的结论:
   系统应该由很多短小的类而不是少量巨大的类组成,每个小类封装一个权责,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为.
  3.3 内聚

方法操作的变量越多,就越粘聚到类上. 假如一个类中的每个变量都被每个方法所使用, 则该类具有最大的内聚性. 我们应该将类的内聚性保持在较高的位置. 内聚性高意味着方法和变量相互依赖, 相互结合成一个逻辑整体.
   为什么要保持高内聚? 保持内聚性就会得到很多短小的类,就越满足单一职责.
    内聚性低怎么办? 假如类的内聚性就不够高,就将原有的类拆分为新的类和方法.
  

4.函数

要想让函数变得整洁,应保证:

• 只做一件事
  
• 好的定名
  
• 整洁的参数
  
• 注意返回内容
  

4.1 只做一件事

what? 函数的第一规则是短小 第二规则是更短小 短小到只做一件事情. (没错和类的原则很像)
why? 函数越短小,越能满足单一职责.
how? 以下是重构前的代码, 这个方法有三个职责,而且该方法很长到达了80+50+5 = 135行

1. public class PicService {
3.     public String upload(){
4.         // 校验图片的方法 伪代码80行
6.         // 压缩图片的方法 伪代码50行
8.         // 返回成功或失败标识 0,1 伪代码5行
9.         return "0";
10.     }
11. }

复制代码

原有的upload方法做了很多的事情, 重构后只做了一件事情: 把大一些的概念(换言之,函数的名称)拆分为另一抽象层上的一系列步调:

1.  public String upload(){
2.         // 校验图片的方法
3.         check();
4.         // 压缩图片的方法
5.         compress();
6.         // 返回成功或失败标识 0,1
7.         return "0";
8.     }

复制代码

而里面的每个方法,也都有着本身各自的职责(校验图片 、压缩图片 、返回结果).
4.2 函数定名

1. 函数名应见名知意

函数要有描述性的名称，不关键怕长名称.
不好的定名方式:

1. public String addCharacter(String originString, char ch);

复制代码

这个函数，一咋看，还不错，从函数字面意思看是给某个字符串添加一个字符。但是到底是在原有字符串首部添加，还是在原有字符串末了追加呢？亦或是在某个固定位置插入呢？从函数名字完全看不出来这个函数的真正意图，只能继承往下读这个函数的详细实现才知道。
而下面这几个名字就比上面要好得多：

1. // 追加到末尾
2. public String appendCharacter(String originString, char ch);   
4. // 插入指定位置
5. public String insertCharacter(String originString, char ch, int insertPosition);

复制代码

2. 函数应该无副作用

函数应该无副作用， 意思就是函数应该只做一件事，但是做这件事的时候做了另一件有副作用的事情.
例如: 校验密码时会初始化 session，导致会话丢失。假如无法移除这种副作用，应该在方法名中展示出来，避免用户误用 checkPasswordasswordAndInitializeSession, 从定名上就要体现副作用.
4.3 参数

1. 参数越少越好

参数越少，越轻易明白，参数高出三个可以将参数举行封装，要按参数的语义举行封装，不肯定封装成一个大而全的参数，可以封装为多个，原则是按语义增补; 示例:

1. public List<Student> findStudent(int age, String name, String country, int gender);
3. //封装参数
4. public List<Student> findStudent(Student student);

复制代码

2. 不要使用标识参数

标识参数是参数为 Boolean 类型, 用户通报 true or false . 不要使用标识参数因为这意味着你的函数违反了单一职责(true false 两套逻辑). 正确的做法是拆分为两个方法:

1. //标识参数方法
2. render(Boolean isSuite);
4. //重构为两个方法
5. reanderForSuite();
6. renderForSingleTest();

复制代码

3. 不要使用输出参数

什么是输出参数?
将变量作为参数传入方法,而且将变量输出, 这就是输出参数

1. public void findStudent(){
2. Student student = new Student();
3. doSomething(student);
4. return student;
5. }
7. int doSomething(Student student){
8. // 省略一些student逻辑
9. return student;
10. }

复制代码

  为什么不应该有输出参数?
  因为增长了明白成本在里面,我们必要查察 doSomething到底对 student 做了什么. student 是输入还是输出参数? 都不明确.
重构:

1. // 将doSomething()方法内聚到student对象本身
2. student.doSomething();

复制代码

4.4 返回值

1. 分离指令与讯问

示例代码:

1. Pulic Boolean addElement(Element element)

复制代码

指令为增长某个元素,询问是否成功
这样做的弊端是职责不光一，以是应该拆分为两个方法

1. public void addElement(Element element);
2. public Boolean isAdd(Element element);

复制代码

2. 使用非常替换返回错误码

直接抛出非常,而不是返回错误码举行判定, 可以使代码更简洁. 因为使用错误码有可能会举行多层嵌套片断 代码示例:

1. // 使用错误码导致多层嵌套...
2. public class DeviceController{
4.  public void sendShutDown(){
5.   DeviceHandle handle=getHandle(DEV1);
6.    //Check the state of the device 
7.   if (handle != DeviceHandle.INVALID){
8.    // Save the device status to the record field 
9.    retrieveDeviceRecord(handle);
10.    // If nat suspended,shut down
11.    if (record.getStatus()!=DEVICE_SUSPENDED){
12.      pauseDevice(handle);
13.      clearDeviceWorkQueue(handle);
14.      closeDevice(handle);
15.    }else{
16.     logger.log("Device suspended. Unable to shut down"); 
17.    }
18.   }else{
19.    logger.log("Invalid handle for: " +DEV1.tostring()); 
20.  }
21. } 

复制代码

重构后:

1. //  将代码拆分为一小段一小段, 降低复杂度,更加清晰
2. public class DeviceController{
4.  public void sendShutDowm(){ 
5.   try{
6.    tryToShutDown();
7.   } catch (DeviceShutDownError e){ 
8.    logger.log(e);
9.   }
11.  private void tryToShutDown() throws DeviceShutDownError{
12.    DeviceHandle handle =getHandle(DEV1);
13.    retrieveDeviceRecord(handle);
14.    pauseDevice(handle);
15.    clearDeviceWorkQueue(handle);
16.    closeDevice(handle);
17.  }
19.  private DeviceHandle getHandle(DeviceID id){
20.               // 省略业务逻辑
21.   throw new DeviceShutDownError("Invalid handle for:"+id.tostring()); 
22.  }
23. }

复制代码

4.5 怎样写出这样的函数?

没人能一开始就写出完美的代码, 先写出满足功能的代码,之后紧接着举行重构
为什么是紧接着? 因为 later equal never!
4.6 代码质量扫描工具

使用 SonarLint 可以资助我们发现代码的题目,而且还提供了相应的办理方案. 对于每一个题目，SonarLint 都给出了示例，另有相应的办理方案，教我们怎么修改，极大的方便了我们的开发
比如，对于日期类型尽量用 LocalDate、LocalTime、LocalDateTime，另有重复代码、埋伏的空指针非常、循环嵌套等等题目。
有了代码规范与质量检测工具以后，很多东西就可以量化了，比如 bug 率、代码重复率等.


5.测试

测试很紧张，可以资助我们验证写的代码是否没题目,同样的测试代码也应该保持整洁。
5.1 TDD

TDD 是测试驱动开发（Test-Driven Development），是敏捷开发中的一项核心实践和技能，也是一种设计方法论。

• 优点：在任意一个开发节点都可以拿出一个可以使用，含少量bug并具肯定功能和可以或许发布的产物。
  
• 缺点：增长代码量。测试代码是系统代码的两倍或更多，但是同时节省了调试步伐及挑错时间。
  

how?

• 在开发代码前先写测试
  
• 只可编写刚好无法通过的单位测试，不能编译也算不通过
  
• 开发代码不可高出测试
  

关于2的解释: 单测与生产代码同步举行，写到一个不可编译的单测就开始写生产代码，云云反复循环，单测就能包含到所有生产代码。
5.2 FIRST原则

FIRST 原则就是一个引导编写单位测试的原则

• fast 快速 单测实验应该快速的完成
  
• independent 独立 单测之间相互独立
  
• repeatable 可重复 单测不依赖于环境，到处可运行
  
• self validating 步伐可通过输出的Boolean自我验证，而不必要通过人工的方式验证（看日志输出、对比两个文件不同等）
  
• timely 及时 单测在生产代码之前编写
  

单位测试是代码测试中的底子测试，FIRST 是写好单位测试的紧张原则，它要求我们的单位测试快速，独立，可重复，自我校验，及时/完整。
5.3 测试代码模式

开发测试代码可以使用 given-when-then 模式

• given 制造模仿数据
  
• when 实验测试代码
  
• then 验证测试结果
  

代码示例

1. /**
2.   * If an item is loaded from the repository, the name of that item should 
3.   * be transformed into uppercase.
4.   */
5. @Test
6. public void shouldReturnItemNameInUpperCase() {
7.  
8.     // Given
9.     Item mockedItem = new Item("it1", "Item 1", "This is item 1", 2000, true);
10.     when(itemRepository.findById("it1")).thenReturn(mockedItem);
11.  
12.     // When
13.     String result = itemService.getItemNameUpperCase("it1");
14.  
15.     // Then
16.     verify(itemRepository, times(1)).findById("it1");
17.     assertThat(result, is("ITEM 1"));
18. }

复制代码

使用give-when-then 模式可提高测试代码的可读性.
5.4 自动天生单测

先容两款 IDEA 自动天生单测的插件

• Squaretest 插件（收费）
  
• TestMe 插件(免费)
  

参考资料：
书籍: <<代码整洁之道>>
https://www.cnblogs.com/sunny3158/p/16353643.html
https://blog.csdn.net/qq_42289636/article/details/108762981
最后说一句(求关注!别白嫖！)
假如这篇文章对您有所资助，大概有所启发的话，求一键三连：点赞、转发、在看。
关注公众号：woniuxgg，在公众号中回复：笔记  就可以获得蜗牛为你精心准备的java实战语雀笔记，回复面试、开发手册、有超赞的粉丝福利！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。