像写诗一样写代码：扁平化管理你的代码

《史记》有云：大乐必易，大礼必简，写给机器看的代码简单，但是写给人看的代码就需要一点心思

在我们平常的开发过程中，如果遇到代码嵌套过深的函数，那么我们会

什么叫嵌套过深呢

我们可以简单看一段发工资的例子

我们将函数内部一个左花括号视为一个嵌套深度，那么我们这个函数具有足足 5 层深度，正常情况下超过 3 层深度，这段代码便会散发出臭的味道，当然这不是业界定义，只要你觉得这一段代码不好理解，那么这一段代码就存在可以优化的空间

扁平化

那如何减少我们这个嵌套深度呢？扁平化管理我们代码呢

通常情况下，我们具有两种手段，第一种是提炼，将一段代码提炼到一个独立的函数；第二种是反转，尽快将结果返回给函数。

接下来，我们开始使用这两种手段，去重构一下我们的代码。

提炼

我们什么时候可以提炼函数呢？

就是当我们 「需要花一段时间去理解这一段代码是用来干什么的时候我们就可以将这一段代码去提炼为函数」

举个简单一点的🌰

有时候我们需要检查response 是否正确，正确的话，我们才会进行一系列对应的逻辑处理

if(Objects.nonNull(respponse) && Objects.equals(respponse.code, "200") && Objects.nonNull(response.getModel())) {
 // do something
}

通常情况下，我们要去阅读主要逻辑之前，我们需要去看一下if这到底是什么情况才会走入我们的逻辑，但其实这边都是一些常规的校验，我们大多数的时候根本不关心这个校验的具体逻辑，因为它是用来预防我们的代码出现异常的取值报错

那么，我认为这种的 if 就可以提炼出来一个函数

if(this.isSucess(respponse)) {  
    // do something  
}  

private Boolean isSucess(Response resp) {  
    return Objects.nonNull(respponse) && Objects.equals(respponse.code, "200") && Objects.nonNull(response.getModel())  
}

读者只需要关心，这个 response 是 sucess 即可，不需要具体关心我是怎么 check 这个 response，因为它相对主逻辑来说不是那么的重要

当然还有一种情况，在代码逻辑中区分红花和绿叶，这也是阿里开发手册中推荐的我们的一点，单个方法的总行数不要超过 80 行，代码逻辑分清红花和绿叶，个性和共性，绿叶逻辑单独出来成为额外方法，使主干代码更加清晰；共性逻辑抽取成为共性方法，便于复用和维护

好，接下来我们优化一下引言中的代码

优化之后，主干逻辑就清晰了，我们想要知道每个情况下的工资是如何发放的，只需要点进去具体的函数查看即可

但是这么多的 if 嵌套，看的还是很不舒服，我们继续下一个动作

反转

通常情况下，我们的if、else 就是用来区分在不同的情况下，代码是走向阳光道还是独木桥，阳光道就是可以理解为都是我们重要的逻辑，读者都需要看

独木桥你可以理解为异常情况，需要立刻从函数中返回回去，我们通常称这样的语句为卫语句，基于我们防御性编程的思想下，尽快的检查返回该函数结果

同样阿里规范也给我们提到了这一点

那么我们根据这个思想再进一步优化一下我们引言的代码

最后再对比一下重构前后的代码

总结

在本文中我们接触到了，可以借助提炼以及反转去优化我们的代码嵌套，其实你可以看看当前你的项目中的代码是否存在这样的情况，可以考虑是否优化一波，当然优化的时候切记回归测试的重要性

借用熊节的一句话：据说古时高僧有云 “时时勤拂拭，勿使惹尘埃”，代码当如是，专业人士的技艺应当如是

希望大家都能像写诗一样的写代码

写在最后

在朋友的安利下，上周去了西溪湿地寻梅

顺着路标的最佳赏梅点，我们一路往前走，但其实花还是没有那么的密集，我们可疑惑，是梅花还没开，还是已经谢了

直到，我们看见有个游人，在拍照的时候不断的摇那个梅花树想让自己更为出片，我才悟了，原来不密集的梅花，不是树的不挽留，而是爱美的人的追求