在回家的路上，一直在思考需求的可行性，索性把最近的已知的问题做一个简单的复盘。
在网上也看了很多bug汇总，都写的比较细，那么我们是否可以宏观的思考，为什么会造成错误。
简单的归纳了几个点：
- 代码逻辑错误
- 产品需求错误
- 场景缺失错误
- 异步错误
- 概念理解错误
接下来展开讨论一下。
代码逻辑错误
「 人很容易发现别人的错误，而对自己的错误视而不见 」
要想发现代码逻辑的问题，最简单的办法就是看老代码或者看别人的代码。代码逻辑体现的是你对需求的理解，以及你对整个产品逻辑的把控。
比如一个列表的渲染。每一次请求我们都会标记返回的数据列表，记作now_list，然后把列表拼接到现有的列表上面，记作list。当列表底部到页面底部的距离大于一定数值的时候会自动触发请求，加载loading。然后判断当now_list为空的时候，停止自动触发。这是正常的逻辑。
接下来，骚操作来了，把loading的开启条件放在了触发条件里，我们可以记作这个触发的方法为onEndReached，把关闭loading的方法放在了请求方法里。这样导致的结果就是当起始数据量小(比如列表长度为1的时候)的情况下，会不断触发loading，关闭loading，然后进入死循环。然后又一个骚操作来了，因为每次请求的列表数量为4，所以在onEndReached方法里，添加里一个判断条件，当now_list的长度小于4的时候，不开启loading。很简单的问题绕了一个大圈。而且像这种以数字为条件的的代码逻辑，一定要引起警惕。因为这预示着你的代码逻辑不严谨。关于代码逻辑的问题还有多层判断条件的问题，比如报告的生成与查看，查看报告的按钮除了不能在状态1和8展示，其余状态都可以展示;而下载报告的按钮只能在状态5或6展示，分享报告的按钮只能在6展示。无论查看、下载、分享都操作的是同一个按钮。像这种逻辑判断条件多的情况，极易产生错误。
产品需求的错误
「 需求评审，都是一场辩论会，不是说服别人就是被说服 」不要太相信产品，因为他们也会犯错误。总结了一下已知产品需求的错误，分两类：
- 无用的需求
- 不合理的需求
先说一下无用的需求，为什么说是无用的，比如上一版做的功能，下一版全部推翻。也就是说，在上一段时间内，你在做无用功，没有对产品产生任何价值。一群人白白耗费了一段时间去做了一件毫无意义的事情。再讲一下不合理的需求，比如买一赠N，在列表中折叠。不管是赠送的订单还是正常的订单，在订单列表中是平铺的。为了解决订单之间的关联关系，给用户呈现层级的展示效果，前端需要做的是把平铺的数据整合成树状结构，然后折叠起来，方便用户查看。列表请求数据条数是一定的，比如4条数据就可以填满屏幕，我们一般会请求5条，以便上拉加载。那么我们可以假设一下场景，比如买一赠7，当我们首先加载完5条数据，并整合成树状结构，折叠起来就变成了一条数据，就会再次触发请求加载，这次我们又加载了5条，不巧的是下一次的正常订单也是买一赠7，前3条数据还是上一条的赠送单，那么我们继续重组数据，现在订单中有两条数据，第一条数据折叠了7条，第二条数据折叠了一条，还会继续触发请求加载，直到屏幕上放满了正常的订单。这个过程会不断的重组数据，并不断的加载loading，关闭loading。专业点的术语可以叫"闪屏"。当然可以把折叠的数据默认展开，这也不失为一个好方法。我承认我们做的一些需求不一定合乎规范，并确实解决了一些问题。但是后期的维护实在太困难，而且不可预料。
场景缺失的错误
「 改bug，最忌讳的就是改一处，制造两处 」
场景缺失的问题，也可以简单的归为两类：
- 同样问题，只改了一处，其他处没有考虑到
- 关联问题，只改了有问题的地方，后续产生的问题没有考虑到
前端时间的地址问题确实困扰了一段时间，侧面反应了处理问题不严谨，也反应设计之初没有考虑周全。
省市区的问题，会伴随着传值、回显、提交拼接。问题就出现在了拼接。老数据是直接拼接在一起的，中间没有任何特殊标记，而现在的需求是第三方拿到这个数据无法解析。旧有的逻辑有自己的一套解析机制，但也存在一定的问题，不严谨。所以在已经存在问题的基础修改，注定还是会存在问题。最好的解决办法就是推翻重新制定规则。
当我们在解决问题的时候，一定要考虑此处修改的方案是否会对后续逻辑产生影响，尤其是改别人的代码逻辑，很多问题预料不到，推翻重写成本太大，所以在以后写业务代码的时候一定要解耦，堆在一起的代码，看的实在头疼。
异步错误
代码执行的时机一直以来是一个比较严重的问题，比如我们常常发现的，数据已经请求到了，为什么页面没有显示。
比如react中的setState，更新DOM树是一个很耗时的工作，setState会等一个时机做批量的更新，而不是直接更新。
再比如很多同学想在forEach或map中使用async异步函数，但是不要忘了，你接受的结果也是异步的。
概念理解错误
还有一些错误的因为你对事物本身不了解。
比如前几天面试，有一个女孩说「 我刚用vue3写了一个项目 」，那我就问「 那你vue3常用的语法有哪些 」，她的回答「 vue add、vue ui... 」。我当时脑子就大了。
还有群里哥们问的一个问题：
- ['1','2','3'].map(parseInt)
- // [1, null, null]
- ['1','2','3'].map(Number)
- // [1, 2, 3]
- ['1','2DDDD','3'].map(parseFloat)
- // [1, 2, 3]
问：「 为什么parseInt不可以实现转化 」
map接受方法参数是固定，只能减少，不能修改，parseInt接受的两个参数，第二个参数直接被改成了map规定的索引值，再执行parseInt的逻辑，返回的肯定不对了。
换句简单的理解就是parseInt接受的参数被map强行改为了索引：
- parseInt('2',1)
- // NaN
- parseInt('3',2)
- // NaN
本文转载自微信公众号「惊天码盗」，可以通过以下二维码关注。转载本文请联系惊天码盗公众号。
