盘点前端问题,你知道几个?

开发 前端
在回家的路上,一直在思考需求的可行性,索性把最近的已知的问题做一个简单的复盘。在网上也看了很多bug汇总,都写的比较细,那么我们是否可以宏观的思考,为什么会造成错误。

[[383982]]

在回家的路上,一直在思考需求的可行性,索性把最近的已知的问题做一个简单的复盘。

在网上也看了很多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. ['1','2','3'].map(parseInt) 
  2. // [1, nullnull
  3. ['1','2','3'].map(Number) 
  4. // [1, 2, 3] 
  5. ['1','2DDDD','3'].map(parseFloat) 
  6. // [1, 2, 3] 

问:「 为什么parseInt不可以实现转化 」

map接受方法参数是固定,只能减少,不能修改,parseInt接受的两个参数,第二个参数直接被改成了map规定的索引值,再执行parseInt的逻辑,返回的肯定不对了。

换句简单的理解就是parseInt接受的参数被map强行改为了索引:

  1. parseInt('2',1) 
  2. // NaN 
  3. parseInt('3',2) 
  4. // NaN 

 本文转载自微信公众号「惊天码盗」,可以通过以下二维码关注。转载本文请联系惊天码盗公众号。 

 

责任编辑:武晓燕 来源: 惊天码盗
相关推荐

2023-12-15 10:42:05

2024-02-26 00:00:00

前端工具Space.js

2022-01-19 09:03:01

工具

2022-04-15 09:01:18

前端工具UTF8编码

2021-06-01 05:16:49

前端开发技术热点

2023-12-06 14:23:24

2024-01-29 00:51:39

前端开发利器

2024-01-18 00:16:07

2021-10-12 09:20:02

数据库SQL脚本

2019-10-17 16:02:44

高并发缓存浏览器

2023-04-27 08:15:09

2018-09-20 17:05:01

前端程序员JavaScript

2019-05-16 09:50:39

负载均衡高可用数据

2021-11-04 11:54:30

Linux内存系统

2020-01-09 09:56:47

Java集合框架

2018-04-26 09:03:48

ApacheWeb服务器

2021-04-13 05:36:18

C#null 可控

2019-08-29 09:15:30

负载均衡算法备份

2019-07-12 08:45:07

开源微服务框架

2024-03-01 13:48:00

Git配置系统
点赞
收藏

51CTO技术栈公众号