十万行级别商业项目(前端)上手过程(不定期更新)

时间:2021-1-8 作者:admin

起因

由于跳槽后明显感觉工作难度提高,感觉现在的前端开发已经发展的相对比较成熟了,光是技术领域就有工程化、微前端、可视化等方面。如果只是基础好但缺乏项目经验,进入大厂后还是会非常吃力,因此本文主要记录如何上手开发十万行级别的项目。

由于入职的时候正好遇上项目交接(项目为CRM系统,包含PC端和移动端,PC端为React, 移动端为Native + React Native),我们组十多个人只有后台leader是入职半年以上的员工,其他人全部都是新招的。在所有前端工程师里面我是第一个入职的,所以有幸参与到了PC端的梳理。

如何从对一个项目一无所知到熟练掌握?如何从初来乍到变得胸有成竹?

首先是项目的梳理,技术上主要包括几部分:路由、状态管理、业务组件、逻辑组件、数据请求(ajax)、项目配置这几方面。然后业务方面的项目背景、交互流程、请求场景。

这里排个序项目项目背景 -> 源码结构 -> 路由 -> 业务组件 -> 逻辑组件 -> 数据请求 -> 请求场景 -> 状态管理 -> 其他

这是我对项目源码的阅读顺序,当然在看一个部分的时候难免会看到其他部分,但是大致的顺序就是这样的。

项目背景

首先是项目背景,项目背景是很重要的,项目的场景是什么?主要解决什么问题?面向的客户是怎样的?了解项目的背景能有助于理解需求、理解逻辑。

对于很多复杂的逻辑,都可以通过项目背景入手帮助理解,光看代码那可是太痛苦了啊,毕竟代码是基于场景写出来的,因此应该从理解场景到理解代码,这样更有利于上手。包括阅读框架的源码也是,需要等对框架的特性和用法都熟悉以后再看,会事半功倍。

了解项目背景以后应该在开发环境试用,尽可能完整地体验每个功能流程,这能让人对项目整体有一个更深入的印象。

源码结构

源码的结构那就是项目大致的架构了,一般而言一个工程化的前端项目包括pages(业务组件)、components(逻辑组件)、routes(路由)、redux/vuex(状态管理)、service(ajax交互层)、utils(公共工具比如对字符串、时间的处理)。当然可能项目里会有更多的目录,但是基本上这几大块是正常的商业前端项目都具备的。也有可能项目设计的不够合理,把某些模块耦合在了一起,这是时候恭喜你,这将是设计前端架构的一个好机会。试想一下,旧项目在自己的推动下变得更加合理,这绝对是一件很有成就感的事情。

正确的阅读源码是先看看每个目录下有哪些子目录,这样就能结合之前对项目的认识联合起来,从而知道功能板块是怎样划分的。比如我们公司的项目,一个功能版块中包含了CRUD这四种页面,那么一个小功能的文件夹下就会有create、detail、delete这三个文件夹,这是业务create和update其实是可以复用同一个页面的。这是通过翻阅目录能看出来的。

路由

路由,是SPA中很重要的一部分,在这里能够看到路由的切换之间携带了什么信息,能够看到大致有哪些组件。

目前已知的一个比较通用的做法是通过路由携带必要信息,跳转完毕后再根据必要信息向服务器请求页面所需的全部数据。比如从列表页跳转到详情页,一般就是在路由中带一个详情id, 待跳转结束后再根据详情id向服务器请求,最后把数据渲染到界面上。因为如果在路由中把详情带上的话,假如从详情页再跳转到别的什么地方,然后用返回键返回到详情页的时候,会因为路由中缺乏了详情信息而渲染报错。

路由正常的做法是按照功能板块切分路由,复杂一些的项目会把不同板块的路由按文件切割,比如route目录下可能是这样子的,其中page1.js里面包含的是功能板块page1的路由以及里面的子路由。目前业内比较通用的一个做法是对路由加载的组件做一个懒加载的处理,这样可以让首屏渲染更快,优化用户体验。

-- routes

    -- page1.js

    -- page2.js

     -- index.js

业务组件

其实对完整地操作一次系统后,对业务组件已经会有一个大致的认识了。在看业务组件的时候能够结合页面上的功能来理解,重点看的有几个点。

