小微团队在前端工程化方向的一些探索

本文主要是介绍小微团队在前端工程化方向的一些探索，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

谈及工程化，大部分团队或许都经历过从无到有、从有到优的实践，在此浅谈我们在前端的一些工程化探索。

一、前世今生

在早期IT行业，Web系统的表现层严格遵循HTML标准，但HTML具有标记语言的局限性，为提高编码效率，业内出现了从Java、PHP、Python等高级语言到HTML模板的动态转译框架[1]，这促使产生了前后端分离的职责分工：一些人编写模板、样式、脚本，另一些人编写业务逻辑。高级语言使用一些复杂特性操纵表现层，即使在今天，大多数系统的技术图谱中，表现层技术都只能占据薄薄的一个尖端，冰山之下则是庞大的、复杂的服务端技术。最近十多年，由于芯片、网络、存储的速度大幅提高，直接推动了Web相关标准的快速演进，一个典型证据是：早期百度搜索需要加载的资源不到10KB，如今已经达到920KB[2]。支撑这接近100倍资源增长的，是ECMAScript、JSON、HTML5/CSS3的标准化。而在标准之外，仅为了实现JavaScript的模块化，即高级语言的import、include语法，国内外就有不下20种方案[3]！为了管理这些表现层的技术，以及在日益复杂的技术栈中解脱出来，以Facebook、淘宝为代表的年轻公司，开始了前端工程化的探索，并创造了一系列衍生技术，这些技术有些被纳入标准，有些被作为最佳实践，得到了业界广泛的追随。

二、最佳实践

在动手操作以前，我们必须认识到：脱离自身真实的场景，就无法衡量某种实践是否“最佳”。我们并非是要复制那些头部公司的工程化方案，而是要挖掘并解决项目开发中急需解决的问题、感到折磨和无力的痛点，工程化这个方向恰好是最关键的切入点，也是我们能够控制的因素中最容易做出改变的、更能引起质变的因素。
我们有哪些痛点？归纳为以下：
一是不可控因素导致的人员水平未形成梯队，我们深度依赖外部人力资源[4]，大家的工作目标不完全一致，导致前期沟通成本、后期维护成本等隐性成本巨大。这些看不见的、不在账面上的成本往往被忽视。
二是工作方法陷入资源池模式，以人力维度进行资源调度。长此以往，项目需求无休止的袭来，人力资源看似得到充分利用，但实际上程序员的创造性被压制，业绩上限也就只能线性增长，而创造性工作[5]带来的增长可能是指数级的，即便是最微小的创新，也能在线性增长时带来更大的斜率。
这两个问题看起来不像是工程化问题，但其他的表层问题基本都由前两点引起，如：
技术栈虽然统一，但互相觉得对方的代码不敢改、难复用，缺少架构设计，代码质量方差较大，涉及编码规范、代码风格、技术评审；
内部框架学习成本高，文档有疏漏、不完整、API和实现不一致，熟悉开源框架，反而在使用内部框架时产生心智负担，涉及文档规范、软件分发机制、技术分享；
重复造轮子，外向程序员可能会在群里吼一句：XXX功能你们有人做过吗？多数内向程序员会用最短的时间，以最快的速度，写个轮子出来。因为自己写个轮子甚至比用别人的轮子要快很多且更放心，涉及组件库、公共仓库、资源管理平台；
重开发、轻运营，项目做完就交差，某一天突然被拉进一个群，名为“XXX缺陷修复沟通群”，在代码堆中翻来翻去终于找到问题，发现提交的人已经不在了，涉及backup机制、异常监控、owner意识；
这些问题就像是工程化问题了。

三、实践历程

