2022年web前端学习经验总结

1、第PAGE9页共NUMPAGES9页2022年web前端学习经验总结项目项目流程1需求评审时了解代码业务，及时提出项目中的技术问题，以及逻辑问题，对于pm的需求不理解的地方不能凭空猜想，需求文档一定要看仔细。_项目排期时间合理，不能盲目自信，不知道多长时间能开发完成就是不知道，对功能分析到位，初次排期要详细，每个功能的实现，与代码逻辑一定能走通，开发功能较多，后端较多的情况应合理安排开发时间，按照优先级排列开发。排期时间内没有完成项目应该向上级汇报并想办法解决。3.功能分析，功能迭代比较多，或者功能比较复杂的，对其功能进行功能分析，多种情况思考，保证功能正常运行。4.开始期间保证前后端进度一致

2、，减少开发时间，提高工作效率。5.代码自测，自测没有问题了才可以进行提测。6.提测期间反复出现的bug要注意，应重新思考代码流程。6.代码上线及时合并分支。_项目跟进，每周询问项目进度，安排相应工作任务。_项目闯车可委托其他人帮完成，或者项目延期开发。git相关_多期项目需求同步开发，不同时间上线，创建不同的分支开发，避免上线代码问题。_项目上线及时合并dev，master的代码。前后端交互1.做项目之前应先与后端统一数据格式，统一接口格式。2.不要盲目定位前后端错误，应该是有问题一起解决，在前端杜绝字段导致的代码问题，保证代码安全性项目代码1.保证代码可读性，命名语义化，写代码注释2.作为一

3、个用户的角度去想这个项目，写出对用户更有好的功能。3.面对比较难的需求的时候，最需要的是一个清晰的大脑，将项目思路缕清，从数据是如何传入，页面如何渲染数据，如何将修改过的数据传回后端。保证思路连贯，然后再去想如何实现等细节问题，做项目的时候最重要的是用户的体验，如何能让用户有更好的体验?首先应该保证项目自己用着舒服。再对页面进行美化，不断的修改。4.将项目中遇到的记不住，或者每次用都需要查的东西记到本子上，背下来，这些知识点会多次遇到，使用时可减少不必要的查找时间。项目进展暂时顺利。项目交接1.交接时问清楚，了解开发业务(现在是什么人在使用?如何使用?后期会有什么人提什么样的需求?)，项目中有

4、什么需要注意的地方，减少开发时间。技术技术学习1.学习不要贪多，尝试把事情做的细致一点_多动手，将项目中的问题抽出来写一个小demo3.切忌死记硬背。4.学习新东西的时候要把握好度，要学到什么程度，别钻到里面出不来5.学的东西杂是因为什么东西都是一知半解，没有深入研究。6.有的问题是因为基础了解的不够多所以才不懂的，有的问题可以通过查找解决。先解决可以通过查找解决的问题，等基础充实后再解决其他问题。技术思考1.学会思考问题，观察问题，分析问题，并对问题进行记录，定位，查找，解决。然后再进行思考问题为什么会解决，为什么不能解决。2.写代码时要明白它的需求是什么样的，需要有什么样的功能，如何实现这

5、些功能，这些功能实现之后会对其他功能有什么影响，是否会对代码的稳定性造成影响技术回顾1.阶段性回顾自己所学的东西，思考自己最近的收获与这段时间的不足2.整理自己的技能树，整理自己学过的东西以及学习的程度，根据自己学习的程度安排自己自己后续的学习计划vue项目1.数据控制视图2.框架的学习，先学会使用，然后慢慢深入了解它的一些原理。了解原理很重要，学明白这一个框架在学其他框架就很好上手，也可以很快了解。3.设计评审将获取数据，存储数据，渲染数据，修改数据，传出数据。数据的整个流向弄清楚，再考虑功能上面的细节。jquery1.代码进口与出口。个人习惯1.细心，不细心能导致很多问题2.工作团队中的合

6、作，自己在团队中能起到什么作用，我对团队有什么样的帮助。3.写周报日报规划好自己每周每天的工作量及任务，养成记录思考的习惯。2022年web前端学习经验总结（二）对一份优秀的交互文档来说，都要具备什么样的基本框架与基础要素呢？如果你没有一个明确的答案，那么本文将为你提供详实的解答。前言：整理文档的过程中看到_年总结的一篇文章，这篇文章主要总结了在Web端后台产品设计时输出交互文档应该考虑的_个方面，虽然现在看来结构简单，考虑的覆盖面也不全，但是在结构上还是值得借鉴。不想看长篇大论的可以跳到文末看结构框架。在交互设计上，规范的控件库是“术”，达于术者，达下乘也，规范的控件库是交互设计的技巧、是可

