你自己的代码可读性怎么样，能让不懂代码的同学看懂主要逻辑吗？有没有“觉得大家的代码风格都差不多”这种感觉？
有没有被吐槽过，或者被赞扬过？
是否也写过或见过几百行的代码，内部调用的方法又是几百行？你见过可读性最好的代码是什么样的，它有什么规则？
代码可读性重要吗，它只有外延没有内涵吗？
无所谓你遇到过哪种问题，或者对某些问题感兴趣，如果说情人能带给你幸福，那么这篇文章或许可以带给你春风。
当养成了某个习惯后，这个习惯可能是好的也可能是坏的，构思代码的习惯就是一个很好的例子。 当拿到需求后经过评审之后，就知道要做什么事了，可是代码要怎么写？
写个Controller、Service 、Dao一通调用，没错这就是习惯。 如果需求量大的很有可能导致service层逐渐臃肿，业务紧密度很高，不易维护。 如果是一个新人对这大段代码来进行梳理的话，学习成本会很高，而且效益不佳。
可读性是没有标准的，只能站在调用方的角度体验调用方式，站在非己的角度去读代码。?如果很难衡量这样的一个点的话，那么可以尝试这种方式：
读一个可读性好的代码可以像读一本书那样，有目录，有章节，有小节、有内容，不同的章节写不同的内容，如果忘记某一个点在哪个章节下就从目录开始看。
一个例子：
从配置中心获取所有节点供上游使用。?如果该节点没有权重，则按照一定算法进行权重分配。?权重分配后按照一定规则进行排序，最近一次使用的配置，置顶配置，指定配置，其他的按照权重降级排序。
思路：
当拿到一个需求的时候首先要清楚逻辑，可以通过绘图或者其他方式让逻辑更清晰些，比如上述的例子中可以有这样的思路：
1、获取所有节点配置信息； 注意这个时候可能由于异常获取其他原因获取不到数据。
2、分配权重，这个时候可能大多数同学都会想到if，先不要管这个，需要知道的是，只要有分配权重这样的事情发生就要处理，所以我们很确定分配权重这件事要做，但是具体怎么做，在这件事内部做处理。 说白了if判断要在分配权重这件事内部去做，而不是在之前。
3、按照规则排序，既然有明确的规则，而这种规则可能会随便变更或者多个规则交替使用，所以把排序规则单独抽取出来一个逻辑处理层，这个处理层只负责排序这件事，这样即可保证每个处理层的职责边界，也不会让单一的处理层变得臃肿。
下面用两种编程范式大概实现下思路：
1）函数式
? ???????
@Slf4j@Service@RequiredArgsConstructorpublic class ConfigService {private final ConfigLoader configLoader;/*** 1、根据产品线获取配置信息。* 2、设置权重* 3、对配置进行排序* 4、构建返回结果*/public List<ConfigResult> fetchConfigList (ConfigDTO dto) {return Option.of(configLoader.fetchConfigsByProductLine(dto.getProductLine())).map(this :: buildWithWeight).map(sortConfigsFunction()).flatMap(buildToConfigResultFunction()).getOrElse(defaultResultSupplier());}}
2）命令式
@Slf4j@Service@RequiredArgsConstructorpublic class ConfigService {private final ConfigLoader configLoader;public List<ConfigResult> fetchConfigList (ConfigDTO dto) {// 根据产品线获取配置信息List<Config> list = configLoader.fetchConfigsByProductLine(dto.getProductLine());// 如果没有获取到配置信息就返回默认配置If (CollectionUtils.isEmpty(list)) {Return defaultResult();}// 设置权重this. buildWithWeight(list);// 对配置进行排序this.sortConfigs(list);// 构建返回结果return buildToConfigResult(list);}
上述例子中可以把ConfigService看作是一本书，甚至可以把public方法fetchConfigList看作是一个使用说明，其中的每个小方法都是一个目录，每一个小方法都是具体的内容，这样做可以让每个方法的职责具体化，有什么用呢？
可以提高函数的组合性。?如果你的方法是近百行甚至几百行，内部逻辑不单一，那么怎么组合呢？?是不是会有很多重复的逻辑在不同的方法里，这样让人读起来就很容易产生困扰。
第二个要说明的是，一定不要把你的逻辑处理层搞的很臃肿，什么事都做，拿上面的例子来说，该方法的核心职责就是获取配置信息供上游使用，那么如果在设置权重的时候失败了就不返回给上游数据了吗？
肯定不是，设置权重的功能起不到阻塞核心流程的作用，所以对于这个方法来说，设置权重是一个支持的功能，把这部分功能单独提取出来，可以做降级处理，并且这种处理是单一的只对设置权重有效，以此体现了代码的伸缩性。
同样排序规则也是一种支持功能。 有可能排序规则很多，说白了总不能和核心业务逻辑都写在一个类里吧。
可读的代码除了让代码逻辑清晰易读外还有个我认为比较重要的内涵，就是测试。
在写单测的时候，目的是让代码符合预期，如果业务代码中的某一个方法逻辑冗杂，链路交错，会给单测带来很大的麻烦，有可能就漏掉了某个逻辑分支。 如果按照上述例子的方式我们会得到类似如下这样的图：
相信以这样的形式展现的话，无论懂代码的程序员还是不懂代码的业务员都能够看得懂。 在开发过程中最大的代沟便是业务和开发者之间，通常来说业务的关注点在于交付业务价值上，而开发者则将注意力放在技术实现上，并不是说开发者的动机是错的，这是一种习惯性，自然而然的就被吸引到了实现层面上，导致最终交付的结果和业务想要的差异很大。
如果能尽可能的让业务了解代码的逻辑或者以其他的方式展示给业务，那就是能够符合业务战略的具有业务价值的软件，并且可以将竞争优势融合进解决方案中。 同时一个符合预期的超高的代码覆盖率能给予程序员以自信，因为这样的测试适应了预先定下的需求。
所以何不在“大家代码风格差不多”的情况下，让自己脱颖而出呢？?即便上升不到业务价值的层面，良好的可读性也会让自己产生愉快感和成就感，在枯燥的工作中让好习惯成为自己的乐趣，也算是彰显人格的性感和立体吧。