一旦想清楚问题究竟是什么，找到答案就只是时间问题了。以下我从技术角度，用问答的形式描述工程化落地的一些实践和思考。
关于编码规范
Q：建立编码规范几乎是人人都会做的事情，但如何落实？你怎么保证别人的代码符合你的规范？他愿意遵守吗？他有没有措施可以绕过或欺骗你的规则？
A：编码规范无非是一个PDF或Confluence资源，没有任何约束力；Code Review的沟通成本太高。我们做的方案包括把规范具化到每一个项目的配置文件中，最终目标是结合IDE插件，可以在编码时就实时产生约束；现在已经实现了在Git提交前，检查增量代码的规范性，不符合规范的代码会抛出异常停止提交，经过这种强约束介入，可以大幅减少人工Code Review的时间。
Q：已有的项目怎么集成编码规范的配置文件呢？就算集成了，怎么保证配置不被篡改呢？
A：既然有人会篡改，比如把ESLint的规则全部注释掉，那么就说明这个规范本身有问题。我们提供了一个命令行工具，在仓库根目录执行，可以把一份公共的、由全体开发人员共同维护的配置文件加载到项目中，完成初始化。随着规范的演进，这个配置文件也可以通过命令行工具进行更新。
关于文档规范
Q：文档先于代码。但是随着版本迭代，文档逐渐跟不上代码变化的速度了，写代码5分钟，更新文档要10分钟，怎么高效维护文档？
A：首先我们拒绝Word、PDF这些静态的、无法保持更新的文档工具，其次也不会使用Confluence这种在线协同文档，你一定会花费大量的时间来调整文档样式。最适合技术文档的工具是Markdown，重视内容，也有不错的可读性，更重要的是，它支持（绝大多数）HTML语法，这意味着你的文档不是一堆干巴巴的功能描述，而是一个动态的、可以体验的、甚至可以在线调试的DEMO。有很多开源文档工具，我们选择了VuePress[6]，它包含以上所有优点，并且原生支持Vue组件。你的库发布新版本了，VuePress构建文档时也会更新依赖，你的DEMO也就自动更新了，因此只要编写Markdown的API描述就可以了。
Q：内部框架如何持续更新？如何保证项目使用合适的版本？
A：文档规范很难像编码规范采取类似的硬性措施，因为写文档、写框架更多的是出于程序员自发的技术热情，但这少数人的技术热情可以带动整体的技术氛围，通过技术交流、分享等方式，可以影响更多人参与其中，这比规范的文档更有效。对于使用者来说，NPM版本号应该使用“~”前缀来确保依赖自动升级。我们的项目在上线之前，都会通过package-lock.json[7]对所有依赖进行版本锁定，保证集成测试环境和生产环境的依赖版本一致。
关于公共资源
Q：有经验的程序员都会写一些公共方法、通用类，放到公共目录下或发布为依赖库，但为什么还会重复造轮子呢？
A：前端代码往往是和业务需求紧密结合的，一个代码工程就是一个业务系统，所有代码都是为了这个业务系统而专门编写的。所以你会看到每个工程都有网络库配置、UI库配置，且配置有细微的不同，提取公共部分作为依赖库会缺乏灵活性，没有哪个公共库可以支撑未来的需求变化，索性复制一套已有的配置再删改，但人工删改容易出错。这就体现了Code Snippet的作用，我们的目标是搭建一个资源管理后台，其中一个模块可以维护常用代码片段，通过评审发布的代码片段需要有详细的使用说明、注释。这样就算是造轮子，也是按照一个模具来造的，可能只是“轮毂”不一样，可维护性更好。
Q：如何保证组件库的质量？我想优化别人写的组件怎么做？我怎么知道某个功能有没有人实现过？
A：能够抽象到公共组件库中的功能，应当至少有两个以上项目使用到，否则没有意义。由于有多个项目正在使用，组件的代码质量自然就得到了验证和保证。对于公共函数，例如深拷贝、大数转换、树的遍历，还需要写单元测试。每个组件库除了有规范的文档外，还要登记到资源管理后台，并维护每个具体业务组件的版本号、开发人员，资源信息做到公开可检索。
关于项目维护
Q：项目如何做到长期维护？如何降低维护成本？
A：根据代码托管平台的统计，大多数项目每迭代一段时间就到了不得不整体重构的地步，甚至有些著名项目会因为难以重构而停止维护，这其中并不都是因为代码写的烂，而是后来的人对先前的业务逻辑不了解。我们的内部项目也如此，程序员不可能一直维护一个项目，当第三方依赖更新、被混入恶意代码、出现偶发Bug，就要付出成本去维护，我们能做的只有将维护成本减到最低：backup机制。类似于离职时的工作交接，保证任何一个模块任意时刻都有至少两个人懂具体逻辑。我们有很多小项目都是由单人独立负责的，这种情况可以通过代码Review来促进其他人对这个项目的了解，可以采取轮换方式，定期的刻意互换项目来做，短期对个体而言付出一些学习成本，但长期对整体而言是更稳健的。
Q：很多项目在生产环境的问题，其他环境难以调试，只能借用户的账号上去调试？
A：我们在逐步引入一个统一的开源监控插件，它可以采集每个页面的行为日志，基于组件树信息提供用户操作的回放，这样就避免用户描述复现步骤，再去根据报错的函数调用栈推测问题了。同时监控后台可以列出各个项目的性能指标、执行情况、报错数量，让每个人了解所负责的项目究竟在线上是什么样的，这些指标在业界平均水平是多少[8]，都可以量化出来。

四、结语
前端工程化还有很多高级的话题，如低代码、智能化，我们仅仅思考和改善了一些目前最迫切的痛点，最重要的是，我们试图找到自己的节奏，让项目需求融入到我们的步伐中。

参考链接：
[1]. 浅谈JSP：https://zhuanlan.zhihu.com/p/42343690
[2]. 收录过去的网站：http://www.wayback.com/
[3]. JavaScript的模块：https://www.ruanyifeng.com/blog/2012/10/javascript_module.html
[4]. 银行业IT服务外包：https://wenku.baidu.com/view/8222d3e8541810a6f524ccbff121dd36a32dc47e.html
[5].《黑客与画家》：https://book.douban.com/subject/6021440/
[6]. https://vuepress.vuejs.org/zh/
[7]. https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json/
[8]. https://developer.mozilla.org/zh-CN/docs/Web/Performance

这篇关于小微团队在前端工程化方向的一些探索的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！