代码整洁之道
原创不易，且行且珍惜”
01
—
前言
【挑战者号事件】1986年1月28日，美国东部时间上午11:39，“挑战者”号航天飞机在发射仅 73.124秒后，因右侧固体火箭助推器故障，在1.5万米高空爆炸坠毁，7名航天勇士全部罹难。
背景：高热气体从出现故障的固体火箭助推器的外壳接缝处泄露出来，喷到外部燃料舱体上，主液氢燃料舱底部发生爆炸，液态氢被点燃。
根本原因：在火箭助推器的圆形接缝处，有2个由合成橡胶制成的同心密封圈。发射前夜，气温降到了-8摄氏度，比密封圈的最低承限温度低了13度，这个温度下的密封圈已经硬的失去了弹性，无法很好地密封高热气体。
工程师们写了备忘录，发出了高危预警信号，要求宇航局的管理人员取消此次发射任务，面对财务和政治的 压力宇航局的管理人员们无动于衷，最终导致此次灾难发生。
反思：事前应对各个零部件进行严格的检测，并将问题报告给生产商莫顿*奥赛科公司和美国宇航局的管理人员，发出预警信号，有必要抗议取消发射任务。如下为发生此次事故的O型圈：
02
—
联想（雪崩效应）
由上面的“挑战者号”事故，我们联想到我们作为工程师开发的系统，当由小问题产生的连锁一系列积累也会引起以下问题：
1、服务提供者不可用；
2、重试加大请求流量；
3、服务调用者不可用；
4、整个系统崩溃不可用
2017年做支付系统时，虽然没有遇到灾难性的问题，但是各种问题层出不穷。当时的系统技术栈很落后。
技术栈：Struts1.0、ibatis、jsp/html、ThreadPoolTaskExecutor定时任务。
程序：代码冗余、结构混乱、开发困难、测试部署艰难。
遇到的问题：一个action类2000多行代码，一个method方法几百行代码，上游渠道、支付方式和路由等规则繁多，支付系统处于中台系统，下方连接商家的支付通道接口，上游连接各个银行机构等渠道。没有可视化界面系统部署可以测试和操作，只有一个jsp测试页面用来测试各个接口（交易下单、退款、交易查询、退款查询等）。
查询问题非常艰难，需要去到不同办公司的运维部门同事的机器旁边，登录生产服务器跟踪日志排查问题（或者打包日志自己查询）。经常出现长款或短款问题，商家支付了没有收到支付系统的异步通知，一是由于支付系统问题导致没有通知到商家，二是由于上游渠道问题没有通知到支付系统，或者在接收上游异步通知的过程中出现问题导致失败。
03
—
重构
基于以上频发问题带来的耗费大量运维人员成本和时间成本等，公司决定重构系统。
技术栈：SpringBoot/SpringCloud kafka Redis vue angluar
系统采用微服务架构，按照业务把支付系统划分为：交易、支付、清算、收银台等模块，前后端分离的策略。
开发和测试以及部署工作变得非常简单，采用链路式日志追踪中间，排查问题简单方便，线上问题减少了很多。
重构的微服务子系统架构如图所示：
04
—
代码整洁之道
4.1 何谓整洁代码
代码逻辑直截了当，缺陷难以隐藏
尽量减少依赖，便于维护，便于阅读
分层战略完善代码逻辑，不冗余
有单元测试，性能调优
只提供一种做一件事的途径
4.2 方法和技巧
有意义的命名 重构 Code Review逐步改进
4.3 有意义的命名
a、名副其实 b、避免误导 c、做有意义的区分 变量、函数、参数、类、包命名中的原则
public List<int[]> getThem(){
List<int[]> list1 = new ArrayList<int[]>();
for(int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}以上这段代码，我们认为是不太整洁的，至少存在以下几个问题：
（1）theList中是什么类型的东西？
（2）theList零下标的含义是什么？
（3）值4的意义是什么？
（4）怎么使用返回的列表？
运用整洁的技巧之后：
public List<Cat> getCat(){
List<Cat> catList = new ArrayList<Cat>();
for(Cat cat : animals)
if (cat.color == Constants.WIHTE)
catList.add(cat);
return catList;
}05
—
重构
1、何谓重构：软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高可理解性，降低成本。
2、为何重构：可读性差、难以维护和修改，冗余甚至出现隐藏bug，带来线上隐患。重构可以改进这些问题，帮忙找出bug，避免问题。
3、何时重构：《三次法则》第一次做某件事时只管去做 第二次做类似的事会产生反感，但无论如何还是可以去做 第三次再做类似的事，就应该重构了。
预备性重构，让添加新功能更容易；帮助理解重构，使代码更易懂；有计划的重构，长期重构等。
4、挑战：延缓新功能开发，代码所有权，分支问题、测试问题。
尝试重构以下代码段，重构之前：
public void scaleToOneDimension(float desiredDimension, float imageDimension){
if(Math.abs(desiredDimension - imageDimension) <errorThresold)
return;
float scalingFactor = desiredDimension / imageDimension;
scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f);
RenderedOp newImage = ImageUtilities.getScaledImage(image, scalingFactor,scalingFactor);
image.dispose();
System.gc();
image = newImage;
}
public synchronized void rotate(int degrees){
RenderedOp newImage = ImageUtilities.getRotatedImage(image, degrees);
image.dispose();
System.gc();
image = newImage;
}重构之后：
public void scaleToOneDimension(float desiredDimension, float imageDimension){
if(Math.abs(desiredDimension - imageDimension) <errorThresold)
return;
float scalingFactor = desiredDimension / imageDimension;
scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f);
replaceImage(ImageUtilities.getScaledImage(image, degrees));
}
public synchronized void rotate(int degrees){
replaceImage(ImageUtilities.getRotatedImage(image, degrees));
}
public void replaceImage(RenderedOp newImage){
image.dispose();
System.gc();
image = newImage;
}06
—
总结
我们在做系统开发编码时，无论是对于系统响应及时性没有前端系统要求那么高，却有业务复杂、数据严谨的性质。还是面对高并发多线程，海量业务，分布式事务，一致性等要求很高的情况。良好的代码质量是保障系统和业务稳定的基础，要求我们从每一个代码、每一个变量、每一个方法做起。