我们真的缺前端工程师吗？
这两天在好几个地方都看到了一篇关于为什么整个互联网行业都缺前端工程师？的文章，文章本身是去年的，中心思想是：其实我们并不缺前端工程师，我们缺的是优秀的前端工程师。我还是比较同意作者观点的，不过略有意犹未尽的感觉。于是我结合自己的经验，也来聊一下这个话题：我们真的缺前端工程师吗？
Thesewallsarekindoffunnylikethat.Firstyouhatethem,thenyougetusedtothem.Enoughtimepassed,getsoyoudependonthem.That’sinstitutionalising.
传统软件公司划分开发者的方式下，在前端部门的程序员永远不会去读缓存数据部分的代码，设计师也不太可能去和开发坐在一起，开发也不知道软件最终软件会以何种方式部署在服务器上。
什么是“前端”工程师
我在招聘广告和办公室的一些对话中，听到了一个新的角色：UIDev，事实上我在知乎上还回答过一个关于ThoughtWorks的UIDev的问题。简而言之，UIDev可以快速的把设计师的作品实现为HTML/CSS/JavaScript代码。
如果按照这个标准，我觉得UIDev对自己的要求太低了。毕竟要学会HTML/CSS实现mockup并不困难，但是成为一名前端工程师则需要掌握更多的知识：
会用PS来进行图片的处理（比如切图，微调等）
用HTML/CSS实现mockup（可能还有SASS/LESS等工具）
熟悉JavaScript（比如前端的MVVM框架，客户端模板）
前端开发的工作流程（代码检查，精简化，模块化CSS，LiveReload，调试）
编写测试（静态检查，单元测试）
跨浏览器、跨设备的解决方法（不同分辨率，不同厂商）
会根据项目的特点选择不同的前端技术栈（移动端，Web站点，响应式设计等）
在有了基础的HTML/CSS/JS技能之后，你会尝试做的更好：
如何更高效的操作DOM
如何将CSS写的更加清晰易懂
如何编写更加易于维护的代码（更有意义的单元测试）
如何组织大型的项目结构，模块化，组件化等等
这些要求事实上已经不那么容易做到了。它可能会花费你2到3年时间来完全掌握。但是2到3年之后，即便你已经成为了一个“合格的”前端工程师，这也还远远不够。在现实世界中，一个软件产品除了前端，还有非常广阔的空间，还有很多有趣的东西值得学习：
HTTP协议本身（缓存，鉴权）
Web容器/HTTP服务器如何工作
无状态的Web应用的工作原理（如何让网站正确地运行在集群上）
动态，静态内容如何分离部署（反向代理配置）
安全机制如何配置
监控机制如何配置
有了这些，也算是有点端到端的意思了。这时你也已经不是一个“纯前端”工程师了，系统中的大部分问题你都可以搞定，不过日常工作中可能更多的职责还是做前端的开发。但是这些还不够，软件除了交付之外，还有一些非功能性的需求：
端到端测试（UI测试，比如seleniumserver/webdriver）
devops（比如数据库环境，测试服务器，CI服务器的自动化provision）
基本的UI设计原则（在某些页面确实的情况下，根据系统的已有UI做设计）
数据库性能优化
性能测试
不过这些还只是我对于Web开发这个领域的总结。其他领域，比如大数据，机器学习，GIS，图像/视频处理等等。
这时候，你才能算是一个严格意义上的“前端”工程师。不从系统的角度来思考，不真正做一些后端开发/配置，并不能算是前端工程师，或者可以被称为偏前端工程师（partialfrontenddeveloper）。但是即使称为上边这样的“前端工程师”，我想这离一个优秀的工程师还是有很大差距的。
我跟一位设计师同事聊过这个问题：
Dev眼中的世界是这样的，从墙上（物理的或者电子的）上找到一些卡片（story卡或者需求文档说明书），然后撸袖子开干，干的过程中有很多自以为是的理解，同样有一些自以为是的牛逼实践（TDD啊，自动化啊），最后功能做完，大功告成，然后接着做下一个卡片。传统的Dev，或者苦逼屌丝程序员的世界就是这样的：需求从哪儿来，不知道；做完之后谁来负责质量，不知道；最终上线的时候怎么发布，不知道；线上有问题了怎么办，不知道。
以及
在ThoughtWorks，Dev的工作有了很大的变化，一个最明显的变化是边界的模糊。比如很多项目都不设QA角色，所有人都对质量负责，都做测试，也有OPs角色，但是大部分非生产环境都是Dev自己发布。也就是说，软件/项目生命周期中的大部分实践我们都能涉足，而且可以带来改进，提升效率。但是这只是往下游（从开发，到测试，到部署，到运维），反过来看上游，比如需求从哪儿来，Dev还是不知道。这毫无疑问是一个令人沮丧的事实，因为这需求的产生才是核心，也就是我昨天跟你聊的：一个idea如何变成一个可视化的原型，然后进一步演进为项目原型？
开发工作不应该仅仅局限在编码上，作为开发者/工程师，应该尽可能的多了解一些上下文：比如我们的项目最终是给谁用的，需求从何而来，项目是如何部署在线上的等等。