大厂技术 高级前端 Node进阶
点击上方 程序员成长指北，关注公众号
回复1，加入高级Node交流群「兄弟们可能有的感受」
感受一：入职 「初创公司」 或者成立 「新的团队」 而只有你一个前端，不知道从何做起。
感受二：「天天写业务代码和内部工具」，感觉没技术沉淀，成长太慢，然后发现架构那边挺有趣的。
感受三：对一些框架的原理、源码、工具 「研究较少，无法突破评级」，成为leader。
上面的感受都是一些兄弟们的典型感受（也包括我自己）。这时候不妨可以考虑一下，了解了解前端的基础建设，进而 「搭建起一个坚实的底座和让自己得到一个提升」
「正文开始——关于“基建”」
1.什么是基建？
“技术基建”，就是研发团队的「技术基础设施建设」，一个团队通用技术能力的沉淀。
小到文档规范，脚手架工具，大到工程化、各个领域工具链，凡是能促进业务效率、沟通成本都可以称作基建。
网上看到的一句话，说的很好， 「“业务支撑是活在当下，技术基建是活好未来”」 。
2.基建的意义
主要是为了以下几点：
「业务复用，提高效率：」 基建可以提高单个人的工作产出和工作效率，可以从代码层面解决一些普遍性和常用性的业务问题
「规范、优化流程制度：」 优异的流程制度必将带来正面的、积极的、有实效的业务支撑。
「更好面对未来业务发展：」 ，像建房子一样，好的地基可以建出万丈高楼。
「影响力建设、开源建设」：建设结果对于业务的促进，更容易获得内部合作方的认可；沉淀下来的好的经验，可以对外输出分享，也是对「影响力」的有力帮助。
「基建搞什么」
1.核心：
下手之前首先得记住总结出的核心概念：
「三个落地要素：」 公司的团队规模、公司的业务、团队水平。
「四大基础特性：」 技术的健全性、基建的稳定性、研发的效率性、业务的体验性
根据结合落地和基础特性，来搭建不同"重量"和"复杂度"的基建系统。（毕竟每个公司的情况都不同）
2.方向
基建开始之前，首先得确定建设的策略及步骤，主要是从 「拆解研发流程」 入手的：
一个基本的研发流程闭环一般是：需求导入 => 需求拆解 => 技术方案制定 => 本地编码 => 联调 => 自测优化 => 提测修复 Bug => 打包 => 部署 => 数据收集&分析复盘 => 迭代优化 。
在研发流程闭环中每一个环节的「阻塞点越少，研发效率就越高」。基建，就是从这些耽误研发时间的阻塞点入手，按照普遍性 + 高频的优先级标准，挨个突破。
3.搞什么
通用的公式是：「标准化 + 规范化 + 工具化 + 自动化」 ，能力完备后可以进一步提升到平台化 + 产品化。在方向上，主要是从下面的 「8 个主要方向」进行归类和建设，供大家参考：
「开发规范」：这一部分沉淀的是团队的标准化共识，标准化是团队有效协作的必备前提。
「研发流程：」 标准化流程直接影响上下游的协作分工和效率，优秀的流程能带来更专业的协作。
「工程管理：」 面向应用全生命周期的低成本管控，从应用的创建到本地环境配置到低代码搭建到打包部署。
「性能体验：」 自动化工具化的方式发现页面性能瓶颈，提供优化建议。
「安全防控：」 三方包依赖安全、代码合规性检查、安全风险检测等防控机制。
「统计监控：」 埋点方案、数据采集、数据分析、线上异常监控等。
「质量保障：」 自测 CheckList、单测、UI 自动化测试、链路自动化测试等。
如上是一般性前端基建的主要方向和分区，不论是 PC 端还是移动端，这些都是基础的建设点。业务阶段、团队能力的差异，体现在基建上，在于产出的「完整性」、「颗粒度」、「深入度」和「自动化」的覆盖范围。
4.大小公司基建重点
「小团队的现实问题」：考虑到现实，毕竟大多数前端团队不像大厂那样有丰富的团队人员配置，大多数还是很小的团队，小团队在实施基建时就不可避免的遇到很现实的阻力：
最大的阻力应该就是 「受限于团队规模小」 ，无法投入较多精力处理作用于直接业务以外的事情
其次应该是团队内部 「对于基建的必要性和积极性认识不够」 （够用就行的思想）
「大小公司基建重点：」
「小公司：」 针对一些小团队或者说偏初创期的团队，其建设，往往越偏向于基础的「技术收益」，如「脚手架」、「组件库」、「打包部署工具」等；优先级应该排好，推荐初创公司和小团队成立优先搭建好：规范文档、统一开发环境技术栈/方法/工具、项目模板、CI/CD流程 ，把基础的闭环优先搭建起来。
「大公司：」 越是成熟的业务和成熟沉淀的团队，其建设会越偏向于获取更多的「业务收益」，如直接服务于业务的系统，技术提效的同时更能直接带来业务收益。搭建起一套坚实的项目底座，能够更好的支持上层建筑的发展，同时也能够提升团队的成长，打开在业界的知名度，获取更好的信任支持。大公司在基础建设上，会更加考虑「数据一些监控以及数据的埋点分析和统计」，更加的偏重于「数据的安全防范」，做到质量保证。对于这点，很多前端需要写许多的「测试case」，有些人感觉很折磨，哈哈哈哈哈哈。
「基建怎么搞」
下面，会针对一些大家都感兴趣的方向，结合自身过去部分的建设产出和一些文章的记录的整合（部分地方可能比较久远的，有些不记得出处。如有冒犯，深感抱歉，可与我联系！），为大家列举一些前端基建类的沉淀，以供参考。
「1. 规范&文档」
规范和文档是最应该「先行」的，规范意味着「标准」，是团队的共识，是沟通协作的基础。
「文档：」
新人文档（公司、业务、团队、流程等）
技术文档、
业务文档、
项目文档（旧的、新的）
计划文档（月度、季度、年度）
技术分享交流会文档
「规范：」
「项目目录规范」：比如api，组件，页面，路由，hooks，store等
「代码书写规范」：组件结构、接口（定义好参数类型和响应数据类型）、事件、工具约束代码规范、代码规范、git提交规范
「2. 脚手架」
开发和维护一个通用的脚手架工具，可以帮助团队「快速初始化项目结构、配置构建工具、集成常用的开发依赖」等。
省事的可能直接拥抱框架选型对应的全家桶，如 Vue 全家桶，或者用 Webpack 撸一个脚手架。能力多一些的会再为脚手架提供一些插件服务，如 Lint 或者 Mock。从简单的一个本地脚手架，到复杂的一个工程化套件系统。
「3. 组件」
公司项目多了会有很多公共的组件，可以抽离出来，方便自身和其他项目复用，一般可以分为以下几种组件：
「UI组件」：antd、element、vant、uview...
「业务组件」：表单、表格、搜索...
「功能组件」：上拉刷新，滚动到底部加载更多，虚拟滚动，拖拽排序，图片懒加载..
「4. 工具 / 函数库」
前端工具库，如 axios、loadsh、Day.js、moment.js、big.js 等等（太多太多，记不得了）
常见的 方法 / API封装：query参数解析、device设备解析、环境区分、localStorage封装、Day日期格式封装、Thousands千分位格式化、防抖、节流、数组去重、数组扁平化、排序、判断类型等常用的「方法」和「hooks」抽离出来组成「函数库」，方便在各个项目中使用
「5. 模板」
可以提前根据公司的业务需求，封装出各个端对应通用开发模版，封装好项目目录结构，接口请求，状态管理，代码规范，git规范钩子，页面适配，权限，本地存储管理等等，来减少开发新项目时前期准备工作时间，也能更好的统一公司整体的代码规范。
通用「后台管理」系统基础模版封装
通用「小程序」基础模版封装
通用「h5」端基础模版封装
通用「node」端基础模版封装
其他类型的项目默认模版封装，减少重复工作。
「6. API管理 / BFF」
推荐直接使用「axios」封装或「fetch」，项目中基于次做二次封装，只关注和项目有关的逻辑，不关注请求的实现逻辑。在请求异常的时候不返回 Promise.reject() ，而是返回一个对象，只是code改为异常状态的 code，这样在页面中使用时，不用用 try/catch 包裹，只用 if 判断 code 是否正确就可以。再在规定的目录结构、固定的格式导出和导入。
「BFF」（Backends For Frontends）主要将后端复杂的微服务，聚合成对各种不同用户端（无线/Web/H5/第三方等）友好和统一的API；
「7. CI/CD 构建部署」
前端具备自己的构建部署系统，便于专业化方面更好的流程控制。很多公司目前，都实现了「云打包、云检测和自动化部署」，每次 git commit 代码后，都会自动的为你部署项目至 测试环境、预生产环境、生产环境，不用你每次手动的去打包后 cv 到多个服务器和环境。开发新的独立系统之初，也会希望能实现一种 Flow 的流式机制，以便实现代码的合规性静态检测能力。如果可以的话，可以去实现了一套插件化机制，可以按需配置不同的检测项，如某检测项检测不通过，最终会阻塞发布流程。
「8. 数据埋点与分析」
前端团队可以做的是 Web 数据埋点收集和数据分析、可视化相关的全系统建设。可实现埋点规范、埋点 SDK、数据收集及分析、PV/UV、链路分析、转化分析、用户画像、可视化热图、坑位粒度数据透出等数据化能力，下面给大家细分一些这些数据：
行为数据：时间、地点、人物、交互、交互的内容；
质量数据：浏览器加载情况、错误异常等；
环境数据：浏览器相关的元数据以及地理、运营商等；
运营数据：PV、UV、转化率、留存率（很直观的数据）；
9.微前端
将您的大型前端应用拆分为多个小型前端应用，这样每个小型前端应用都有自己的仓库，可以专注于单一的某个功能；也可再聚合成有各个应用组成的一个平台，而各个应用使用的技术栈可以不同，也就是可以将不同技术栈的项目给整合到一块。这点就很不错，在如今电子办公化如此细致的时代，可能许多公司工作中都不止一个平台，平台之间的切换十分的繁琐，这时候「平台之间聚合的趋势想来是必然的」。（个人浅显的理解）
目前成熟一点的框架有蛮多的，使用的底层思想也各有不同，目前我也在学习qiankun等框架中，期待后面能够给大家分享一篇文章，加油💪
「基建之外思考」
「1. 从当下业务场景出发」
很多时候我们的建设推不下去，往往不是因为人力的问题，而是 「没想清楚/没有方向」 。对于研发同学，我们更应该着重于当下，从方案出发找实际场景的问题，也就是从我们项目和团队「目前的业务问题、人员问题，一步步出发」。还有就是，我们得开这个头。没有一个作家是看小说看成的，同理技术专家也不会是通过看技术书籍养成的。在实践中也就是实际场景中学习，从来都是最快的方式。许多有价值的事从来都是从业务本身的问题出发。到头来你会发现：「问题就是机会，问题就是长萝卜的坑」。
2.基建讲究循序渐进
业界大部分的研发团队，都不是阿里、腾讯、头条这样基础完备沉淀丰富的情况，起步期和快速爬坡期居多，建设滞后。体现在基建上，可能往往只有一个基于 Webpack 搞搞的脚手架，和一个第三方开源的 UI 组件库上封装下自己的业务组件库，除此之外无他。如果兄弟们现在恰好是我说的这种情况，不用焦虑，很多前端也是一样的情况。只要我们「一步步建设，慢慢落地基础设施，就一定会取得好的反馈」。
3. 技术的价值，在于解决业务问题，并且匹配
「技术的价值，在于解决业务问题；人的身价，在于解决问题的能力」。
基建的内容我认为首先是 「和业务阶段相匹配」 的。不同团队服务的业务阶段不同，基建的内容和广深度也会不同。高下之分不在于多寡，而在于对业务的理解和支持程度。
“业务支撑” 和 “基础建设” 都是同一件事的两个面，这个 “同一件事”，就是帮助业务解决问题。任何脱离解决实际场景而发起的基建，都需要重新审视甚至不应被鼓励。如果时间成本没有那么多的话，建议先搭建好基本的建设底座，想要更好的闭环的想法还是先搁置一下。
4.个人不足
总结了这么多，结果发现自己对于一些知识点还是了解的太浅显了，自身在那些方面能分享的还是不多，平时也看了一些文章记录了一些笔记，却只能描出个大概，实在是有点不好意思。但回头想想，这何尝也不算个勉励自己的方法，能够鞭策自己。
Node 社群
我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。
“分享、点赞、在看” 支持一下
1029
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
