前言
前端侧重于人机交互和用户体验,后端侧重于业务逻辑和大规模数据处理。理论上,面向用户的产品里,所有问题(包括产品、设计、后端、甚至看不见的问题)的表现形式,都会暴露在前端,而只有部分问题(数据问题、计算问题、安全问题等)暴露在后端,这就意味着前端起到了至关重要的承载和连接作用。
前端技术的更新日新月异;前端框架的技术选型百家争鸣;视觉审美的潮流不断更替;可视化效果酷炫无比;用户的运营体系逐渐精细化;适老化、无障碍化、青少年人群的诉求浮出水面;智能设备的升级和适配无穷无尽。所有的这一切,对前端领域和前端同学就一个要求:要折腾,爱折腾,反复折腾。
一、前端开发流程
需求评审
一般在做需求评审时,PRD里只有交互稿,尚未有视觉稿。需要在评审结束并达成一致后,再输出视觉稿。
1、需求分析:需求点逐一讨论、需求合理性、交互评审、逻辑梳理,以及可能遗漏的部分。
提示:逻辑梳理的过程很花时间,贯穿开发始末。
2、涉及渠道/环境:
渠道和环境,往往是需求盲点,也是影响技术选型和开发进度的关键因素。
3、可行性分析:是否有技术上的实现难点,是否有其他的依赖条件。
数据来源:哪些是调接口,哪些是做成可配置,哪些是前端写死;可配置的部分,是前端读取,还是接口读取然后返给前端。提示:可配置的灵活性与风险正相关。
异常流设计:容错、容灾、兜底、降级、回退机制、风险可控。prd一般只写了正常流的逻辑,异常流往往需要研发同学配合做全盘考虑。
6、需求变更:如有需求不明确、改需求、加需求、砍需求、加时间、改时间、加人力等等,需要提前预判风险。
视觉评审
1、进度跟进:视觉稿是分批交付,还是一次性给到?这是要首先考虑的。
按照历史经验,前端项目进度的延误,有一半的概率依赖于视觉稿的进度;因为一个新页面的开发,前端有30%~50%的工作在做页面构建。
2、视觉稿的文件格式:
备注:Sketch 是Mac平台独有的原型设计软件,最为知名和常见。Figma 是最近比较火的全平台原型设计软件,有取代 Sketch 的趋势。
【划重点】交付视觉稿时,需要视觉同学输出“带尺寸标注”的视觉规范文件。
3、检查需求:是否覆盖需求和交互设计中的全部设计点。
4、检查视觉规范:
5、哪些图是前端构建,哪些图是写死图片资源,哪些是可配置;可配置的图中,需要把每个元素做拆解,这个元素是合并到背景图中,还是单独切图,还是读取数据。
6、切图格式:png(透明格式)、jpg
切图的图片大小,不要太大。移动端的大图(比如幕帘弹窗的背景图)建议不超过50kb,小图建议不超过20kb。图片在上传之前,可以先在 上进行压缩。
7、复杂图形、动画的实现难度和实现方式,技术评估。详见接下来要讲的「技术选型」。
排期评估
1、排期一般包含这几个要素:
2、评估排期时,要根据视觉稿排期,不要根据交互稿排期。这是首先要强调的。一个新页面的开发,前端有30%~50%的工作在做页面构建。 只看交互稿的话,无法评估真实的开发工作量。
3、前端开发工作包括:概要设计、视觉构建、逻辑代码、前后端联调、自测、转体验。每一项都要单独拆解后评估时间,加在一起就是整体的排期。
4、排期时,要考虑其它的依赖因素:比如视觉稿延期、需求不明确、接口进度、测试进度,当然最重要的是上线进度。紧急项目,经常是根据上线时间倒推开发排期。
5、即将进入开发阶段后,与测试部门协调测试资源,确认转测时间;大型项目&重点项目,需要在需求评审阶段,提前知会测试部门,让其预留时间。
6、如果自己有在并行开发其他项目,则排期时需要给自己预留 buffer。并行开发两个项目是家常便饭;但,这个项目在测试时,往往很难抽身去做别的项目,因为会一直被测试童鞋牵制。
7、开发排期:如果开发排期有变更,需要立即周知其他相关人员,尤其是要评估测试排期的风险。测试排期比开发排期 更难变更。
技术选型
技术选型千变万化,百家争鸣。这里需要列出你所在部门的常用技术选型,并非市面上的技术栈罗列。
1、页面开发框架:
(1)多端页面:(小程序原生页面、H5)
注2:有些业务,一开始只做H5,后来迭代时,要求做小程序原生页面。这一点也要纳入需求评估。
(2)H5页面:Vue.js 框架、React 框架
(3)App端:
(4)B端开发,UI框架:
(5)Node.js后端开发框架:
2、CSS预处理器:SASS
3、复杂图形、动画的实现难度和实现方式,技术评估:
概要设计
开发环节
1、代码设计:
(1)目录结构设计、代码风格
(2)公共组件、工具类设计:确保可复用、高内聚低耦合的原则。哪些可以复用京喜平台的公共组件,哪些需要自己单独写 components、utils。
(3)弹窗设计:如果一个页面有多个弹窗,建议先设计一个抽象的弹窗基类。设计弹窗时,需要考虑的是:
2、视觉构建:
(1)后端在开发接口时,前端做视觉构建;视觉构建完成后,前端根据接口文档的定义,通过 mock 数据的方式调接口,写前端逻辑;待接口开发完成后,可进入前后端联调阶段。
(2)建议前端童鞋学会自己切图,可控程度更高,也能减少沟通成本。学会基本的 PS、Sketch操作就行,做一名合格的前端切图仔。
(3)对于规则的样式和动画,建议用代码实现,而不是图片。图片会降低页面的打开性能,且大屏都显示效果比较模糊。
(4)切图的尺寸要求:100%宽度以 750px 为准。
(5)像素级还原视觉稿:推荐使用 Snipaste 截图软件,按F1截图,F2贴图,然后调整贴图的透明度为50%,将贴图与前端页面进行像素级比对。
3、业务逻辑实现:
(1)建议先用思维导图,梳理业务逻辑,再着手写代码。思维导图有利于理清逻辑、事后复盘、高效给他人讲解,一目了然。重要的是思想,而不是用哪一款工具更酷。
(2)在调用接口时,要明确前端自己的安全边界:假设接口字段异常时,前端需要有自己的降级措施,不能完全依赖和信任字段,导致让页面直接白屏、交互异常、甚至挂掉。
(3)除了完成产品要求的业务逻辑之外,还要时刻考虑异常流的设计和容灾。
(4)很多前端童鞋在做需求时,有个习惯是不喜欢细看prd,只对着交互稿和视觉稿进行开发。这样做虽然省事,但有三道手续不能少:
4、非功能性需求。业务代码写完后,还有很多细节需要打磨。比如:
5、代码提交:
6、自测:
产品体验
1、在真机体验,而不是在模拟器上。最好是 iOS和 Android 都要对比体验。
2、体验时,记录整理各种 todolist:
代码评审/代码review
代码 review 可以在测试期间进行。
review顺序:
视觉走查
视觉走查 可以在测试期间进行。
视觉童鞋都有像素眼,即便是一两个像素的区别,他们都能瞧出来。所以,建议前端童鞋加强自测,努力做到像素级还原视觉稿。
推荐前端童鞋使用 Snipaste 截图软件,按F1截图,F2贴图,然后调整贴图的透明度为50%,将贴图与前端页面进行像素级比对。
测试环节
1、建议加强自测质量。进入测试阶段后,测试童鞋会进行一轮冒烟测试,如果质量不合格,将会被打回,这就很尴尬了。
2、整理自测、测试、发布时需要的主流程checkList,每次迭代时都能用上。
转测邮件的基本元素,包括但不仅限于:
3、测试童鞋提的bug单,开发同学需要在 XX 小时内处理完成,否则会被QA催。
4、需要控制bug单数量,否则会被追责复盘。同类问题,建议测试童鞋合并到同一个bug单中。
5、测试管理系统 是所有人处理bug 流程的平台,不是让测试童鞋随便记录个人问题的。所以要提醒测试童鞋,明确该问题是bug,再提单;不是bug,要么不提,要么在沟通后驳回。
发布方案
上线确认
二、前端工程化
Git 版本管理
1、前端代码仓库 git 分支规范:
2、Commit Message 的格式,只允许使用以下10种标识,最常见的是 feat和 fix :
3、业务分支,命名规范:(建议一定加上日期)
代码规范
CSS预处理器
包管理
编译构建
小程序工程化
测试相关
三、前端核心知识
前端入门核心知识点
浏览器
HTML5
CSS、CSS3
JS基础
JS 高级
Node.js
Web 安全
页面形式
四、前端框架
每个框架和工具,都有自己的约束、价值和最佳实践。
JS框架
对比:
在vue 中,几乎给你想要的全部给你了;而react 追求的更多的是自力更生。
CSS框架、组件库(B端常用)
知识库框架
补充:知识库框架,首先推荐 Vuepress 和 Docusaurus,功能强大,成熟稳定。
API 文档框架
跨端框架
桌面应用开发框架
Electron 非常流行,也被大量公司使用,也有很多成功软件,比如 VS Code、Facebook Messager、Twitch、Microsoft Teams 等。Electron 虽然上手容易,但问题也很明显,就是慢、吃内存和大,Electron 吃内存是因为打包的 Chromium 吃内容,同时一个 Hello World 编译后就要 120M+ 。
VS Code、chrome、小程序开发者工具,本质上都是运行的 chrome 内核。所以你会发现,这三个软件都很占内存,都很卡。我将其称之为“前端头痛三剑客”。
前端可视化框架、图表库
编辑器框架
Node.js 框架
服务端渲染框架
前端测试框架
五、前端性能优化
性能分析工具
性能参数
浏览器渲染优化
JavaScript 优化
资源优化
构建优化
网络传输优化
六、前端工具和资源
前端文档
前端社区
JS 学习资源
JS 代码规范
1、Airbnb JavaScript Style Guide:
2、clean code JavaScript:
前端刷题
CSS 学习资源
字体相关资源
抓包工具
兼容性查看工具
图片相关工具
设计工具
流程图工具
大纲笔记
markdown 编辑器
代码编辑器
七、前端书籍推荐
JS经典书籍
JS进阶
CSS
Vue.js
Node.js
数据结构和算法
后端
项目管理和认知
产品
设计
运营
商业
思维和认知
八、前端总结和认知
研发视角,如何理解需求
从上面的流程图中可以看出,产品经理的交付物是什么?是prd吗?显然不是。
产品经理的工作跟设计师、工程师非常不同。人们对工程师的期望是交付有效的代码,对设计师的期望是交付视觉稿。而对于产品经理来说,只交付一份prd是不够的。
产品经理要负责跟进整个产品周期,包括上线后的页面效果和数据表现。编写需求规范是一种沟通和推动项目的手段,但规范本身并没有内在的价值。很多产品经理并不借助prd来交流他们的想法,他们可以用谈话,还可以把想法画在白板上。也有一些产品经理虽然写了规范,但却没有参照执行。
前端工程师应该具备怎样的能力和素质
前端认知
1、虽然我们绝大多数时间耗在业务开发上,但仍需要积累其他方面的沉淀,做多一些有趣的、可持续的事情,比如分享总结、基础能力建设、研发效能提升、技术运营建设、技术沉淀等。
2、学会提问。我们日常在提出问题和解决问题时,经常容易陷入X-Y问题,导致目标不明确、思路不清晰、沟通效率低下,甚至在一个完全错误的方向上浪费大量的资源、时间和精力。无论是在寻求帮助的人身上,还是在提供帮助的人身上,都有所体现。
在面对一个问题时,要理解这句话的意图、事实、情绪、期待。学会提问,学会答疑,都是一种智慧。参考提问的智慧 。
3、全流程跟进,持续交付,创造业务价值。
4、前端的本质是链接商业、设计、计算能力,为用户提供专业的人机交互体验。
5、产品能力和技术能力是:判断信息,抓住要点,整合有限的资源,把自己的价值打包成一个产品进行交付,并获得回报。
6、部门体系的角色有很多:运营、产品、视觉、开发、测试、架构师、leader、行销、数据分析、运维等。有些工作不是“做或者不做”的问题,而是程度的问题。在注意边界的前提下,主动承担、全盘思考、多一份同理心,这是能力和责任逐渐增强的体现。
7、谦逊、尊重和信任,是协同作战和良性合作的基础。
8、组织内,人与人的关系应该是怎样的?有人认为是管理与被管理的关系,有人认为是合作关系。而我认为,组织内的关系是奉献关系。没有奉献作为基础,组织关系是不成立的。组织内的人与人之间是相互付出的关系,部门与部门是相互付出的关系,上级与下级之间是相互付出的关系,在这样的相互奉献关系中,组织才会真正地存在并发挥作用。
奉献关系所产生的基本现象是:每个处于流程上的人更关心他能够为下一个工序做什么样的贡献;每个部门都关心自己如何调整才能够与其他部门有和谐的接口;下级会关注自己怎样配合才能够为上级提供支持,而上级会要求自己为下级解决问题并提供帮助。
能力很重要,而付出更重要。
9、优秀的人有几个特性:敏感、不能忍、有动手优化的能力。
10、前端侧重于人机交互和用户体验,后端侧重于业务逻辑和大规模数据处理。理论上,面向用户的产品里,所有问题(包括产品、设计、后端、甚至看不见的问题)的表现形式,都会暴露在前端,而只有部分问题(数据问题、计算问题、安全问题等)暴露在后端,这就意味着前端起到了至关重要的承载和连接作用。
11、前端技术的更新日新月异;前端框架的技术选型层出不穷;视觉审美的潮流不断更替;可视化效果酷炫无比;用户的运营体系逐渐精细化;适老化、无障碍化、青少年人群的诉求浮出水面;智能设备的升级和适配无穷无尽。所有的这一切,对前端领域和前端同学就一个要求:要折腾,爱折腾,反复折腾。
暂无评论内容