盘点前端问题

要想发现代码逻辑的问题，最简单的办法就是看老代码或者看别人的代码。代码逻辑体现的是你对需求的理解，以及你对整个产品逻辑的把控。

比如一个列表的渲染。每一次请求我们都会标记返回的数据列表，记作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。专业点的术语可以叫"闪屏"。当然可以把折叠的数据默认展开，这也不失为一个好方法。我承认我们做的一些需求不一定合乎规范，并确实解决了一些问题。但是后期的维护实在太困难，而且不可预料。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!