导读
年，Web开发整体上仍然处于比较低效的状态，各种开发，部署工具仍未很好的收敛，开发者仍然要面对选择框架，选择各种库，选择部署方式，沟通前后端接口等，一个完整的Web应用开发会牵扯很多不同的工种，而不同分工之间的协作却是很低效的，本文旨在能够很好的梳理当下Web开发的"困局"，以及我们通过何种方式，能够走出这些困局，解放生产力，希望能给未来的工具发展给出一定的预测和启发。
困境设计/前端协作困境
在实际的Web开发中，UI/UX的工作与前端的工作事实上是在两个完全割裂的环境中进行的，比如，UI会在Figma中完成页面与组件的设计，而前端则是根据设计好的原型图，在代码环境中去复现原型图，这其中就出现了几个协作问题。我把它简要总结成四个问题：
应该先设计再开发，还是先开发再设计？（DevFirstorDesignFirst？）如果说设计的原型图是前端开发的上游，那前端应该如何更高效地获取设计的上游更新？设计图中藏有很多可复用的概念与元素，如何很好的传达给前端？前端工程师是否有义务参与纯样式的开发？既然UI已经完成了样式的设计，为什么前端仍然需要重新实现一遍？
下面我们逐个讨论这些问题，之后给出可能的解决方案。
DevFirstOrDesignFirst？
先来讨论第一个问题，这是一个困扰了我很久的问题，在之前的工作经验中，我的处理方式往往是，以功能为主的组件，先开发，再设计（比如富文本编辑器），以展示为主的，先设计，再开发，但是实际的协作仍然会出现很多问题：
DevFirst：先开发再设计，往往前端程序员需返工（比如原来调的现成组件现在不能直接用了，需要自己重新写一个），降低前端程序员工作体验，而在设计图不稳定的时候，前端会反复地follow设计图的改动，降低前端程序员的工作体验，有时甚至会引发员工间的矛盾。
DesignFirst：设计对组件逻辑理解较为模糊，难以涵盖组件所有状态的样式，而为了枚举或描述组件的所有可能状态，常常过于繁琐，会有很多长得很像的重复原型图，而缺斤短两的原型图，也容易影响前端工程师的工作体验，甚至会提升责任推卸的可能性（前端觉得有些组件状态设计图没有给到，就停工了，将责任推卸给UI）。
之后我们可以看到，如果不改变协作模式和工具，这个dilemma是无法消除的。
前端应该如何更高效地获取设计的上游更新？
设想这样一个场景，公司有一个完整的设计团队，它们有时会更新一些组件的图标，当这些图标得到更新后，设计团队可能会手动通知前端工程师，前端工程师再下载到新的icon文件，将该文件放入仓库的src/assets下，再push代码，触发流水线，部署完毕后，icon得到更新。
上述的过程显然是十分低效的，设想这样一种情形，全公司有上百个网站，几乎每个网站都用到了公司的logo，但绝大多数网站都是将该logo放入src/assets这样的形式来部署的，那么当公司更新logo的时候，就需要所有代码仓库都更新该logo，浪费很多团队，很多人的时间，并且更重要的是，公司logo的全量更新成为了一个漫长的过程。
除了上面这个例子外，还有很多例子，比如设计经常会给原型图做一些修改，每次修改后，如果我们希望足够敏捷，那UI就会当场通知前端，前端再打开Figma之类的软件和VSCode等开发工具，完成了更改（更多时候，前端还需要仔细检查到底是哪里更改了，有时需要和UI进行同步沟通），在这个场景下，前端像是被UI牵着鼻子走的工种，长此以往，前端会觉得自己的工作没有价值，引发更深层次的问题。
那为了防止这样的现象，我们索性牺牲敏捷性，每个月迭代一版，前端统一更新UI，但这样又抛弃了Web的优势之一：用户使用的应用永远都是最新的，在讲究快速迭代的环境中，这种方式越来越少见，一个例子就是现在越来越多的Web应用忽略了版本号这个概念，因为只要能够很好的追踪
