垃圾代码和好代码的区别？

作者：三星无神,,\链接：https://zhuanlan.zhihu.com/p/...几种业务场景下的重构实例请求的顺序取决于本场景业务的复杂程度决定复杂程度的代码。首先我们看一个简单的例子，在前端和node中都有可能出现：我们有四个请求数据的函数A、B、C、D（由函数本身实现），C依赖于B的结果，而D依赖于ABC最终输出D的结果。错误示例虽然这段代码是故意写成这样的，但确实有一些初学者看到过。这段代码还是可以给出正确的结果，但是写法丑陋，回调地狱。如果后面人家不重构，还有request依赖，就得继续嵌套回调。性能太差以至于没有考虑到A和B其实是可以并发的。这里简单介绍一下最原始的callback...中间可以回顾整个ES2015+，callback(async.js)-->Promise-->generator+co-->async+await的演变过程.其实就是不断简化和增强我们从原生语法层面控制异步的能力。下面是直接为当前阶段提供的最终解决方案：基于Promise+async/await的正确例子，我们重新思考了上面的问题，理清了逻辑顺序的依赖。并使用最新的语法。使用Promise.all结合async/await的形式，兼顾了并发和序列化，写法简洁，实现了例子要求下最快的解决方案。解决了无限嵌套的问题。这是语言进化本身带给我们的一种优化。但不仅如此。我们对问题进行分类，将具有依赖顺序的B和C的请求分离到单独的函数中。让他们处理自己的逻辑。我们稍后会回到这一点。折磨人的ifelse可能会出现以下一些问题。过多的嵌套逻辑处理冗余。无防御性编程（错误处理直接自带代码示例，这是获取背景色的方法，但是随着业务的不断变化，背景色的来源越来越多，处理下可能是这样的部分业务人员：错误示例认为，上面的代码让你阅读起来极其痛苦，基本不可能一眼就知道你最终会进入哪个分支，因此，基于以下两个原则，进行合理的抽取intoafunctionerrorpriorityreturn有重构的基本版本：正确的例子可以看到整个逻辑，已经重构。拆分成三个函数，子方法分别处理对应层级的逻辑，一个主方法负责调度。整个事情一目了然。当然，我们按照上面的原则重构之后，这段代码有没有问题呢？当然有。可以看到我们三个函数都依赖全局变量。函数本身是不纯的。如果是全局问题，还是不好排查。我们可以把它修改成一个纯函数，让这段代码更容易理解和测试。以修改一个函数为例：我们把全局变量变成了一个参数，调用的时候只需要传入全局变量，但是这样，我们得到的是一个纯函数。为什么要在这里强调这一点呢？事实上，函数式编程中最基本的问题之一就是纯函数。只有这样才能观察到输入和输出，有输入必有输出。只有这样，系统中的不纯函数才能越来越少。使代码更易于测试。当然，如果我们从重构的角度去思考，还需要注意这一点：这里的逻辑会将最后匹配到的数据设置为bgColor。（我们都知道findindexOf之类的过去基本匹配）真的是业务需求吗？可见，编写/重构业务代码的过程其实是对业务逻辑和业务理解的另一种提升。无论是抽离成一个函数，还是错误优先返回的设计，这其实都可以解决这样一个问题：在不了解全局的情况下，了解某个区域的详细逻辑，让代码易于理解和修改。...这里的代码即使经过这样的重构，仍然还有进一步优化的空间，比如函数和参数的命名，完整的测试用例等，受限于文章篇幅，不再赘述暂时。一些代码中可能存在的其他问题在视图层中逻辑耦合。a==='a'&&b==='b'&&c==='c'&&d==='d'?

：空组件复用，函数复用，无封装，代码重复。功能不单一，一个功能承担太多职责。这些职责没有任何关系，但它们都耦合在同一个块中。参数列表混乱，防御性编程，不处理错误（接口错误，超时，重复提交等。幻数，幻串，没有描述。数据结构不好/命名不好（其实上面的具体代码例子也存在）思考代码优化首先说一下为什么要优化代码?技术追求。公司要求有系统在线使用。有用户在用，写不好吃亏的其实是我。团队合作，我写不好，其他组员也写不好。恶性循环是受苦的人。快速迭代。系统需要不断增加新的功能。您必须编写好的代码才能做到这一点。别人的看法，我怕别人会觉得我技术能力差……xxxx……那么就会有以下要求：容易理解系统架构，容易理解系统的生命周期和执行过程系统，容易理解各个函数的作用，容易理解函数是如何被调用和传递（输入和输出）的，容易理解变量的含义和表达式的含义。易于扩展......实际上回到编写应该干净、易于理解/修改/测试的代码。（其实这里大部分时候是隐含了一个人协作的条件在里面，所以需要把代码写好，但是不要过度封装，让团队其他成员看不懂（当然，如果有些人经验不够，那么对自己的问题就需要自己去加强。））一些建议，更清楚地了解业务，思考可能的变化。做之前想清楚，设计清楚。查看一些开源项目和行业中的最佳实践，了解什么是好代码，什么是坏代码。该机构明白，虽然代码是供计算机运行的，但它最终是由人类阅读的。这不仅仅是无错误的心智模型。建立业务与代码质量同等重要的思维模型。避免因为时间原因必须以这种方式编写的代码。理解codereview本身或许可以发现并指出一些问题，但是最终的实现还是要看你自己，不能变成一个形式，需要融入到你自己的思维中。使用错误优先原则。尽量让错误先返回，这样你以后会得到干净的代码。（写代码的时候不仅要考虑正向判断，还要考虑反向判断）合理拆分成独立的函数。明确函数内部对输入输出的处理、错误处理等。（比如某些场景下确实会有大量的逻辑判断，首先要考虑判断里面的语句是否可以分类拆分出来。）对于多个状态的判断和组合，可以使用组合状态表（映射表）状态机等模式学习设计模式和重构等相关知识。重构！！只要你觉得这个地方有问题，就别等到后来了。然后通常再也不会了。结束说到这里感觉像是突然结束了。在本文中，我们首先通过两个具体的优化代码示例作为介绍，让大家了解一些业务代码优化思路。之后列出了其他一些可能的错误，以及优化代码的思想准备和理论指导。其实就是希望大家能在业务中发现问题，然后思考如何解决问题，因为说了这么多，是不是就能把代码写好。你还是要靠自己。近期热点文章推荐：1.1,000+Java面试题及答案（2021最新版）2.别在满屏的if/else中，试试策略模式，真的很好吃！！3.操！Java中xx≠null的新语法是什么？4、SpringBoot2.5发布，深色模式太炸了！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！