前端工程 - 什么是前端工程管理?

在写这篇文章之前, 一直有个问题困扰着我, 什么是前端工程管理? 当我作为面试官和一些候选人聊这个话题的时候, 我得到的答案五花八门, 比如谈目录规范, 编码规范, 做个脚手架, 增加单元测试, CodeReview 等等, 我的直觉告诉我这些和前端工程管理有关系, 但这些一定不是前端工程管理的本质, 但是当我们理不清本质的时候, 可以试着从实施手段去逆向思维, 同时再借着概念正推. 放张图

正文

从实施手段看前端工程管理

从前端工程化提出到现在差不多有好几年的光景, 在这段时间前端生态发展出非常多的针对前端工程管理的工具和手段, 我将这些统称为实施手段, 比如 grant gulp 和直接使用 npm script 实现流程管理, 通过 webpack rollup snowpack 实现构建, 用 npm 等来管理代码, 用 crate-react-app 和 vue-cli 和一堆自定义脚手架来管理目录, 用 eslint 来试试编码规范, 用 jest 等来做代码测试, 我们可以做个分类

• 流程管理

• 代码管理

• 质量管理

  • 单元测试

  • 集成测试

• 规范管理

  • 目录规范

  • 编码规范

  • 命名规范

  • ...其他规范

• 构建管理

然后大家会发现一个很有意思的现象, 可能也是整个技术史上仅有的

任何一个分类下, 都有数不清的轮子, 已知的三四五六个, 未知的成千上百, 另外这里所有的分类都离不开一个核心工具 Nodejs, 所以说 Nodejs 的诞生是前端工程化最初的那个点, 并不为过.

乍看之下前端工程管理手段之丰富, 社区之繁荣, 让相邻的什么后端, 移动端相形见绌, 但是作为这段历史的亲历者, 包括作为一名前端工程师, 我并不为此感到自豪, 反而有点上头, 因为 我们有如此多优秀的工具和繁荣的社区, 优秀的工程师, 却依然让我们的前端工程看起来一团糟

我相信无论你是否连续几年待在一家公司还是跟蚂蚱一样跳来跳去都会发现一些相同的或者类似的问题

• Gitlab 上工程多如牛毛, 命名混乱(2020了, 如果你所在的团队都没用 Git 管理代码, 那我觉得你的职业生涯可能要终结了)

• 工程内目录就像川剧脸谱, 大家都在玩变脸游戏

• 打包构建项目流程从三方到自研, 反正没有一个是能对齐的

• 编码规范还在讨论到底是 4个空格 还是 2个空格的问题, 要不要加; 函数名后面到底要不要留空格

• 代码测试? 不存在的, 永远都在写, 永远写不完, 永远用不上

• 命名规范, 这个我们能开个会讨论一下午

有意思的是大部分的前端技术团队就像得了阿尔兹海默症的老人一样, 上面的事情翻来覆去的搞一遍又一遍

就光编码规范这件事, 我几乎每去一家公司都要重新来一遍, 7年了我还在参与关于到底是用 Tab 还是用 空格 来缩进的讨论, 可能我也得了阿尔兹海默症吧 😑

为了治好自己, 我开始思考为什么会这样? 这让我想起了战国时期的百家争鸣, 以及后来的秦的统一. 熟悉战国史的同学应该知道, 战国时期为了讨论怎么治理国家是对的, 或者说如何治理国家才能让国家强大, 诞生了无数的思想派别, 这些思想家四处游说和宣讲他们的治国理念, 有意思的是因为这种乱糟糟的局面反而让周朝延续了几百年, 因为谁也不能说服谁, 彼此就维持了微妙的平衡, 直到秦国出现以武力打破这种局面, 同时也为中国后来的封建文化的繁荣打下了基础.

可以这么说, 如果没有秦朝对很多治理手段和治理思想的统一就不可能管理如此庞大的中国, 如果把当前前端工程化的各种实施手段看成是战国时期的治理手段, 那我们此时差不多处于战国的中期, 小轮子诞生速度开始下降, 中大轮子形成了自己的稳固生态, 继续积蓄力量, 迎接最后一战

有人可能担心技术上统一之后会降低生态的创新能力, 不会发展了, 其实我觉得这要从两个方面看, 如果是从务实的角度看, 技术统一对技术运用, 尤其是工程管理方面的理论和方法的推动是非常有价值的, 也可以让整个技术生态更趋于成熟, 但如果你说的是完全不同的新的方法新的思维, 那一定是会产生打压的, 对于一个成熟的技术生态来讲, 轮子减少也是说明生态变得厚重了不是谁都可以随随便便搞创新了, 提高创新门槛, 发展有质量的技术创新我觉得对整个前端生态来讲也是好事. 另外从实际情况来看, 前端生态的轮子制造速度正在下降, 这也是我将其类比为战国中期的原因

从实施手段我们是无法看清楚什么是前端工程管理, 因为太多太乱, 但是通过这些实施手段的分类我们看到了一些前端工程管理上的方向, 让我们朝着我们想要了解的东西进了一步, 这时候我们停下来, 放一放, 从另一个角度再看看

从通用概念来看前端工程管理

这里的通用概念其实就是把前端去掉, 我们看看现有的工程管理都是怎么做的, 我们经常把软件工程, 软件架构类比到建筑行业, 因为其实很多概念也都是来自建筑行业, 如果把计算机比作数字世界的挖掘机, 制造机器, 建筑行业是对现实世界的模拟和改造, 那软件工程就是对数字世界的模拟和改造, 两者在本质上都是对我们所认知的世界进行模拟和改造, 所以是相通的, 当我们理不清的时候看看发展了几千年的建筑行业往往能得到不少启发.

