说说全栈工程师

http://www.oschina.net/question/1024009_141796

对每一层都熟悉，究竟包含哪些层呢？作者的观点是：

1. 服务器、网络、运维。
2. 数据模型。
3. 业务逻辑。
4. API 层、Action 层、MVC。
5. UI 层。
6. 用户体验。
7. 理解用户与商业需求。

如果对以上七层都很熟悉，同时精通一二，就是全栈工程师了。

这样来看其实并不难。比如对 Java 开发来说，第 3 层是工作重点，稍微有点追求的工程师，对 1、2、4、5 层也都会有一定的熟悉。对前端工程师来说，第 5 层是工作重点，然后对 3、4、6、7 层也会有一定熟悉度。其他职位，运维、DBA、测试等，也都有精通点，同时对周边的层会有熟悉度。

也就是说，大部分有点追求的工程师已经是四分之三栈工程师。反而单栈工程师很少很少，甚至不可能存在。

回到全栈工程师的定义，可以分解为三点：

1. 精通若干层。
2. 熟悉所有层。
3. 对软件技术充满热情。

第 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/lifesinger.github.com/issues/185

我觉得这篇文章比较符合我的观点