2. 函数应该无副作用
函数应该无副作用， 意思就是函数应该只做一件事，但是做这件事的时候做了另一件有副作用的事情.
例如: 校验密码时会初始化 session，导致会话丢失。如果无法移除这种副作用，应该在方法名中展示出来，避免用户误用 checkPasswordasswordAndInitializeSession, 从命名上就要体现副作用.
4.3 参数
1. 参数越少越好
参数越少，越容易理解，参数超过三个可以将参数进行封装，要按参数的语义进行封装，不一定封装成一个大而全的参数，可以封装为多个，原则是按语义补充; 示例:
public List<Student> findStudent(int age, String name, String country, int gender); //封装参数 public List<Student> findStudent(Student student);
2. 不要使用标识参数
标识参数是参数为 Boolean 类型, 用户传递 true or false . 不要使用标识参数因为这意味着你的函数违背了单一职责(true false 两套逻辑). 正确的做法是拆分为两个方法:
//标识参数方法 render(Boolean isSuite); //重构为两个方法 reanderForSuite(); renderForSingleTest();
3. 不要使用输出参数
什么是输出参数?
将变量作为参数传入方法,并且将变量输出, 这就是输出参数
public void findStudent(){ Student student = new Student(); doSomething(student); return student; } int doSomething(Student student){ // 省略一些student逻辑 return student; }
为什么不应该有输出参数?
因为增加了理解成本在里面,我们需要查看 doSomething到底对 student 做了什么. student 是输入还是输出参数? 都不明确.
重构:
// 将doSomething()方法内聚到student对象本身 student.doSomething();
4.4 返回值
1. 分离指令与讯问
示例代码:
Pulic Boolean addElement(Element element)
指令为增加某个元素,询问是否成功,
这样做的坏处是职责不单一，所以应该拆分为两个方法
public void addElement(Element element); public Boolean isAdd(Element element);
2. 使用异常替代返回错误码
直接抛出异常,而不是返回错误码进行判断, 可以使代码更简洁. 因为使用错误码有可能会进行多层嵌套片段 代码示例:
// 使用错误码导致多层嵌套... public class DeviceController{ public void sendShutDown(){ DeviceHandle handle=getHandle(DEV1); //Check the state of the device if (handle != DeviceHandle.INVALID){ // Save the device status to the record field retrieveDeviceRecord(handle); // If nat suspended,shut down if (record.getStatus()!=DEVICE_SUSPENDED){ pauseDevice(handle); clearDeviceWorkQueue(handle); closeDevice(handle); }else{ logger.log("Device suspended. Unable to shut down"); } }else{ logger.log("Invalid handle for: " +DEV1.tostring()); } }
重构后:
// 将代码拆分为一小段一小段, 降低复杂度,更加清晰 public class DeviceController{ public void sendShutDowm(){ try{ tryToShutDown(); } catch (DeviceShutDownError e){ logger.log(e); } private void tryToShutDown() throws DeviceShutDownError{ DeviceHandle handle =getHandle(DEV1); retrieveDeviceRecord(handle); pauseDevice(handle); clearDeviceWorkQueue(handle); closeDevice(handle); } private DeviceHandle getHandle(DeviceID id){ // 省略业务逻辑 throw new DeviceShutDownError("Invalid handle for:"+id.tostring()); } }
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 验证测试结果
代码示例
/** * If an item is loaded from the repository, the name of that item should * be transformed into uppercase. */ @Test public void shouldReturnItemNameInUpperCase() { // Given Item mockedItem = new Item("it1", "Item 1", "This is item 1", 2000, true); when(itemRepository.findById("it1")).thenReturn(mockedItem); // When String result = itemService.getItemNameUpperCase("it1"); // Then verify(itemRepository, times(1)).findById("it1"); assertThat(result, is("ITEM 1")); }
使用give-when-then 模式可提高测试代码的可读性.
5.4 自动生成单测
介绍两款 IDEA 自动生成单测的插件
- Squaretest 插件（收费）
- TestMe 插件(免费)
6.结束语
编写整洁的代码可以让我们 提高代码的可读性,使代码变得更易扩展。
