前言
随着业务越来越重，越来越复杂，双倍工作量，团队规模肯定不会扩大双倍，蛮力已经无法持续高效的支持业务，如何因地制宜地打造出适合自己的前端工程化，成了每个到了一定规模的前端团队都在思考和探索的问题。但在没有研究出合适的方案时，不能盲目地去追求工程化，为了工程化而工程化，浪费人力投入的同时，也会削减自己前进的动力。
会遇到什么问题
-
新旧项目交织，存在各种技术栈，同一UI风格，基础组件没法复用，难以统一管理
-
成员间水平各异，编写代码的风格和使用的技术栈各不相同
-
不同项目Webpack配置差异过大，基础工具函数库和请求封装不一样
-
缺少代码注释、项目文档，commit信息格式不统一，新人接手困难，旧项目难以维护
-
解决方案缺乏沉淀，不同人遇到同一业务场景，需要重复采坑
-
一个人独立负责一个项目，一离职，交接成本会比较高
-
UI缺少统一组件、接口格式不统一
…
需要先做什么
一、统一规范
统一的规范可以降低维护成本，助于团队协作，同时养成良好的代码规范，也有助于自身的成长。
1.代码规范-ESLint
- 常见的风格有airbnb、google、standard、prettier
- 根据文档配置出适合自己公司风格的
2.git 规范
- 分支管理规范
- commit 规范
3.项目文档规范
- 标准化Readme格式
- 写清楚项目说明、环境依赖、启动命令、部署方式、目录结构、技术栈、问题说明等
二、技术选型
前端一直都在讨(zheng)论的话题，三大框架vue、react、angular，如何选其一，中小团队，可以简单粗暴点根据以下特点来判断：
- 高效、成熟、生态丰富
- 当前团队人员最熟悉的
- 市场占有率高的
三、统一物料
1.脚手架
- 统一配置
- 统一项目结构
- 集成基础框架、组件库、方法库、工具
2.公共组件
- 对可复用的功能、业务组件化
- 统一组件开发规范
- 组件库的管理
3.公共UI
- 和设计师沟通，制定统一的UI标准
- 使用统一的组件库
4.工具函数库
- 统一使用的工具库，如日期处理、加密、ajax请求、可视化等
- 轻量的自己写，较复杂的用开源或者根据团队精力去安排开发
5.CI/CD
- 云打包
- 云检测
- 自动化部署
四、统一协作工具
1.日常沟通（微信、钉钉等）
2.需求管理（Jira、禅道、teambition、TAPD等，或者在线Excel）
3.接口文档（RAP、eolinker、swagger、YAPI等）
未来
1.单元测试
-
对一个函数、一个组件做测试
-
TDD开发模式是否适用当前场景
2.埋点与分析
- 性能监控（白屏时间、页面加载耗时、DOM渲染耗时、资源加载耗时等）
- 错误监控（资源加载错误、js执行错误、promise错误）
- 信息收集（UV、PV、停留时间、操作记录等）
3.丰富规范
4.本地开发环境工程化
5.模块化业务
6.可视化系统
…
那么，什么是前端工程化
一切以提升前端开发效率，降低前端开发成本，提高前端应用质量为目标的工作都是前端工程化。小到一个方法一个组件一个标准，大到一个工具一个框架一个平台，都是工程化之路，不要因为小而忽略，也不要因为大而盲目追求。工程化是和公司业务阶段相匹配的。不同的业务阶段，内容和广深度也会不同。公司可分为初创期、生存期、快速发展期、成熟期、大成期。每个阶段需要适配不同的工程化程度。
结语
本次主要分享了整体的框架，每个环节都有很多需要深入探索的东西，下次有机会分享单个环节怎么去深挖细化，希望大家能跳出舒适区，一起努力推动自己、团队、公司的进步。技术的价值，在于解决业务问题；人的身价，在于解决问题的能力。诸君共勉。同时，我司前端团队正在探索和打造适合自己的前端工程化，如果你想和我们一起进步，欢迎加入我们。
标签：极客,前端,规范,组件,工程化,团队,星球,统一 来源： https://blog.csdn.net/apkkkk/article/details/121959102
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。