关于前端工程师与其他岗位协作的想法

终于有时间静心想了一下W3CTech的交流话题，觉得还是写一点好，之前裕波同学发来话题的时候，一直觉得这是一个太泛泛的话题，但是 后来又思考了一下，这的确是一个值得去讨论的话题：前端工程师究竟如何去与其他岗位协同作业？

首先，这个话题应该从高中低三个层次去切入，因为所谓的协同作业在不同的公司不同的环境，甚至不同的部门都是有差异的，并不是说公司或者部门有高下 之分就要分三个层次去探讨，而是我觉得它们之间实在有很大的差异。

低级协作我认为在小型的团队较多，它的角色划分很简单客户（OR 老板）、设计、前端、后台开发，在这个流水线里，前端需要与三方的接触，需要清楚客户提过来的页面互动需求，需要知道设计师的设计意图，需要考虑后台开发 的实现接口，这是比较传统的协作方式，或者也有人叫线性的协作，而其实即便是这种古老的流水线式作业里，前端仍旧无法高效的工作，具体表现为与客户的沟通 不畅，前端工程师切入的是专业的代码级的点，而客户往往关注的最终的效果，与设计师的分离或者脱节，诸如前端抱怨设计对浏览器的无知，或者设计埋怨前端无 法完美还原他们的作品，以及不了解后台架构忽略了页面在动态状况下的实现，或者后台开发直接插手前台代码，等等。在这种协作模式里，前端是一个处于弱势的 职业角色，而也正因为如此，许多小型公司都基本忽视了这个职位，甚至是设计和前端一人担当，我觉得要在这种模式里，协作效率的提升完全取决与前端的个人能 力，如你能用深入简出的话语跟客户去沟通，你能在设计师抱怨的时候跟他讲清楚为何不能实现，你能预留出动态代码的实现DEMO等等，甚至是你涉猎广泛可以 跟设计师谈设计构成可以跟后台开发谈后台架构，但是总之，我觉得在这种模式里效率很难得到保证。

中级协作，相应的这种模式下角色划分更为细致，如有产品经理介入，有交互设计以及UE参与等等，最关键的是前端参与进项目流程，他从项目初始就跟 进，从专业的角度来协同各个岗位做好这件事。许多的专业web team大体都会这么去配置，在这种模式下前端需要的是比较强的专业影响力，从项目开始时就有一个比较清晰的路线图，在跟进过程中跟每个环节的涉及的人去 打交道，把能够促进这件事完美完成的东西加入到环节中去，如去跟产品经理一起讨论最理想的产品架构，跟设计师讨论设计中的细节和交互的实现，跟后台开发讨 论代码层级的优化等，在这种模式下效率的提升应该来自比较完善的参与机制，如前端在什么节点介入，介入的深度等等，我认为前端在开始就要介入项目，但不一 定要很深入，这样可以充分了解项目背景，前期应该是与相关岗位的人员一起，共同制订一个大纲，当枝节理顺时就可以进入设计环节，在设计环节里跟设计一起确 定细节的东西，在产出页面前应该与后台开发就接口做一个提前接入，如给定接口模式之类，最后才是产出页面，当然这还没有完，后面还有测试评估以及不断的版 本迭代。

中级协作看似挺完美，但是还是有些遗憾，如这种协作依旧是需要前端工程师的较强的个人能力，无法模式化，我觉得更高级的协作应该是引入前端架构师的 角色，关于前端架构师的职能，我觉得简而言之，他就是一个专门去做这些协作工作的人，以下是引用kejun对前端架构师的职业描述：

1. 他需要制订一套跟上下游环节更高效配合的技术方案。具体说有改进模板（视图层）的开发方式，团队内部开发方式，维护和测试方式等。

2. 他要把关各种技术的实施方案。哪种好，哪种有风险，哪种还不成熟，哪种成本高。需要“把握问题的关键，平衡设计”的能力。

3. 他要主动联合相关部门，从性能、易用性、安全性等方面提升产品的价值和竞争力。

4. 他要正确选择适合产品的框架和库（或设计这样的框架和库），建立建全规范体系。保证代码风格的一致性（解决开发效率的问题）。

5. 他要有前瞻性。引入先进的前端技术落地到具体的产品中。

6. 他要负责团队成员的甄选。

7. 他要能做PPT，向高层布道。

说的比较具体，如果一个团队存在这么一个角色，那么与其他岗位的协作将会是统一和模式化的，前端工程师在架构师的框架里可以更好的发挥自己的专业技 能，当然这是比较理想的状态，我觉得在现在的状况下，在团队中可以培养一些前端工程师的架构思想，尝试制订一些协作框架，好的制度永远胜过个体的强大，只 有建立高效的协作机制，才能保证在各种良莠不齐的团队中协作的高效。