首先是组件入参,一般而言首层的业务组件的入参会很少甚至没有,因为主要的参数是从路由获取的,然后想服务器请求渲染页面所需的数据,获取到之后传入子组件。

业内貌似还有一个比较通用的做法,那就是对服务器的请求都是做在父组件的,然后把对服务器的请求写到函数内向子组件传入,当子组件触发点击之类的用户输入后,由子组件触发父组件传入的函数来更新数据。这样组件内的数据仅仅依赖于路由中的参数,因为url不会受到前进后退的影响,所以浏览器对浏览记录的前进后退不会导致bug。

如果页面之间的跳转中带上了数据比如对象数组、对象详情,那么在使用浏览器的回退时会因为缺乏了这部分数据导致渲染错误。

其次是使用到了哪些逻辑组件,并且可以留意一下用法。因为在实际开发中,绝大部分的需求都是业务组件层面上的,这时候学习一下已有代码的写法和风格会有很大的帮助。业务组件一般都不会太复杂,多数都是模板代码,当然也难以避免一些奇奇怪怪的逻辑,初来乍到只要大概看看就可以了,奇怪的逻辑可以等到工作上手后再细看。

逻辑组件

逻辑组件就是相对底层一些的部分。一般是基于开源的组件库,比如react的ant design, 比如vue的vant这些。开源组件库更多提供的是一些通用的样式和逻辑,但是大公司的项目多少会追求一些特别,因此会对开源组件进行二次封装,对一些经常用到的样式和属性还有高度复用的逻辑都封装一次,这样减轻调用时的开销。

需要特别注意逻辑组件的入参,这代表着使用这个逻辑空间的操作空间,我们对逻辑组件的使用其实也只是往里面传参,这时候对参数的了解就很重要了。一般而言简单类型比如数字类型、字符串的参数比较好理解,但是部分复杂的参数比如数组、对象甚至函数,这种就需要查看业务组件中传入之前的封装,以及在逻辑组件中对参数的运用和结构。

逻辑请求

这部分是对服务器发请求的地方,一般而言请求获取到的数据会直接返回到组件内,也有存入状态管理中供所有组件适用的。有一个值得注意的设计细节是当请求遇到错误或者抛出异常时是如何处理的,据说这一个细节能区分出一个人的功底是否深厚。然后还有不同接口之间的url、参数、返回是如何管理的,这些都充满了学问。

成熟一点的系统会在接口中加入权限的控制,那么这个权限的校验、权限的获取以及存储也是值得看一看的部分。权限包括针对个人、用户组、某个功能,不同的权限不同的校验方式和获取方式。

还有一个细节就是对于部分接口的调用是一连串的,这时候这个接口如何封装,如何把这些固化的调用模式编写成通用的接口。对于微服务普遍发展起来的今天,如果前后端协调的不好,数据的组装很有可能会由前端来完成,这时候如何完成这些脏活累活,是不是有技巧,都可以从中学到东西。

请求场景

一般而言正常的系统多数功能是增删改查,然后复杂一点的批量导入导出,但是不同功能的不同实体是不一样的,相对而言一个操作流程在前端是更完整的,因为后端只是看到一个一个的接口,如果文档和注释不规范他们是无法推敲出接口的调用顺序,从而也就无法知晓业务的流程。前端梳理请求的顺序和场景能有助于后端工程师了解系统,也有利于自己更熟悉系统,更熟悉业务,为接下来的开发做好准备。

状态管理

状态管理主要的场景是多组件之间共享数据,一般而言一个大功能对应一个独立的状态管理对象。我认为优秀的状态管理部分应该要有对存储数据的完整描述,每一个字段的类型和取值都应该有描述。目前接手的系统缺乏这部分的描述,从而在阅读源码时带来了很大的障碍。

其他

这部分其实发挥空间很大的,比如老生常谈的性能优化:打包优化(webpack配置、雪碧图)、请求优化、体验优化(如骨架屏),然后测试方面的自动化测试、单元测试之类,国际化的翻译、地理位置定位、git flow、生产问题流程、性能监控错误上报、utils中的公共代码。

目前从事开发的人越来越多,只有保持时刻的思考和进步才能够一直跟上节奏不被淘汰,加油吧打工人

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。