浅谈前端工程化

一袋米要扛几楼
525 阅读8分钟

什么是工程化

1.png

当我在百度搜索什么是工程化时，第一页居然出现了3次什么是前端工程化？这让我感觉到有点震惊！ 通过我以往的学习经验在此尝试性的解答一下这个问题。

  • 前端工程化就是降本提效，保证工程的质量，提升工程的可维护性。
  • 前端工程化就是将前端工程师的工作进行标准化，然后形成团队统一的规范，然后通过工具保证规范的统一执行。前端工程化就是将前端工作标准化、规范化、工具化。
  • 从狭义来说：前端工程化只是gitlab上的一个前端项目，包括技术选型、项目脚手架、代码组织结构、UI规范、代码规范、提交规范、单元测试、CICD
  • 从广义来说：将前端所有工作串起来形成一个流程，对这个流程进行标准化、规范化、工程化，以达到降本提效，提升工程的可维护性的目的。

狭义前端工程化

  • 技术选型 技术选型要充分考虑到当前团队的技术能力、学习能力，不能盲目追求最新最强的技术，拔苗助长容易害人害己。新技术栈的社区活跃度、维护团队的靠谱程度也很重要，如果你使用新的框架本身就有很多问题并且不能及时得到解决，那新技术带来的副作用远大于其提效的程度。
  • 项目脚手架
    • angular\vue\react等热门框架大多有配套的脚手架工具，开箱即用就好，但框架自带的脚手架为了更高的普适性和通用性往往比较简单，难以满足公司复杂业务的需要。
    • 小公司不建议开发自己的脚手架，因为小公司的项目本身就不具备通用性，往往朝令夕改差异化巨大，换个UI或产品就换一整套风格，费时费力开发一个脚手架却没有用武之地实在是得不偿失；虽然说收获了一定的前端基建经验，但是没有经过大量项目检验过的前端基建是不会又太大收获的。
    • 大公司一般都会开发自己的脚手架，用来保持前端工程UI库、代码风格、提交规范、公共组件库、错误上报等等的一致性，减低开发成本。这个时候更多是要注意通用性和易用性，在单个业务线的易用性非常好的脚手架往往在整个公司大前端来说通用性不会很好。如何通过传参配置平衡通用性和易用性才是需要考量的重点。
  • 代码组织结构
    • 一般来说单个项目会按模块水平拆分，按作用垂直拆分。比如在src/views文件夹下按订单列表、用户列表、部门列表水平拆分模块；在src文件夹下按api、routes、vuex、plugins、utils、views、components等分层垂直拆分。
    • 区块形式组织代码。为方便业务代码复用，在src下直接进行模块拆分，然后每个模块就是一个区块，包含此模块需要的api、routes、vuex、plugins、utils、views、components文件。区块形式组织代码的好处是一个业务模块的所有代码全部聚合在一个文件夹里，复用的时候直接copy这个文件夹即可。后期开发“前端资产平台”进行代码复用管理的时候可以很方便的按业务功能上传下载代码。副作用是新的代码组织形式会对开发人员带来心智负担，并且与旧项目代码组织形式不同难以相互复用。
    • monorepos 单一代码库相比于传统的 multirepos 来说简直太棒了。感兴趣的可以看看5分钟搞懂Monorepo
  • UI规范
    • CSS命名规范：BEM
    • CSS属性顺序规范
    • h5像素适配方案
    • 统一UI组件库
    • 公用业务UI组件库
  • 代码规范
    • eslint 规则强度: airbnb > standard > recommended
    • prettierrc
    • 设计模式 设计模式这样学也太简单了吧！
    • 一个项目的质量并不是取决于开发团队的上限，而是取决于某个开发者的下限，规范所有开发者的代码是提高项目质量性价比最高的方式之一
  • 提交规范
    • git commit规范
    <type>(<scope>): <subject>
