共计 1825 个字符，预计需要花费 5 分钟才能阅读完成。
「降本增效」是人们在生产过程中永恒不变的话题、永远的谋求——于公，短暂看能够让企业缩小开销并提供更为稳固、优质的产品；于私，可能使本人缩小反复无养分的劳动，将精力投入到更为「高精尖」的中央，有助于自我成长，为本人为企业发明更大更多的价值。
提效的形式
当初想一下，在纯 Web 开发或大前端联合 Web 服务的畛域中，提效的形式都有什么？
单点提效
从前端角度看，绝大部分前端团队都在不遗余力地去封装本人的工具库、UI 组件库、脚手架与构建工具，有些能力强点的团队还会封装利用开发框架、可视化源码搭建工具等。
从设计角度看，每个部门都会搞本人的设计规范 / 设计语言 / 设计体系，整顿出一份设计侧的 UI 组件库，并制订一套 Design Token 用于与其余设计及前端沟通交流和设计与研发之间的联动。
从后端角度看，貌似没有什么可提效的空间——后端语言大多公司用的是 Java，相干生态体系曾经很健全，顶多做些业务层面的封装。
从产品角度看，产品经理的工作就是接管 / 提出需要，做一些产品层面创收和改良相干的事件，这类思维流动为主的根本只能通过晋升思维能力去提效了，如果有个业务向的常识图谱兴许会好些。
链路提效
同工种或者说分工内提效的天花板清晰可见，很容易就会达到瓶颈。要想更进一步，自然而然也必须要跳出本人所处角色的视角，横向寻求上下游间的买通，独特提效。
以前端为核心与其余环节进行买通的话，大略是这么几种伎俩：与设计之间是设计稿与前端代码互转，即 D2C、C2D；与产品之间是需要文档转代码，即 P2C；与后端之间是采纳 FaaS，即惯例意义的「前后端一体化」。
产研一体化
上述几种链路提效形式的思考角度，个别都比拟表层，仍是以本人或别人的职能为出发点，而不是从问题的实质开始探究解决方案——尽管每个分工角色的交付物不同，但它们都应是同一样事物的体现。
那么，那个「同一样事物」是什么呢？是模型与流程，或是业务概念、概念之间的关系以及相互间的作用，又或是业务知识。
所以，链路级的提效最要害的一点就是畛域驱动的对立建模，其产物作为全链路的惟一可信起源（Single Source of Truth）。这意味着，从需要 / 产品、设计到开发、测试，都要基于同一份「数据」进行。
简要作业流程
产品整顿各类需要，划分出各种业务概念，明确它们之间的关系和作用规定，这一过程就是在建模，最终会产出模型和流程。
建模完结后，产品能够在积淀了 UI 组件、逻辑函数等物料的利用搭建平台上联合建模的产物制作「原型」，「原型」即最终页面。
若已有物料中没有想要的 UI 组件和逻辑函数等，能够用占位符之类的形式标注下，让设计和开发去补上。而 UI 组件和逻辑函数等的研发，既能够走线下又可能走线上。
合作模式改革
从下面的简要作业流程能够看出，从需要到研发最重要的角色根本只有产品和后端——产品负责领域建模和「原型」搭建，后端负责代码及数据连贯，设计和前端被「踢」了进来，业务研发流程失去了精简。
从另一方面来看，也应该去尽可能增员——
软件开发过程就是从接到需要到产出合乎需要的可用软件的过程。在这一整个链条中，源头是需要提出方，而后通过产品、设计、开发、测试等不同岗位的人解决。
虽说源头是需求方，但更理论的源头是需求方的志愿。这个「志愿」是不是「真（true）」的，首先要打个问号。而后信息在传递过程中必定会有所损失，每个传递的节点能力越差损失得越多。
信息在每个人那里输出、输入时，因为常识、理解力、表达力等因素，多多少少都会产生变形，为了尽可能「保真」，必然的抉择就是缩小传递环节，也就是缩小参加人数，尽最大可能让需求方的志愿间接变成合乎需要的可用软件。
欧雷《说说「反混沌」：Hello, World!》
那设计和前端干嘛？要被裁了吗？！当然不是！尽管他们离业务比拟远，业务研发流程根本不须要他们，但利用搭建体系的物料开发和保护须要他们啊！在这里，他们对团队的价值可能最大化。
总结
本文简略梳理了在纯 Web 开发或大前端联合 Web 服务的畛域中始终以来大家为提效所做的各种尝试，并描述了「产研一体化」在我脑中的轮廓。
目前次要是几个大厂以提效为目标在「产研一体化」方向进行摸索，我在这个方向上也有了比拟具体的有待尝试落地的想法，待日后缓缓道来。「反混沌」体系下的「Fxxk Design」和「Future.js」就是「产研一体化」这盘棋上的棋子。
「产研一体化」是中后盾利用低代码化过程的一部分，也是前端工业化过程的一部分。
本文其余浏览地址：集体网站|微信公众号
