全栈工程师(Full Stack Developer)好像突然就火了,知乎、微博上都有讨论。这个概念在 2012 年时就有提出:What is a Full Stack Developer?,主要观点是:
有这么一批人,他们对软件开发的很多层未必精通,但对每一层都很熟悉,他们对软件技术充满热情,这种人就是所谓的全栈工程师。
对每一层都熟悉,究竟包含哪些层呢?作者的观点是:
- 服务器、网络、运维。
- 数据模型。
- 业务逻辑。
- API 层、Action 层、MVC。
- UI 层。
- 用户体验。
- 理解用户与商业需求。
如果对以上七层都很熟悉,同时精通一二,就是全栈工程师了。
这样来看其实并不难。比如对 Java 开发来说,第 3 层是工作重点,稍微有点追求的工程师,对 1、2、4、5 层也都会有一定的熟悉。对前端工程师来说,第 5 层是工作重点,然后对 3、4、6、7 层也会有一定熟悉度。其他职位,运维、DBA、测试等,也都有精通点,同时对周边的层会有熟悉度。
也就是说,大部分有点追求的工程师已经是四分之三栈工程师。反而单栈工程师很少很少,甚至不可能存在。
回到全栈工程师的定义,可以分解为三点:
- 精通若干层。
- 熟悉所有层。
- 对软件技术充满热情。
第 3 点很重要。未必要刻意去让自己熟悉所有层,如果能「对软件技术充满热情」,那么遇到陌生领域时,一个优秀的工程师会有能力去快速学习,从而慢慢地自然而然地就熟悉所有层,就莫名其妙成为全栈工程师了。
全栈工程师是不给自己设限,是永远保持激情和学习欲望的一批人。
另外想说一点,全栈工程师并不违背《国富论》提到的社会分工。在软件开发领域,分工依旧是提高效率的重要手段。但分工后,还有影响效率的一个重要因素:
分工是否合理,是否已达成让合适的人做合适的事。
从分工合理性的角度去考虑,会发现一些传统的分工未必是合适的。比如第 4 层 MVC 中的 View 和 Controller 层,Java 开发工程师真的是最合适的人选吗?这一层或许可以细化为:
4.1、Service、API、Model 层。
4.2、View、Router 等处理。
这样,4.1 依旧是后端开发擅长的领域,4.2 则很可能交给前端工程师来负责更合理。再次分工、分工合理性的判定,经常就需要跨界了解,需要全栈工程师的视角。
如果 4.2 交给前端来负责,Node 很可能就是当下更合适的技术选型。基于 Node 可以达成更合理的分工,有如 NCZ 的想法:
全栈视角可以让我们重新去审视、去思考各个角色最合适去做什么,从而有可能促进更合理的分工协作。一旦发现了更合理的分工、需要对分工做出调整时,全栈就是一种自然而然的要求。比如基于 Node 的前后端分工协作,就需要前端工程师勇敢地去承担原来只是熟悉却并不精通的领域。如果能承担下来,无论对前端还是后端,效率上都会有提升,甚至带来一系列研发交付方式的变革。
全栈的背后,是自由,是分工的更细化,是分工的更专业。
(转自https://github.com/lifesinger/blog/issues/185)