业界开发模式与效率提升的探索

加入新公司一月有余。作为一家初创公司，在我看来，其虽然技术能力不错，但前端的基础架构相对薄弱，开发模式也有可提升之处。经历过一个大的迭代之后，一直在思考效率提升的方案，与老大粗聊几次，也算有些收获。以此文记录，也作整理思路之用。

背景

产品与开发模式

公司目前的主要产品是一款 windows 端的渲染器，为实现更好的视觉效果，上层选择采用了前端技术来搭建界面。由于技术栈的隔离，开发天然的划分为两部分：客户端与前端开发。前端与客户端通过Qt WebChannel来连接。开发模式类似与前后端分离。后续即以前后端分离代表这种开发模式。前后端代表前端与客户端。

问题

公司在开发上的问题主要集中在下面几点：

  1. 前端流动性较高：为保证代码质量，倾向技术能力较强的中短期前端开发（如有大厂能力的实习生），而不倾向技术能力一般的稳定前端开发；
  2. 业务的学习成本较高：在前后端均有业务逻辑的情况下，前端无法将客户端发送的信息视为黑盒直接使用，造成了前端需要逐步学习业务知识。
  3. 前后端开发分离：前后端开发分离的问题大家应该都有耳闻，前后端联调是一个比较困难的过程，尤其是在公司：
    • 缺少 Test Case
    • 客户端编译出包时间较长
    • 创业对于出版本时间的要求较高
      —— 造成造成即使是一个小 bug，如果前后一方没做到位，也需要大量的调试时间。

可以看出，1, 2 两点是冲突的也是必要的，需要投入更大的人员成本才有机会将其解决。很遗憾，现阶段并没有合适的人选。而第三点，就是本文讨论的重点，如何对其优化以带来效率上的提升。

一些探索

成熟的研发体系总会对这样的痛点做适合他们的一些探索，前后端是一个长久以来一直存在的问题，那么首先，为什么要有前后端分离？

前后端分离

我们知道原始的前端和 view 层是一致的，切图、写页面、写交互、把写好的页面交给后台，后台将其作为模板提供成可插入数据的页面。这样的开发模式为什么要慢慢转变成前后端分离开发？有人将其解释为耦合，下面我谈谈读过一些资料后我的理解：

第一点，串行开发：后台需要等待前端提供模板之后才能进行开发，功能如需进行调整，整个过程是漫长的。

第二点，先提一下康威定律：设计系统的组织，其设计受制于组织间的通信结构

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
按照phodal的话说，就是部门大了需要拆分。

那么如何拆？通过技术栈拆成前后端看起来是一种方式。

第三点，多端客户端的产生：随着手机端的盛行，对于一个功能，已经不止是为电脑服务的 web 前端要用到，手机 web 端，手机 app 甚至一些特殊设备都要用到。有一套后台 REST 接口便可以支持多端运行，很明显是一件提升效率的事情。

前后端真的分离了？

前后端是否分离取决于前后端的知识上下文是否分离，也就是前后是否彼此互为黑盒，只要定义好接口，之间的沟通就可以尽可能的少很明显，只是拆成前后端，但是没有保证前后端分离，也就没有做到前后端分离，反而会增加沟通成本，

为此，业界基于一致的“接口”，有很多优秀的实践：

  1. 契约测试（Pact 等）：保证变化的 api 的正确性。
  2. 数据结构生成器（swagger 等）：保证前后端接口元信息的一致性。
  3. 一些分锅工具（log 分析等）：迅速准确定位定界。
  4. ci/cd：前后端分别独立构建发布，保证前后端版本的分离。

业界实践

业界根据业务模式，可以分成三种：

前端主导

  1. BFF(Backends For Frontends)
  2. serverless

后台主导

前端模式化

  • 前端可视化编辑器
  • 前端组件化

全功能团队

端到端的领域模型 -> 端到端开发

一些设想

成熟的研发体系总会对这样的痛点做适合他们的一些探索，

技术与业务

理想

我理想中的开发模式应该是这样的：

  1. 明确的领域模型
  2. 前端负责视图组件开发
  3. 后台负责逻辑开发

现实

客户端对前端技术不感兴趣

无代码编写业务逻辑

回归初心 —— 为什么要用前端技术?

Q&A

参考文档