拆解工程管理概念

我家今年门口的高架不知道能不能造完, 作为基建狂魔, 中国在工程管理上是很有一套方法的, 当我在观察这些工程在实施管理的时候, 作为外行人的我也能发现很多有意思的东西, 比如这里的管理其实包含两层意思 管控和治理 一个工程会有很多人参加, 有各种工人, 设计师, 监理, 不同的周期内又有各种流程, 从投标到交付, 中间还有很多机构分工, 设计单位, 规划单位等等如果没有一套有效灵活的管控和治理手段是很难将一个工程做起来的, 同时交付之后还有物业管理, 装修和维护等等, 一个工程从诞生到最终被拆掉其中的流程和参与的人和单位非常的多和复杂, 工程的负责单位也在变化, 但是都离不开两大类手段, 管控和治理. 你需要管控风险, 但是风险是客观存在的, 因为中间有人的参与一定会有各种偏差和错误的产生, 所以你需要持续的治理, 像我上班开车, 现在的高架工程外围都会持续喷水, 降低扬尘, 这些都是因为我们改变了环境带来的问题, 不治理, 那你这个工程可能影响到其他工程, 甚至整个环境.

我将这些观察和我们的前端工程管理做了个对比, 发现我们其实忽略了非常多对我们的前端工程有影响的元素, 而也是因为这些被忽略的元素导致了我们即使有这么丰富的工具也无法有效的进行前端工程管理, 比如

• 我们很少关心对我们工程有影响的人

  • 项目经理

  • 产品经理

  • 测试人员

  • 后端, 移动端等其他工程相关的非前端职能的开发者

  • UI 设计师等

• 我们一直在一个理想环境中管理我们的工程, 在这个而理想环境下一切都是围绕前端展开的

• 我们更关注工程的创建过程, 而不关心如何治理让工程保持健康, 这导致很多前端工程师在写代码上其实没什么原则性

  • 项目紧, 随便写下吧

  • 服务端风险大, 我写吧

  • 算了算了不想了, 就这么写吧

  • 上任写的是屎, 还是这么写吧

  • 上任都写成屎了, 改起来风险太大, 我继续这么写吧.

因此对于前端工程管理, 我们不仅要考虑前端工程内部的实施手段, 同样要研究工程参与者的管控方法和工程本身的治理策略

把两者结合起来看

当我们把正向和逆向推导出来的内容结合起来看, 我们可以得到一个更加接近前端工程管理本质的概念分类, 包括外部和内部两部分

• 前端工程管理
  • 外部管理

    • 需求管理 (管控和治理来自需求侧对工程的影响)

    • 调用管理 (管控和治理来自不同工程, 例如后端, 移动端, 其他前端等对工程的影响)

      • 客户端调用管理

      • 服务端调用管理

      • 其他端调用管理

      • 二方库/组件调用管理

      • 三方库/组件调用管理

    • 开放接口管理 (管理工程输出给外部的接口)

  • 内部管理

    • 流程管理

    • 代码管理

    • 质量管理

      • 单元测试

      • 集成测试

    • 规范管理

      • 目录规范

      • 编码规范

      • 命名规范

      • ...其他规范

    • 构建管理

通过观察和思考, 我认为我们可能在内部管理上用力过猛, 并且执着于实施手段而忽略如何沉淀理论基础, 因此在概念上形成了碎片化的认知和理解, 加上开发者的高流动性进一步加剧了这种管理困境, 其次在外部管理上我们几乎丧失了关注, 仅凭经验办事

因为这种发展模式导致了我们在前端工程管理上的困难, 因为大量的不统一和对某些关键部分的关注力丧失, 让我们不得不一次又一次的疲于应对相同的工程管理上的问题, 又因我们缺少方法论, 只懂如何使用实施手段, 但又不理解为什么这么做, 加上选择困难症, 面对同一类问题不知道采取哪种实施手段更有效, 总之一个字 难!!!

后话

在我之前的文章中我批过大前端更像个垃圾厂, 在这里我想进一步指出, 大前端这个概念是我们没有认识到前端工程外部管理的重要性, 同时又想解决我们和相邻端在集成和调用上导致的工程管理困境, 在没有办法下想出的办法, 那就是把外部问题转换成内部问题, 服务端也是我们, 移动端也是我们, 诶这下总没问题了, 我可以用各种实施手段治他们, 让他们服服帖帖的.

因此我更觉得当下这种大前端的理念行不通, 因为我们在工程内部管理上并没有达成一致, 匆忙将外部问题转换成内部问题反而会加剧内部问题的管理混乱, 俗话说打铁还需自身硬, 要实现大前端一体化, 前端还需要自己先理清楚前端领域的工程该怎么管理, 再去考虑横向的拓展, 扩大前端工程的职能边界

单体工程也好, 微前端也好, 这些都是前端工程管理的实施手段, 手段再好但是如果我们对前端工程管理这件事各执一词, 凭经验理解就好比战国时期的百家争鸣, 看着热闹却不务实, 反而会因为理念上的差异加剧实施手段上的分裂(同样的微前端模式在不同公司玩出了花), 仔细数数搞微前端的也有很多种了吧. 如今 webpack5 即将发布, 大家又可以造一波轮子了.

写到这里我不免想起谷歌的技术战略, 无论是 Go 还是 Dart, 都像是一个外来者对原有体系的强力冲击, 凭借的是强大的经济实力(Chrome浏览器的绝对份额和谷歌自身的强大), 另起炉灶抛弃历史包袱提供更好的开发体验, 就像战国时的秦军改革一样, 但最终结局如何, 还得拭目以待.