前端开发岗位：静态与交互的细分是否必要？

昨天早上在微博上看到@前端农民工 发了条关于前端工作细分的微博，大意是说将前端的工作细分为页面重构(html/css)和js开发限制了工程师的发展，而且页面功能模块的开发维护也会变得割裂，一定程度上限制了js和css的配合方式，公司不应该这样做。

然而，事实上很多互联网公司前端团队就是这么干的，包括我们团队，今天就来探讨一下这个问题，看看很多公司为什么要把前端工作细分，把前端工作细分有什么好处，能为我们解决那些问题。

首先我们明确一下前端岗位职责的问题，前端岗位的输入是UED部门给到PSD效果图、后端研发给到API，输出产品成品。也就是说拿到UED部门给到的PSD效果图做成HTML、CSS，再拿到后端研发给到的API，完成前台逻辑、前后端数据交互及其他JavaScript开发，最终产出产品成品并提交给测试。

由前端的岗位职责我们可以看出，前端工作可以分为两种，一种是偏静态，即HTML、CSS开发，一种是偏交互，即JavaScript、前台逻辑和前后端交互。这两种工作对人的要求是相差很大的，偏静态的可以不涉及太多编程和逻辑，但要求心细、能把握细节、对视觉体验非常敏感、对用户体验有一定的理解、能忍受IE6等浏览器带来的痛苦、能持续学习，而后者对JavaScript要求较高、要有一定的编程能力、熟悉前后端协作模式、熟悉HTML和CSS、有一定的前端架构能力。

从公司组建团队的角度来说，要找一班优秀的full stack前端工程师，是有一定难度的。比如我们鑫合汇前端团队，现在一共7个人，如果我们要求每一个人都写HTML、CSS、JavaScript、前台逻辑、前后端交互，并且都产出可维护的高质量代码，对很多人来说做到没问题，但你知道要招到那么一班人有多难吗？现在市场上本身优秀前端就相当奇缺，对于一个BAT以外的互联网公司来说，也许1个月都招不到1个让你满意的人，然而，如果我们换一种方式，找几个偏静态的，找几个偏交互的，相对来说，难度就小了很多，也许原来4个月都很难招到那么一班人，现在不到2个月就办到了。千万别小看这一点，对于很多互联网公司来说，速度就是生命，不能迅速组建好团队并快速将产品推向市场，也许就意味着完蛋。

从公司用人成本的角度来说，将前端细分为偏静态和偏交互，能节约一笔开支。对每一个人都是高要求的话，自然成本要大一些，然而，如果把人员的要求都相对降下来了，成本自然也就降下来了。

从团队效率上来说，将前端细分为偏静态和偏交互，是高效的。打个比方，团队有50个页面要做，一共有5个人，是每个人做10个静态页面，并实现所有的JavaScript、前台逻辑、前后端交互效率高？还是2个人做所有的静态页面，3个人完成JavaScript、前台逻辑、前后端交互效率高？肯定是后者，专注于做静态页面的同学可以做到平均一个页面45分钟完成，但如果全部都做，是很难做到的，并且写JavaScript效率也变低了。

从团队技术管理的角度来说，将前端细分为偏静态和偏交互，人员相对易于管理，而且更容易产出可维护的高质量代码。偏静态的几个人可以致力于将静态这一块做到极致，偏交互的几个人可以致力于将交互做到极致。

从个人职业上来说，将前端细分为偏静态和偏交互，降低了前端职位的从业门槛，有了一定技能的时候更容易安定下来。

有人说前端细分这样限制了JavaScript和CSS的配合方式，以我们鑫合汇团队的实践经验告诉大家，JavaScript和CSS的配合没有问题。

有人说前端细分限制了工程师的职业天花板。这个在某些情况下是成立的，但是个人的职业天花板更多的还是由人本身决定的，一个对职业有追求的人，会想方设法让自己的路越来越广。马云以前是英语老师，现在是中国首富，我初二的语文老师以前是挖煤的工人，主要还是由人本身决定的。当然如果你想在你们团队中静态和交互都做，也很简单，据说腾讯有的团队就可以轮岗，干几个月Node.js、再干几个月做静态页面，你在你们团队中提出来，我相信你们老大会同意，只要不在项目非常紧急的时候。

我们程序员都希望自己能掌握更多的技术，精通前后端等所有技术，打败Google，征服世界，相信我们程序员的思维是值得所有人尊敬的！

最后再来个总结吧，(*^__^*) ，将前端细分为偏静态和偏交互，顺应了互联网企业的发展需求，是今后的必然趋势，无人能打败的趋势！

作者：Hoogle ；转载自：简书