<BLANK LINE>
<body> 
<BLANK LINE>
<footer>
    scope: commit 影响的范围, 比如: route, component, utils, build...
    subject: commit 的概述
    body: commit 具体修改内容, 可以分为多行.
    footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.
    • type: commit 的类型
    feat: 新功能、新特性
fix: 修改 bug
perf: 更改代码，以提高性能
refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
docs: 文档修改
style: 代码格式修改, 注意不是 css 修改（例如分号修改）
test: 测试用例新增、修改
build: 影响项目构建或依赖项修改
revert: 恢复上一次提交
ci: 持续集成相关文件修改
chore: 其他修改（不在上述类型中的修改）
release: 发布新版本
workflow: 工作流相关文件修改
  • 单元测试
    • TDD 测试驱动开发 先写测试再写代码 白盒测试 测试重点在代码。保证代码质量 测试覆盖率高 测试代码量大。适合工具库、框架、功能函数库。
    原理是在开发功能代码之前，先编写单元测试用例代码，通过测试来推动整个开发的进行。
setup（单个测试用例开始之前） 
suiteSetup（每一个测试用例开始之前） 
test（定义测试用例，并用断言库进行设置） 
teardown（单个测试用例开始之后） 
suiteTeardown（每一个测试用例开始之后）
    • BDD 行为驱动开发 先写代码再写测试 黑盒测试 测试重点在用户行为。保证交互无误 关注用户行为 覆盖率低 代码量小。适合业务代码、敏捷开发
    行为驱动的开发，描述了软件的行为过程，可以直接作为软件的需求文档。
beforeEach（每一个测试用例开始之前）
before（单个测试用例开始之前） 
it（定义测试用例，并用断言库进行设置） 
afterEach（每一个测试用例开始之后）
after（单个测试用例开始之后）
  • CICD
    • 通过jenkins等平台进行部署发布
    • 通过gitlab的cicd进行自动化部署发布

广义前端工程化

我所理解的广义前端工程化=需求任务拆分管理+前端资产平台+可视化搭建+狭义前端工程化+DevOps+性能监控+错误上报错误定位+Scrum敏捷开发。
可以参考下下面这些文章，我就不详细展开了

可视化搭建系统 从设计到架构，探索前端领域技术和业务价值
应用性能前端监控，字节跳动这些年经验都在这了
什么是scrum？
CICD到底是什么？十分钟理解DevOps

前端基建案例

  • 当你的视角从解决单个项目的痛点进行降本增效放大到如何解决整个大前端团队研发流程中的痛点进行降本增效时，你的身份就从前端开发工程师悄悄的转变为了前端架构师。
  • 而当你找到了一个痛点之后有该如何去将它进行标准化、规范化、工具化呢？可以参考下EasyDoc

EasyDoc

微医自研架构《EasyDoc》是我所在团队的一个非常完整的基建案例，你可以通过EasyDoc了解到一个完全自研的前端架构项目是如何产生的？如何实现的？如何推广的？如何管理的？...

试着用5W2H去完善你的基建项目

  • When时间 用户在什么时候会用这个产品或功能？
  • Where场所 用户在哪会用这个产品或功能？
  • Who人员 谁我们的用户群？产品或功能为谁设计？
  • What对象 用户可以用这个产品或功能能做什么？产品或功能为用户解决什么问题？
  • Why目的 用户为什么用你的产品，而不用别的？为什么需要这个功能？和其它产品的区别？
  • How方法 用户如何使用这个产品或功能？
  • How mach 需要多少资源？成本多少？
  • Value 这个产品的价值怎么样？
  • Data 这个产品的数据怎么样取得了什么结果

试着用产品思维灵魂8问去完善你的基建项目

  • 产品要解决什么问题？产品价值
  • 为谁解决这个问题？ 目标市场
  • 成功机会多大？ 市场规模
  • 怎样判断成功？ 结果
  • 有哪些同类产品？ 竞品
  • 为什么我们适合做这个产品？优势
  • 时机合适吗？ 机会
  • 如何推进？ 营销

今天的 [浅谈前端工程化] 就讲到这里吧

avatar
文章
阅读
粉丝