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