7、以复用的技术；而统一的交互文档指导方案是“法”，可以复以指导术之提高，达于法者，达中乘也；最后形成一套交互设计、用户体验、信息架构的知识库是“道”，达于道者，达上乘也。从“术法道”而言，随着业务需求的增加，即使有了规范的控件库可以进行复用，但在不同的场景下会有不同的交互规范。但交互文档的结构是可以提炼总结的，交互设计师可以时常对交互文档结构进行归纳总结，以便在今后的工作中针对不同的适用场景根据结构快速给出方案，将更多的时间用在业务逻辑和流程梳理上。本篇文章，以_后台管理系统为例，结合自己的经验来聊一聊我总结的交互方案。包含以下9部分，有：限制条件、状态、页面切换、信息校验、系统提示、界面、浏览

8、器兼容、用户角色、数据埋点等。在输出交互说明文档的过程中需要考虑以上部分，当然并不是一定要包含以上，要视具体的产品需求、功能模块与规格大小来确定。Part1：限制条件1.1是与否是与否，非0即1，允许或不允许，比如：内容的复制粘贴，分私密信息和非私密信息，私密信息不支持复制粘贴，常见的为密码，非私密信息则支持用户复制粘贴。1.2范围值指数值的取值范围。如：列表页展示多少数据记录等。通常在后台管理系统，数据列表统一是展示10条数据，可以翻页查看更多，或者自行选择每页展示的数据量，有“10、20、50、100”供选择。而物料商城的商品列表展示，适配不同分辨率浏览器，让用户使用主流的笔记本、电脑在浏

9、览器可视区域浏览商品时不出现视觉误导(假如每页最多显示商品数_个，若每行显示_个商品的话，存在多页的情况下，商品行数为4行过_个，有_个商品空缺位，这样看起来会误认为数据加载有问题)。我们最终确定的商品展示方案是：每页列表最多展示_个商品，适配不同浏览器分辨率，自动调整为每行显示4、5或_个商品，分辨率越大，每行展示商品数递增。1.3极限值指数据的显示极限。如：文字最多显示多少字，显示不下怎么办；数字输入框是否有上下限等。分别举两个例子：举例一，在_后台管理系统表格中，单元格超过宽度即用“”结尾，鼠标悬浮显示全文。而在设计列表、卡片、面板、弹窗等承载内容的载体时，都要考虑到内容的承载极限，比如

10、在物料商城卡片和购物车卡片，商品的说明内容有多有少，而内容区宽度是固定的，所以需要进行视觉展示上行数的显示。图1.(左)商城商品卡片说明内容限定(右)购物车卡片说明内容限定举例二，在物料商城中，每个商品都有库存数，那么前端购买最大商品数对应的就是该商品的库存数，按常识，商品最小购买量为1。在交互设计上，根据商品购买数的极限值，当购买数为库存数的时候，“+”按钮置灰，表示用户无法再增加，购买数为1的时候，“-”按钮置灰，表示用户无法再减少。同时，若用户输入大于库存的数字，都将被处理为最大库存数，同理，输入小于1的数字，都将被处理为1。在输入数字类型的限制上，只允许用户输入整数。图2.商品加入购物

11、车数量极限值限定(左：极小值、右：极大值)Part2：状态2.1默认状态默认状态显示的列表、文案、选项等。举一个例子，_后台管理系统中很多模块是纯列表展示，要考虑默认展示的列表数据量是否影响加载速度，加载速度长意味着增加了用户的等待时间成本，在这种情况下，可以采取“初次打开不加载，提示用户点击搜索按钮后加载”的方案，避免等待时间过长。图3.列表输入查询条件示意2.2正常状态用户正常使用时，会遇到的状态。比如：商品上架/下架，数据存在动态更新情况。以_后台管理系统物料商城为例，商品背后有复杂的盘点库存管理逻辑，商品盘点缺货的话应及时下架。那么存在一种场景，某商品在加入购物车之前是正常在架状态的，

12、加入购物车之后该商品已被下架了，若将下架的商品从购物车从移走隐藏，这种粗暴处理的结果就是用户会产生疑惑，“我的商品怎么从购物车丢失了？是不是刚刚我没有加入购物车呢？”。根据易用性原则“有效的反馈信息”，我们可以将下架的商品标记为失效商品，与上架的商品作区分供用户快速识别。图4.商品加入购物车不同状态示例(左：上架、右：下架)2.3特殊状态特殊状态往往在一些特殊场景下才出现的状态，这种状态有两类：一是无数据情况(空白页)，二是数据异常情况，拆分数据异常的情况，又可能包含：数据加载失败、网络错误、系统更新等状态。以_后台管理系统的物料商城为例，数据为空的情况有：在商城某分类商品列表无上架商品、我的购物订单列表为空、我的购物车为空这_种。图5.物料商城数据为空占位图示意对于特殊状态，在同属相同功能模块下，可以用一套样式风格和文案风格一致的占位图进行占位处