既然原文是说，Facebook 工程师说 Facebook 只招 full stack engineer，那我就来说说 Facebook engineer 都是怎样的人啦。
我觉得任何一方面的具体经验都不重要，重要的是思维方式和学习能力。首先说思维方式，那就是不为自己设限，不会想着自己是前端工程师，所以后端的东西我就一点也不碰。Facebook 的工程师，级别越高就需要保持越大的影响力。如何创造更大的影响力，就是寻找当前杠杆效应最明显的问题来解决。有些问题你解决了的话，投入进去的时间每小时能换回来一千美元；有些问题你解决了的话，投入进去的时间每小时能换回来一百万美元。然而哪些问题更值得解决，这是动态的，往往还存在衰减效应。如果现在性能瓶颈在后端，你做了一个季度两个季度优化后，瓶颈就已经不在后端了，你再优化下去衰减效应就会越来越明显。等瓶颈变成前端了，你是不是就说因为你不懂，所以不愿意碰？那就相当于寄望于公司有个前端很懂性能优化的人来解决，但如果公司没有这样的人那就没有人来解决了。
Facebook 的众多海报当中，有一张写的是「任何一个 Facebook 的问题，都不是别人的问题」。有问题，你就需要去评估是否值得解决。如果值得解决，你就应该着手去解决，而不是假设公司内会有另外一个人比你更合适解决这个问题。这时候很可能你就需要去做你从来没有做过的事情，需要学习你原本可能完全不懂的技术。如果你是个专门做数学模型的博士，加入 Facebook 原本是打算做搜索结果优化的，结果发现这不是最急需解决的问题，JavaScript 性能才是最需要解决的问题，你怎么办？如果你以为 Facebook 需要的是你做数学模型的经验，那你就错了。Facebook 需要的是你完成博士学位的学习能力。你从来没做过 JavaScript 并且觉得 JavaScript 很恶心？正确的做法是立即在网上买几本 JavaScript 入门的书连夜看完，然后着手分析性能瓶颈并且解决。在你完成手动优化后，你还可以思考一下能否把这做成自动化，例如说在代码提交时分析 JavaScript 语法树并且指出可能成为性能瓶颈的地方，又或者说从用户浏览器那里收集性能数据扔到 Hive 然后再从中分析产生瓶颈的特征。这些都可能涉及到一些你没有做过也没有学过的东西，但问题摆在那里你就需要去解决，而无论这要求你去钻研什么。这就是我所说的学习能力。
这是高级工程师和初级工程师的主要差距。尽管在高级到初级这一维度上，美国工程师和中国工程师是有重叠的，但美国的教育体系和行业传统使得美国应届生比一般中国工程师更偏向于高级那一端。美国学生的优势在于，他们的教育体系让他们习惯面对开放性问题。一家公司万千问题当中，此时此刻哪一个最值得解决？这不是中国工程师擅长的问题，因为实在是太开放了。中国教育让人擅长在给定条件下解决问题，太开放反而不知道从何入手。此外因为绝大多数文献都是英文的，所以要钻研什么对于能读懂英文的人来说都可以非常成体系的学习，这对于很多拒绝阅读英文的中国工程师来说很不利。拒绝阅读英文意味着永远只能接受别人的二手资料，对于很多概念的理解只能停留在技师的层面，而无法上升到工程师或者科学家的层面。
我觉得任何一方面的具体经验都不重要，重要的是思维方式和学习能力。首先说思维方式，那就是不为自己设限，不会想着自己是前端工程师，所以后端的东西我就一点也不碰。Facebook 的工程师，级别越高就需要保持越大的影响力。如何创造更大的影响力，就是寻找当前杠杆效应最明显的问题来解决。有些问题你解决了的话，投入进去的时间每小时能换回来一千美元；有些问题你解决了的话，投入进去的时间每小时能换回来一百万美元。然而哪些问题更值得解决，这是动态的，往往还存在衰减效应。如果现在性能瓶颈在后端，你做了一个季度两个季度优化后，瓶颈就已经不在后端了，你再优化下去衰减效应就会越来越明显。等瓶颈变成前端了，你是不是就说因为你不懂，所以不愿意碰？那就相当于寄望于公司有个前端很懂性能优化的人来解决，但如果公司没有这样的人那就没有人来解决了。
Facebook 的众多海报当中，有一张写的是「任何一个 Facebook 的问题，都不是别人的问题」。有问题，你就需要去评估是否值得解决。如果值得解决，你就应该着手去解决，而不是假设公司内会有另外一个人比你更合适解决这个问题。这时候很可能你就需要去做你从来没有做过的事情，需要学习你原本可能完全不懂的技术。如果你是个专门做数学模型的博士，加入 Facebook 原本是打算做搜索结果优化的，结果发现这不是最急需解决的问题，JavaScript 性能才是最需要解决的问题，你怎么办？如果你以为 Facebook 需要的是你做数学模型的经验，那你就错了。Facebook 需要的是你完成博士学位的学习能力。你从来没做过 JavaScript 并且觉得 JavaScript 很恶心？正确的做法是立即在网上买几本 JavaScript 入门的书连夜看完，然后着手分析性能瓶颈并且解决。在你完成手动优化后，你还可以思考一下能否把这做成自动化，例如说在代码提交时分析 JavaScript 语法树并且指出可能成为性能瓶颈的地方，又或者说从用户浏览器那里收集性能数据扔到 Hive 然后再从中分析产生瓶颈的特征。这些都可能涉及到一些你没有做过也没有学过的东西，但问题摆在那里你就需要去解决，而无论这要求你去钻研什么。这就是我所说的学习能力。
这是高级工程师和初级工程师的主要差距。尽管在高级到初级这一维度上，美国工程师和中国工程师是有重叠的，但美国的教育体系和行业传统使得美国应届生比一般中国工程师更偏向于高级那一端。美国学生的优势在于，他们的教育体系让他们习惯面对开放性问题。一家公司万千问题当中，此时此刻哪一个最值得解决？这不是中国工程师擅长的问题，因为实在是太开放了。中国教育让人擅长在给定条件下解决问题，太开放反而不知道从何入手。此外因为绝大多数文献都是英文的，所以要钻研什么对于能读懂英文的人来说都可以非常成体系的学习，这对于很多拒绝阅读英文的中国工程师来说很不利。拒绝阅读英文意味着永远只能接受别人的二手资料，对于很多概念的理解只能停留在技师的层面，而无法上升到工程师或者科学家的层面。
Live with less, share with more.
做这样一个简单的 app:
一个天气应用，干净清爽的界面，天气信息一目了然。它不仅可以精确预测未来 10 天的天气，还可以显示某地的历史天气信息。它具有自定义提醒功能，支持 web 版本， iOS 版， Android 版。
为什么想要做这样一个 App ？因为你喜欢旅行，但没找到一个天气 App 可以提供你下个月或者某个特定月份的天气信息；因为你懒你没有每天看天气预报的习惯，你想要在第二天温度达到 30 度以上或者温差有 +/-7 度的时候，获得温馨提示；因为你要成为一个 Full Stack Engineer ，你必须不断训练每个 stack 的能力。
## Web版
你决定用 MySql 来存储用户数据，用 NoSql 存储历史天气数据。你用 Redis 作为 cache ，缓存一些最常请求的天气数据。你用 Python 写后台，功能简单，后台不复杂，用户注册登录，抓取返回某城市的天气数据，某地的历史天气数据，很快便搞定。
后台开发并测试好了，接下来是 Web 前端。你十分清楚一个好的 UI 设计对一个 App 的重要性，你也明白 UI 的设计不只是为了美观，更重要的是提高信息的可读性和程序的可用性。幸好你平日的积累这次派上用场了。你把之前保存下来的上百个优秀的UI设计作品拿来研究，你从书架上拿出Norman 的那本经典 - The Design of Everyday Things 重新细读。最终你用白纸黑笔敲定了第一个版本的 UI，简洁直观，没有任何多余的设计，所有元素的排列间距 大小颜色都恰到好处。你相信即使天气不好，但用户只要使用这个 App 都会有着愉悦的心情。
那么开始写前端吧。啊，别急，都忘了还有 Icon 和 Logo ，可是不会 PS ，不会 AI ，不会 Sketch 怎么办呢，学吧。你平日喜欢结交不同领域的朋友，正好几周前在一个活动上你认识一位朋友做设计的。她花一个下午的时间教你基本的 Sketch 的使用，并对你的 UI 设计给出了一些意见。你请她吃了顿晚饭表示感谢，然后立即回家根据她的一些建议重新调整了 UI ，这次你在 PS 里把 UI 画了出来，Icons 和 Logo 也顺道一起做了。
接下来的一周，你学习 HTML，CSS，以及 Javascript，并漂亮地把前端搞定。
## 发布 App
在朋友圈发了个状态，找人帮你做 Beta 测试。他们都首先问你是什么 App，一开始你简单回答一个天气的 App。但你发现，这不能提起他们的兴趣。你觉得你需要用语言，用故事包装一下。不光是作为别人「是什么 App」提问的回答，也是成为 Full stack Engineer 道路上的一个重要技能。
你去看了所有你喜欢的产品的主页，从他们的文案上获得一些灵感启发；你读了经典的 On Writing Well ，发现好的文案，好的设计，其实和好的代码很相似，都是重在交流，如何让他人毫不费劲地明白你要表达的内容。你的故事要吸引人，你的产品介绍要在1分钟内解释清楚，并确保你的父母可以毫无压力听明白。
一切就绪，产品上线了。反响不错，用户持续增加。很多用户希望有移动版本，于是你立即投入到iOS 版本的开发上。
## iOS 版 及 后台优化
你花一周不到时间学习了基本的语法和工具使用便投入到 App 的开发中。你知道 Learn by Doing 是最好也是最快的。由于之前学习了设计的基础，UI ，Icons 很快搞定，不久 iOS 版本便发布了。iOS 的发布带来了更多的用户增长，后台服务器的压力颇大，你知道是时候优化后台了。
你在 AWS 上多开了 2 台服务器，并写了一个 Script 来自动化部署过程。
你改用 uWSGi 协议，用 uwsgi 作为 Application Server。
你使用 Nginx 来做并发，负载均衡 ...
......
......
## 成立公司
用户持续增长，每天你都会收到十几二十封用户的邮件。你很感激这些愿意花时间给你写邮件的用户，你相信他们是你最重要的用户，是潜在的付费用户。如果你把他们像上帝一样对待，他们同样也会把你看作是上帝。所以除了睡觉时间的发来的邮件，每一封邮件，你都会在2小时内给予回复。
果然这样的付出是收获巨大的，他们不仅惊讶且非常感谢你的快速回复，他们会在app store里给你★★★★★的评价，他们在社交网站上分享你的app，他们甚至会主动提出捐款给你。
你从快速的用户增长中嗅到了商机，你开始思考如何赚钱。广告你是坚决不能允许的，你认为再精确的广告也会影响用户体验。你设计了 2 个不同的付费方案，你打算用 A/B 测试看哪个方案更好。你分别给 200 个用户发去邀请尝试付费的邮件，邮件内容你精心打磨过，并在最后写上：CEO & Founder. 通过分析 2 种方案的用户行为，你决定将使用第一种方案。
接下来，你相信差不多是时候成立个公司了。为了省时间，你花 2000 块钱找了个园区挂靠并帮你注册公司。公司的名字让你头疼了很久，你不想只是简单的用这个 App 的名字作为公司名字，你知道公司将来还会做出其他优秀的产品。你希望这个名字简单易记，同时其含义也是你公司文化的象征。
公司注册下来了，但银行那边得自己跑。你联系了一些媒体编辑，邀请他们来试用你的产品；你重新设计了产品主页，并开始写产品的 Blog ；你在各大社交网络都给 App 注册了账号，即做社区客服也为宣传... 这些事大大压缩你写代码的时间。以往你都是以代码量作为衡量自己当天工作效率的指标，所以这些天你总感觉没做啥工作。
这样的发展早已超过你的预期，这个 App 从一个 Side Project 几乎变成了你生活的全部。你跟你女朋友半个月才出去约会一次，她抱怨不断；你1个月没跟朋友出去玩耍喝酒了；你 2 个月都没锻炼过身体... 你意识到, YOU CAN NOT DO THIS ALONE，你需要帮手，你需要找人一起把这个做下去。
但你不是要成为 Full Stack Engineer 么？你现在是了么？
## Full Stack Engineer
设计，后台开发，前端开发，移动开发，运营维护，PS，文案... 好像都会了，这算 Full Stack Engineer 了么？
不，这只是踏上成为 Full Stack Engineer 的第一步。你知道目前只是每个 stack 都懂一点，离senior 或者 expert 还差得远，而要每个 stack 都做到极致，需要大量的时间和精力。精力有限，产品开发紧迫，力不从心啊，这条道路也太孤独，因为你不需要与任何人进行协作。难道要把一些stack的任务交给别人做么？这样算是放弃成为 Full Stack Engineer 么？
不！这不是。
什么是 Engineer？「Engineers are versatile minds who create links between science, technology, and society」。
Engineer 的本质工作是设计，开发出应用于大众的产品。
一个真正的 Full Stack Engineer ，他从生活中发现问题，洞察需求，他设计解决方案，并开发出初始版本的产品。为了达到目标，他愿意去学习任何领域的技能和知识。同时他不追求一个人完成所有工作，如果有人可以比他在某方面做得更出色，便会十分热情的邀请他们加入。
最终他的职位也许不再是 Engineer ，他不再设计 UI ，不再写代码 ... 他的工作不再是 design and building an app or product，因为他有更大更重要的任务要做 - design and building a team or a company which builds great products.
而这时，社会给了他们另一个称呼 - 创业者。尽管众人已忘记他们 Engineer 的身份，但在他们骨子里，内心深处，自己始终都是一个 Engineer 。当他们需要从头再来时，他们毫不犹豫从设计开发产品做起。Nikola Tesla，Ferdinand Porsche，Henry Ford，Jack Dorsey，Mark zuckerberg，Elon Musk ... 细数那些改变了或正改变世界的创业者，他们大多数是 Engineer 背景，热衷于设计创造。他们学习技能和知识，不是为了成为某个领域的专家；而是因为那些 是完成自己目标所需要的。
以上，为我认可的 Full Stack Engineer
---
Peng
一个天气应用，干净清爽的界面，天气信息一目了然。它不仅可以精确预测未来 10 天的天气，还可以显示某地的历史天气信息。它具有自定义提醒功能，支持 web 版本， iOS 版， Android 版。
为什么想要做这样一个 App ？因为你喜欢旅行，但没找到一个天气 App 可以提供你下个月或者某个特定月份的天气信息；因为你懒你没有每天看天气预报的习惯，你想要在第二天温度达到 30 度以上或者温差有 +/-7 度的时候，获得温馨提示；因为你要成为一个 Full Stack Engineer ，你必须不断训练每个 stack 的能力。
## Web版
你决定用 MySql 来存储用户数据，用 NoSql 存储历史天气数据。你用 Redis 作为 cache ，缓存一些最常请求的天气数据。你用 Python 写后台，功能简单，后台不复杂，用户注册登录，抓取返回某城市的天气数据，某地的历史天气数据，很快便搞定。
后台开发并测试好了，接下来是 Web 前端。你十分清楚一个好的 UI 设计对一个 App 的重要性，你也明白 UI 的设计不只是为了美观，更重要的是提高信息的可读性和程序的可用性。幸好你平日的积累这次派上用场了。你把之前保存下来的上百个优秀的UI设计作品拿来研究，你从书架上拿出Norman 的那本经典 - The Design of Everyday Things 重新细读。最终你用白纸黑笔敲定了第一个版本的 UI，简洁直观，没有任何多余的设计，所有元素的排列间距 大小颜色都恰到好处。你相信即使天气不好，但用户只要使用这个 App 都会有着愉悦的心情。
那么开始写前端吧。啊，别急，都忘了还有 Icon 和 Logo ，可是不会 PS ，不会 AI ，不会 Sketch 怎么办呢，学吧。你平日喜欢结交不同领域的朋友，正好几周前在一个活动上你认识一位朋友做设计的。她花一个下午的时间教你基本的 Sketch 的使用，并对你的 UI 设计给出了一些意见。你请她吃了顿晚饭表示感谢，然后立即回家根据她的一些建议重新调整了 UI ，这次你在 PS 里把 UI 画了出来，Icons 和 Logo 也顺道一起做了。
接下来的一周，你学习 HTML，CSS，以及 Javascript，并漂亮地把前端搞定。
## 发布 App
在朋友圈发了个状态，找人帮你做 Beta 测试。他们都首先问你是什么 App，一开始你简单回答一个天气的 App。但你发现，这不能提起他们的兴趣。你觉得你需要用语言，用故事包装一下。不光是作为别人「是什么 App」提问的回答，也是成为 Full stack Engineer 道路上的一个重要技能。
你去看了所有你喜欢的产品的主页，从他们的文案上获得一些灵感启发；你读了经典的 On Writing Well ，发现好的文案，好的设计，其实和好的代码很相似，都是重在交流，如何让他人毫不费劲地明白你要表达的内容。你的故事要吸引人，你的产品介绍要在1分钟内解释清楚，并确保你的父母可以毫无压力听明白。
一切就绪，产品上线了。反响不错，用户持续增加。很多用户希望有移动版本，于是你立即投入到iOS 版本的开发上。
## iOS 版 及 后台优化
你花一周不到时间学习了基本的语法和工具使用便投入到 App 的开发中。你知道 Learn by Doing 是最好也是最快的。由于之前学习了设计的基础，UI ，Icons 很快搞定，不久 iOS 版本便发布了。iOS 的发布带来了更多的用户增长，后台服务器的压力颇大，你知道是时候优化后台了。
你在 AWS 上多开了 2 台服务器，并写了一个 Script 来自动化部署过程。
你改用 uWSGi 协议，用 uwsgi 作为 Application Server。
你使用 Nginx 来做并发，负载均衡 ...
......
......
## 成立公司
用户持续增长，每天你都会收到十几二十封用户的邮件。你很感激这些愿意花时间给你写邮件的用户，你相信他们是你最重要的用户，是潜在的付费用户。如果你把他们像上帝一样对待，他们同样也会把你看作是上帝。所以除了睡觉时间的发来的邮件，每一封邮件，你都会在2小时内给予回复。
果然这样的付出是收获巨大的，他们不仅惊讶且非常感谢你的快速回复，他们会在app store里给你★★★★★的评价，他们在社交网站上分享你的app，他们甚至会主动提出捐款给你。
你从快速的用户增长中嗅到了商机，你开始思考如何赚钱。广告你是坚决不能允许的，你认为再精确的广告也会影响用户体验。你设计了 2 个不同的付费方案，你打算用 A/B 测试看哪个方案更好。你分别给 200 个用户发去邀请尝试付费的邮件，邮件内容你精心打磨过，并在最后写上：CEO & Founder. 通过分析 2 种方案的用户行为，你决定将使用第一种方案。
接下来，你相信差不多是时候成立个公司了。为了省时间，你花 2000 块钱找了个园区挂靠并帮你注册公司。公司的名字让你头疼了很久，你不想只是简单的用这个 App 的名字作为公司名字，你知道公司将来还会做出其他优秀的产品。你希望这个名字简单易记，同时其含义也是你公司文化的象征。
公司注册下来了，但银行那边得自己跑。你联系了一些媒体编辑，邀请他们来试用你的产品；你重新设计了产品主页，并开始写产品的 Blog ；你在各大社交网络都给 App 注册了账号，即做社区客服也为宣传... 这些事大大压缩你写代码的时间。以往你都是以代码量作为衡量自己当天工作效率的指标，所以这些天你总感觉没做啥工作。
这样的发展早已超过你的预期，这个 App 从一个 Side Project 几乎变成了你生活的全部。你跟你女朋友半个月才出去约会一次，她抱怨不断；你1个月没跟朋友出去玩耍喝酒了；你 2 个月都没锻炼过身体... 你意识到, YOU CAN NOT DO THIS ALONE，你需要帮手，你需要找人一起把这个做下去。
但你不是要成为 Full Stack Engineer 么？你现在是了么？
## Full Stack Engineer
设计，后台开发，前端开发，移动开发，运营维护，PS，文案... 好像都会了，这算 Full Stack Engineer 了么？
不，这只是踏上成为 Full Stack Engineer 的第一步。你知道目前只是每个 stack 都懂一点，离senior 或者 expert 还差得远，而要每个 stack 都做到极致，需要大量的时间和精力。精力有限，产品开发紧迫，力不从心啊，这条道路也太孤独，因为你不需要与任何人进行协作。难道要把一些stack的任务交给别人做么？这样算是放弃成为 Full Stack Engineer 么？
不！这不是。
什么是 Engineer？「Engineers are versatile minds who create links between science, technology, and society」。
Engineer 的本质工作是设计，开发出应用于大众的产品。
一个真正的 Full Stack Engineer ，他从生活中发现问题，洞察需求，他设计解决方案，并开发出初始版本的产品。为了达到目标，他愿意去学习任何领域的技能和知识。同时他不追求一个人完成所有工作，如果有人可以比他在某方面做得更出色，便会十分热情的邀请他们加入。
最终他的职位也许不再是 Engineer ，他不再设计 UI ，不再写代码 ... 他的工作不再是 design and building an app or product，因为他有更大更重要的任务要做 - design and building a team or a company which builds great products.
而这时，社会给了他们另一个称呼 - 创业者。尽管众人已忘记他们 Engineer 的身份，但在他们骨子里，内心深处，自己始终都是一个 Engineer 。当他们需要从头再来时，他们毫不犹豫从设计开发产品做起。Nikola Tesla，Ferdinand Porsche，Henry Ford，Jack Dorsey，Mark zuckerberg，Elon Musk ... 细数那些改变了或正改变世界的创业者，他们大多数是 Engineer 背景，热衷于设计创造。他们学习技能和知识，不是为了成为某个领域的专家；而是因为那些 是完成自己目标所需要的。
以上，为我认可的 Full Stack Engineer
---
Peng
Update：
我又合伙创业了。招php基础的开发者，入门基础到中级的都收，有意私信。坐标上海，汽车后市场的现代化连锁化互联网化改造。
http://www.zhuanchedao.com
如果你目前写的少基础还比较差，只要逻辑思维清晰，好学，问题不大，我会带你的。
另外说一下，开发者的概念。我们要的是开发者而不是程序员，我从入行2000年到转管理岗07年，之间的工作一直是开发者，尤其朗讯贝尔实验室，我们根本不管你会什么语言，我们默认你会所有的语言。就像我曾经接手一个perl的数据转换脚本的工作，迁移爱立信设备的用户数据到我们服务器上。就一周时间，我在班车上边啃骆驼书上班了边写，后面我就开始喜欢上写perl了。
我一直觉得，代码专家负责纯语言的底层事情，手术刀是用来做业务逻辑的，语言根本不是问题。
Update：
这个回答竟然收到的赞同比我其他所有回答都高，看来我还是转型灌技术鸡汤好了。
补充下，首先我觉得好的开发者，即使不是全栈，也要融会贯通多种技术。我从来不认为一个只专精一种技术的人有可能成为好的开发者，即使是 C，即使是汇编。（当然其实反过来看，那些大神们哪个不会搞点其他的？比如几个做服务器端开发的大神居然不懂服务器管理？）
然后从广度和深度的组合看，我认为好的开发者大概有两种类型：
1. 手术刀
2. 代码专家。
（来自《人月神话》）
手术刀是业务驱动的，最需要全栈的人；他们的核心价值在于：懂业务，技术全面，都能拿的起来，而且能选择最合适的技术。
代码专家是技术驱动的，即使不够全栈也可以用，但是技能树点的越多当然有好处。
而我提的创业逼出来的全栈，是因为，对于创业团队而言，手术刀更加重要，代码专家要依靠各种开源组织的贡献，或者临时聘请。
还有几位讲，创业的最大需求技能是整合资源的能力，找合适的人做事的能力。这个我认同，我只是说我自己，我承认我没能力忽悠一堆技术大牛策划大牛和我一起没工资的创业。我也忽悠不到前期种子投资的钱。
所以我说的，是说对于我，种子期，天使期，最重要的都是我自己作为手术刀，而不是资源整合者。
------------------------------------------
全栈工程师不是为了工作本身，是为了方便实现自己的梦。
作为一个标准的全栈工程师来答下，全栈工程师不是培养出来的，是逼出来的~
不是公司逼的，是自己逼自己逼出来的~
因为我要创业，我经济压力又大没法辞职，我没法忽悠其他人一起免费干活......而且作为一个写了13年程序的老程序员（貌似知乎上比我老的程序不会很多了。。。。），本来工作语言就已经用过 Delphi, C++，Java，Perl，PHP，Lua，ObjectiveC，NodeJS，Tcl。这些都是工作中用的，尤其是创业那些年，遇到什么问题，我就要自己去探路，探出路来需要招聘对应的人再招聘～结果顺便把各种语言都学了一圈～
之前创业三年，一开始就我一个技术，所以运维几十台Linux 服务器我也顺便管了（我之前工作平时就工作在 Solaris 下面，差距不大），我老婆是前端工程师，所以 HTML，CSS，JS 我也一起学了。
所以多学一些语言对我来说真的不是件事情......
做过几年游戏制作人（做制作人我也同时每天 写代码....），策划，UI 都还有心得。
而且我这十三年怎么过的呢？别人朝九晚五，我每天工作到半夜2点，周末也很少休息。
谁能做到这样努力的工作（不是为了“资本家”，而是为了自己为自己工作），并且不是一直专注于一个岗位，我相信都能成为全栈工程师。
回到起点，全栈工程师不是为了工作本身，是为了方便实现自己的梦。
没错，如一些答主所说，你各方面都半吊子，我承认。
我之前有一段工作是写 C++和 Lua。Lua 部分还好，C++要遍历个 std::map 我到现在记不住，每次现搜索。作为一个 C++程序员我不够好，只能算是入门，或者说我一直是重视实现功能而非钻技术细节的人。我不关心技术上多牛，我关心功能的实现。
但我的价值根本不在于是一个 C++程序员，而是我可以从前端到后端到运维提供一揽子方案，视野广阔，任何点都可以选择最合适的技术，比如说最终选择 Lua 实现逻辑。
如果是创业，我可以自己一个人完成这个纯应用层面难度的开发的全部工作（当然，我的意思不是我一个人全做掉）。
如果不是创业，我的价值可能也就是个2w 多工资的架构师或者技术经理，这个价格远远对不起我这13年的付出。
一个真正的全栈工程师，目标只有一个：创业。
我又合伙创业了。招php基础的开发者，入门基础到中级的都收，有意私信。坐标上海，汽车后市场的现代化连锁化互联网化改造。
http://www.zhuanchedao.com
如果你目前写的少基础还比较差，只要逻辑思维清晰，好学，问题不大，我会带你的。
另外说一下，开发者的概念。我们要的是开发者而不是程序员，我从入行2000年到转管理岗07年，之间的工作一直是开发者，尤其朗讯贝尔实验室，我们根本不管你会什么语言，我们默认你会所有的语言。就像我曾经接手一个perl的数据转换脚本的工作，迁移爱立信设备的用户数据到我们服务器上。就一周时间，我在班车上边啃骆驼书上班了边写，后面我就开始喜欢上写perl了。
我一直觉得，代码专家负责纯语言的底层事情，手术刀是用来做业务逻辑的，语言根本不是问题。
Update：
这个回答竟然收到的赞同比我其他所有回答都高，看来我还是转型灌技术鸡汤好了。
补充下，首先我觉得好的开发者，即使不是全栈，也要融会贯通多种技术。我从来不认为一个只专精一种技术的人有可能成为好的开发者，即使是 C，即使是汇编。（当然其实反过来看，那些大神们哪个不会搞点其他的？比如几个做服务器端开发的大神居然不懂服务器管理？）
然后从广度和深度的组合看，我认为好的开发者大概有两种类型：
1. 手术刀
2. 代码专家。
（来自《人月神话》）
手术刀是业务驱动的，最需要全栈的人；他们的核心价值在于：懂业务，技术全面，都能拿的起来，而且能选择最合适的技术。
代码专家是技术驱动的，即使不够全栈也可以用，但是技能树点的越多当然有好处。
而我提的创业逼出来的全栈，是因为，对于创业团队而言，手术刀更加重要，代码专家要依靠各种开源组织的贡献，或者临时聘请。
还有几位讲，创业的最大需求技能是整合资源的能力，找合适的人做事的能力。这个我认同，我只是说我自己，我承认我没能力忽悠一堆技术大牛策划大牛和我一起没工资的创业。我也忽悠不到前期种子投资的钱。
所以我说的，是说对于我，种子期，天使期，最重要的都是我自己作为手术刀，而不是资源整合者。
------------------------------------------
全栈工程师不是为了工作本身，是为了方便实现自己的梦。
作为一个标准的全栈工程师来答下，全栈工程师不是培养出来的，是逼出来的~
不是公司逼的，是自己逼自己逼出来的~
因为我要创业，我经济压力又大没法辞职，我没法忽悠其他人一起免费干活......而且作为一个写了13年程序的老程序员（貌似知乎上比我老的程序不会很多了。。。。），本来工作语言就已经用过 Delphi, C++，Java，Perl，PHP，Lua，ObjectiveC，NodeJS，Tcl。这些都是工作中用的，尤其是创业那些年，遇到什么问题，我就要自己去探路，探出路来需要招聘对应的人再招聘～结果顺便把各种语言都学了一圈～
之前创业三年，一开始就我一个技术，所以运维几十台Linux 服务器我也顺便管了（我之前工作平时就工作在 Solaris 下面，差距不大），我老婆是前端工程师，所以 HTML，CSS，JS 我也一起学了。
所以多学一些语言对我来说真的不是件事情......
做过几年游戏制作人（做制作人我也同时每天 写代码....），策划，UI 都还有心得。
而且我这十三年怎么过的呢？别人朝九晚五，我每天工作到半夜2点，周末也很少休息。
谁能做到这样努力的工作（不是为了“资本家”，而是为了自己为自己工作），并且不是一直专注于一个岗位，我相信都能成为全栈工程师。
回到起点，全栈工程师不是为了工作本身，是为了方便实现自己的梦。
没错，如一些答主所说，你各方面都半吊子，我承认。
我之前有一段工作是写 C++和 Lua。Lua 部分还好，C++要遍历个 std::map 我到现在记不住，每次现搜索。作为一个 C++程序员我不够好，只能算是入门，或者说我一直是重视实现功能而非钻技术细节的人。我不关心技术上多牛，我关心功能的实现。
但我的价值根本不在于是一个 C++程序员，而是我可以从前端到后端到运维提供一揽子方案，视野广阔，任何点都可以选择最合适的技术，比如说最终选择 Lua 实现逻辑。
如果是创业，我可以自己一个人完成这个纯应用层面难度的开发的全部工作（当然，我的意思不是我一个人全做掉）。
如果不是创业，我的价值可能也就是个2w 多工资的架构师或者技术经理，这个价格远远对不起我这13年的付出。
一个真正的全栈工程师，目标只有一个：创业。
面向工资编程
高中的时候喜欢踢球，班上有一个特别厉害的前锋，用我们对手的话就是：“挡也挡不住，跑也跑不过，绊都绊不倒”。
嗯，我认为的一个“全栈工程师”，不是仅仅能从汇编写到JavaScript，从PHP写到Objective-C。更是从代码到PhotoShop，从产品设计到地推样样行，样样懂。
从小了说，给他安排个你自己都没想太明白的任务，他给你一个惊喜。
从大了说，就是既能当CTO，又能当COO，没有各种CXO，自己也能当CEO。
==============分割线==============
说一个我一个朋友
的故事吧，我是在大三认识他的。当时我是学校论坛的系统管理员，正在招人接替我毕业后在学校的工作。招了好久没有入得了我法眼的，这时我师傅说找到一个不错的。
说实话，第一次见面我对他没啥好印象，因为这货抽烟，完全不像是一个搞技术的。后来一起通宵修理服务器，研究技术，慢慢发现这货是个挺有意思的人。
以后的日子里我带着他一起写Python，写C，写JS。。。我发现他就是那种能不断给我惊喜的工程师。。。
我们工作室的传统是，每年暑假大家都在学校做封闭开发，当时我找了个去IBM实习的机会，想让他替我留校。最后一聊，这货没空，暑假要骑自行车去西藏。。。我才发现他还是个文艺青年（当时还不是那么贬义）
后来，他到了大三，去的支付宝实习，做运维开发。
再后来跟我一样去了百度，不到三年时间，就升到了T6。。。
有一天无意发现这货豆瓣竟然有上万的粉丝，一问才知道，有一天他闲得无聊，写了篇骂豆瓣的产品的帖子，由于字字鞭辟入里，连豆瓣的产品同学都直呼骂得好（抖m的既视感），不断邀请他来豆瓣做产品，直到他亮出T6的身份，对方才作罢。
此人还对人文历史政治总有很多见解。每每觉得无聊，第一个想到拉他出来吃吃饭，每次都有新收获。
几个月前，他跟我说他前几天被一伙人拉着去融资了，那伙人是想搞云存储的，发现他对分布式存储很有研究，就生生拉上他去壮大阵容。。。
我就问，他们怎么知道你对这个有研究呢？这货拿起手中的加冰可乐，33.3°仰望天花板：“因为MooseFS有部分代码是我写的”。
后来才知道，这货已经是百度分布式存储&缓存Topic的负责人了。。。。
就在我为他要在技术的道路上超越我而惶惶不可终日的时候，有一天，他问我有没有兴趣回成都。。。
原来，这段时间他拉着几个学弟搞了个无节操（约XX）的叫“谁有空”的APP（啧啧，这名字。。），拿了几百万的融资，开始出任CEO，走向人生巅峰了。。。
他也教会我一件事，遇到比自己厉害的学弟，不要嫉妒，不要尝试去压制，因为“有些鸟注定是不会被关在笼子里的，它们的每一片羽毛都闪耀着自由的光辉”。可能有一天你就要去他公司打工呢。所以，过了这么久，我最喜欢的一个身份还是
曾经这个全栈工程师的“师傅”。
嗯，我认为的一个“全栈工程师”，不是仅仅能从汇编写到JavaScript，从PHP写到Objective-C。更是从代码到PhotoShop，从产品设计到地推样样行，样样懂。
从小了说，给他安排个你自己都没想太明白的任务，他给你一个惊喜。
从大了说，就是既能当CTO，又能当COO，没有各种CXO，自己也能当CEO。
==============分割线==============
说一个我一个朋友
的故事吧，我是在大三认识他的。当时我是学校论坛的系统管理员，正在招人接替我毕业后在学校的工作。招了好久没有入得了我法眼的，这时我师傅说找到一个不错的。
说实话，第一次见面我对他没啥好印象，因为这货抽烟，完全不像是一个搞技术的。后来一起通宵修理服务器，研究技术，慢慢发现这货是个挺有意思的人。
以后的日子里我带着他一起写Python，写C，写JS。。。我发现他就是那种能不断给我惊喜的工程师。。。
我们工作室的传统是，每年暑假大家都在学校做封闭开发，当时我找了个去IBM实习的机会，想让他替我留校。最后一聊，这货没空，暑假要骑自行车去西藏。。。我才发现他还是个文艺青年（当时还不是那么贬义）
后来，他到了大三，去的支付宝实习，做运维开发。
再后来跟我一样去了百度，不到三年时间，就升到了T6。。。
有一天无意发现这货豆瓣竟然有上万的粉丝，一问才知道，有一天他闲得无聊，写了篇骂豆瓣的产品的帖子，由于字字鞭辟入里，连豆瓣的产品同学都直呼骂得好（抖m的既视感），不断邀请他来豆瓣做产品，直到他亮出T6的身份，对方才作罢。
此人还对人文历史政治总有很多见解。每每觉得无聊，第一个想到拉他出来吃吃饭，每次都有新收获。
几个月前，他跟我说他前几天被一伙人拉着去融资了，那伙人是想搞云存储的，发现他对分布式存储很有研究，就生生拉上他去壮大阵容。。。
我就问，他们怎么知道你对这个有研究呢？这货拿起手中的加冰可乐，33.3°仰望天花板：“因为MooseFS有部分代码是我写的”。
后来才知道，这货已经是百度分布式存储&缓存Topic的负责人了。。。。
就在我为他要在技术的道路上超越我而惶惶不可终日的时候，有一天，他问我有没有兴趣回成都。。。
原来，这段时间他拉着几个学弟搞了个无节操（约XX）的叫“谁有空”的APP（啧啧，这名字。。），拿了几百万的融资，开始出任CEO，走向人生巅峰了。。。
他也教会我一件事，遇到比自己厉害的学弟，不要嫉妒，不要尝试去压制，因为“有些鸟注定是不会被关在笼子里的，它们的每一片羽毛都闪耀着自由的光辉”。可能有一天你就要去他公司打工呢。所以，过了这么久，我最喜欢的一个身份还是
曾经这个全栈工程师的“师傅”。
一年之后，终于可以真正的给这个问题一个答案。现有的高票的答案没有涉及到怎么成为全栈工程师。
实战篇
《GitHub - phodal/growth-in-action: 全栈增长工程师实战》
你将会看到：
理论篇
献上我写的电子书《GitHub - phodal/growth-ebook: Growth: 全栈增长工程师指南。Growth: Learning Full Stack》
实战篇
《GitHub - phodal/growth-in-action: 全栈增长工程师实战》
你将会看到：
- 如何去开发一个Web应用（博客）
- 如何编写单元测试、功能测试、自动化UI测试
- 搭建并使用持续集成
- 添加SEO支持——Sitemap、站长工具和Google Analytics
- 使用API，制作AutoComplete
- 开发相应的APP及其API——查看文章、用户登录、发表文章
- 制作单页面应用
- 自动化部署
理论篇
献上我写的电子书《GitHub - phodal/growth-ebook: Growth: 全栈增长工程师指南。Growth: Learning Full Stack》
魅族营销中心招募设计师
收录于 知乎周刊 ·
Full Stack Developer 在国内不被接受的一个主要原因是公司缺乏稳定的 T 线（技术职位晋升路线）。
太多有才华的人写了几年代码最后都去做了管理。而今天的网络相关技术，聪明又能持续学习的人，在三年之内可以在一个领域做到很高的水准。那么如果你做五年，十年甚至十五年呢？
我以为你成为 Full Stack Developer 是很自然的选择，而且可以跟随最顶尖的技术。这种人并不罕见，我认识的人中
就是个例子。相信 Full Stack Developer 的核心并非否定团队和协作，而是更多的体现在架构设计，快速原型和 TroubleShooting 方面。
随着今天的分层越来越清晰，平台和语言越来越有特点，更加全面的技术人员可以根据不同的语言搭建整个架构。
数据一致性要求高？那么使用事务管理久经考验的 Spring？还要考虑 scale ？那么放在 Oracle 里面做还是放在 Application Server 的 Transaction 管理里面做？简单请求的高并发？那么 Node.js 也许不错。 Web App 快速原型，那么 Rails 也许不错。邮件模板和自动发送？ PHP 有现成的东西为什么不用？前端数据和交互复杂？ 为什么不试试 emberjs （ PS ：选前端框架对于架构人员来说简直像女人逛银座一样令人兴奋。甚至有人用几乎所有的框架写了同样的 Web App 来供他们试用： TodoMVC）？想绕过苹果的 App Store 的审查机制频繁发布？可以考虑在 iOS Apps 里面嵌入 HTML5 。
Full Stack Developer 在快速原型上也很有优势，因为省去了大量的管理和沟通成本。而且，这并非就意味着一定在代码质量或者测试上有缩水。
MVC 前后都可以用。一个写过 test_helper.rb 的人做前端，一定会搜索 javascript TTD 。同样，用过 javascipt lint 的人一定可以找到 stylecheck 。语言和平台会变化，聪明的方法和工具都是共通的。懂得基本的字体知识和排版审美难道和 CSS 不是天生一对？
TroubleShooting 方面 Full Stack Developer 同样优势巨大。
服务器压力太大未必需要通过后端解决，优化个 SQL 写个 Hint 是选择，而拿一部分数据和运算到前端也许是更加合理和低成本的选择。一个系统运行多年，最后遗留的问题很可能需要对业务和技术都有深入理解的人才能解决。
从以上内容可以看出， Full Stack Developer 并非杂而全 - Facebook 也不会雇庸手。他要求的是一种更加全面的深入。 一方面，他是技术人员不断学习的结果。另一方面，他也是对自己事业的一种责任：
技术人员的价值不是指派做了一半的 issue 给队友，而是更快更好的搞定事情。
太多有才华的人写了几年代码最后都去做了管理。而今天的网络相关技术，聪明又能持续学习的人，在三年之内可以在一个领域做到很高的水准。那么如果你做五年，十年甚至十五年呢？
我以为你成为 Full Stack Developer 是很自然的选择，而且可以跟随最顶尖的技术。这种人并不罕见，我认识的人中
就是个例子。相信 Full Stack Developer 的核心并非否定团队和协作，而是更多的体现在架构设计，快速原型和 TroubleShooting 方面。
随着今天的分层越来越清晰，平台和语言越来越有特点，更加全面的技术人员可以根据不同的语言搭建整个架构。
数据一致性要求高？那么使用事务管理久经考验的 Spring？还要考虑 scale ？那么放在 Oracle 里面做还是放在 Application Server 的 Transaction 管理里面做？简单请求的高并发？那么 Node.js 也许不错。 Web App 快速原型，那么 Rails 也许不错。邮件模板和自动发送？ PHP 有现成的东西为什么不用？前端数据和交互复杂？ 为什么不试试 emberjs （ PS ：选前端框架对于架构人员来说简直像女人逛银座一样令人兴奋。甚至有人用几乎所有的框架写了同样的 Web App 来供他们试用： TodoMVC）？想绕过苹果的 App Store 的审查机制频繁发布？可以考虑在 iOS Apps 里面嵌入 HTML5 。
Full Stack Developer 在快速原型上也很有优势，因为省去了大量的管理和沟通成本。而且，这并非就意味着一定在代码质量或者测试上有缩水。
MVC 前后都可以用。一个写过 test_helper.rb 的人做前端，一定会搜索 javascript TTD 。同样，用过 javascipt lint 的人一定可以找到 stylecheck 。语言和平台会变化，聪明的方法和工具都是共通的。懂得基本的字体知识和排版审美难道和 CSS 不是天生一对？
TroubleShooting 方面 Full Stack Developer 同样优势巨大。
服务器压力太大未必需要通过后端解决，优化个 SQL 写个 Hint 是选择，而拿一部分数据和运算到前端也许是更加合理和低成本的选择。一个系统运行多年，最后遗留的问题很可能需要对业务和技术都有深入理解的人才能解决。
从以上内容可以看出， Full Stack Developer 并非杂而全 - Facebook 也不会雇庸手。他要求的是一种更加全面的深入。 一方面，他是技术人员不断学习的结果。另一方面，他也是对自己事业的一种责任：
技术人员的价值不是指派做了一半的 issue 给队友，而是更快更好的搞定事情。
前端开发、JavaScript、前端工程师 话题的优秀回答者
现有的答案已经说明了，以一个正常人的精力和学习速度来说，想在 full stack 的每一个层面都达到顶级的精通显然是很困难的事情。但是做不到这一点就算不上 full stack developer (FSD) 了吗？其实我希望大家留意题主引用的那段英文的最后一句：a genuine interest in all software technology. （对所有的软件技术抱有一种真挚的兴趣）。
我觉得对于 FSD ，尤其是对于想成为 FSD 的人来说，这个态度才是最重要的事情。即使都是 FSD，每一个人各自的技能加点也肯定会不一样，有人在前端更擅长一些，有人在服务器层面更有经验... 但其实没有什么硬性的门槛，需要的是解决任何问题的能力和意愿。你要做到的就是不固步自封在一个领域。遇到问题，就去研究，不因为问题不在你的 comfort zone 就放弃或者推给别人。即使一开始的解决方案很笨拙也无所谓，just learn whatever it takes to make it work. 比如说我要做一个网站，我有一些东西没碰过，但我有足够的兴趣和动力去搞个八九不离十。（这里自学能力很重要，有好的 mentor 也会帮助很大）当你经历过一次这个过程以后，你就会有信心去弄明白更复杂的东西，在之前的基础上进一步去消化、改进、学更多的东西。
另外，我个人觉得这个过程应该是由实际问题驱动的，而不是漫无目的看到什么东西流行了或者觉得很NB就去学。 的答案里提到绝大部分的网站都活不到或者永远也达不到10k用户在线的水平，那种情况下去看 high scalability 的东西有什么意义？学的东西用来解决或是改进实际遇到的问题，这样你的整个知识体系覆盖面和侧重点会比较合理。打个比方就是你的技能点有限，所以加点方案得有一个主题，到处乱点的话就废了。
我觉得对于 FSD ，尤其是对于想成为 FSD 的人来说，这个态度才是最重要的事情。即使都是 FSD，每一个人各自的技能加点也肯定会不一样，有人在前端更擅长一些，有人在服务器层面更有经验... 但其实没有什么硬性的门槛，需要的是解决任何问题的能力和意愿。你要做到的就是不固步自封在一个领域。遇到问题，就去研究，不因为问题不在你的 comfort zone 就放弃或者推给别人。即使一开始的解决方案很笨拙也无所谓，just learn whatever it takes to make it work. 比如说我要做一个网站，我有一些东西没碰过，但我有足够的兴趣和动力去搞个八九不离十。（这里自学能力很重要，有好的 mentor 也会帮助很大）当你经历过一次这个过程以后，你就会有信心去弄明白更复杂的东西，在之前的基础上进一步去消化、改进、学更多的东西。
另外，我个人觉得这个过程应该是由实际问题驱动的，而不是漫无目的看到什么东西流行了或者觉得很NB就去学。 的答案里提到绝大部分的网站都活不到或者永远也达不到10k用户在线的水平，那种情况下去看 high scalability 的东西有什么意义？学的东西用来解决或是改进实际遇到的问题，这样你的整个知识体系覆盖面和侧重点会比较合理。打个比方就是你的技能点有限，所以加点方案得有一个主题，到处乱点的话就废了。
再见小男孩
名词定义：
以及其他类似的泼冷水答案，FSD并不需要在每个领域都学到精通的程度，领域专家和FSD是压根儿就是拿来做不同的事情的。对于互联网公司来说，一个项目刚开始的时候叫几个FSD就可以非常快地写个poc甚至直接发布，流量上去以后再考虑安全或性能隐患，慢慢交予领域专家在后期调整优化。考虑到大部分项目的生命周期和用户数量，上面这句话的后半部分根本不会发生。引用一句话：the bigger problem isn’t scaling, it’s getting to the point where you have to scale。不知道马同学所谓的高水平公司都有哪些，可能都是外包公司吧。因为对于互联网公司来说，他提到的问题基本都属于premature optimisation。比如：
建一个VPS还非得精通到怎么搞机房和数据中心？以现在的硬件条件稍微高配一点的VPS跑一个在线人数10K的网站+DB问题也不大。国内有多少网站在线人数超过10K了？对于大部分的网站要CCNP/CCNA干嘛？
ORM性能差就要用native sql? 重写了一遍以后每个request平均能省下多少ms? 你的用户在乎这点时间吗？值得那么多重写和测试的￥￥么？ 现在确实native sql确实又开始火了，但本质原因还是方便，根本不是性能问题。
还有很多，不一一反驳了。
下面回到楼主的问题，我认为成为FSD的想法非常好。因为成为FSD意味着具备了单人创业的能力。而且随着框架越来越强，互联网创业团队(包括intraprenuer)越来越小，FSD的前景其实远远超过领域专家。（这句话是个人观点，5年以后再回来看）
那么如何成为FSD呢？很简单也很难：自己去做一个网站，并维护它。
- FSD = full stack developer
- 领域专家 = 和FSD相对，表示精通且只精通单一领域的大牛（暂时想不出更好的名字了）
- 互联网公司 = 通过互联网产品本身的运行来产生现金流。例如百度，Dropbox
- 外包公司 = 根据客户需求来订制产品然后整体卖给客户。项目本身的现金流和公司没有关系。例如东软。
以及其他类似的泼冷水答案，FSD并不需要在每个领域都学到精通的程度，领域专家和FSD是压根儿就是拿来做不同的事情的。对于互联网公司来说，一个项目刚开始的时候叫几个FSD就可以非常快地写个poc甚至直接发布，流量上去以后再考虑安全或性能隐患，慢慢交予领域专家在后期调整优化。考虑到大部分项目的生命周期和用户数量，上面这句话的后半部分根本不会发生。引用一句话：the bigger problem isn’t scaling, it’s getting to the point where you have to scale。不知道马同学所谓的高水平公司都有哪些，可能都是外包公司吧。因为对于互联网公司来说，他提到的问题基本都属于premature optimisation。比如：
建一个VPS还非得精通到怎么搞机房和数据中心？以现在的硬件条件稍微高配一点的VPS跑一个在线人数10K的网站+DB问题也不大。国内有多少网站在线人数超过10K了？对于大部分的网站要CCNP/CCNA干嘛？
ORM性能差就要用native sql? 重写了一遍以后每个request平均能省下多少ms? 你的用户在乎这点时间吗？值得那么多重写和测试的￥￥么？ 现在确实native sql确实又开始火了，但本质原因还是方便，根本不是性能问题。
还有很多，不一一反驳了。
下面回到楼主的问题，我认为成为FSD的想法非常好。因为成为FSD意味着具备了单人创业的能力。而且随着框架越来越强，互联网创业团队(包括intraprenuer)越来越小，FSD的前景其实远远超过领域专家。（这句话是个人观点，5年以后再回来看）
那么如何成为FSD呢？很简单也很难：自己去做一个网站，并维护它。
知乎用户
写 code
折腾之魂永不停息的人，最后就容易变成 full stack.
另外，在学校里写东西，找人巨难，这造就了一批 full stack 小伙伴. 有一次搞一个 html5 的比赛，到后来快要deadline时，前端明显要搞不完了，作为一个野生前端，怒刷了一天 js 后开始填坑.
有时候因为找不着人，还可以临时变身美攻（当然你也可以叫设计湿），然后客串一下 ios 客户端开发，设计个数据库…… 最后小伙伴们所有东西都搞完，你再从头到尾把他们搞的东西擦一遍屁股，然后需要宣传/比赛的话，海报/视频/演讲/slides/文档都是你的事，最后就成了 full stack 了.
你看，full stack 都是苦逼的人（你看这还只是学校里的 full stack，要是工作上成了 full stack 那就不定啥样了）. 想想好像没必要匿…，就不匿了吧.
另外，在学校里写东西，找人巨难，这造就了一批 full stack 小伙伴. 有一次搞一个 html5 的比赛，到后来快要deadline时，前端明显要搞不完了，作为一个野生前端，怒刷了一天 js 后开始填坑.
有时候因为找不着人，还可以临时变身美攻（当然你也可以叫设计湿），然后客串一下 ios 客户端开发，设计个数据库…… 最后小伙伴们所有东西都搞完，你再从头到尾把他们搞的东西擦一遍屁股，然后需要宣传/比赛的话，海报/视频/演讲/slides/文档都是你的事，最后就成了 full stack 了.
你看，full stack 都是苦逼的人（你看这还只是学校里的 full stack，要是工作上成了 full stack 那就不定啥样了）. 想想好像没必要匿…，就不匿了吧.
汇集阿里技术精粹！微信号yunqiinsight
看到已经有很多小伙伴分享了成为全栈工程师的答案，小编特在此贡献一篇全栈架构师的内容，以供大伙扩展：
老曹眼中的全栈架构师-博客-云栖社区-阿里云
看一下工程师和架构师的区别，简单地，工程师关注的是功能和代码性能，而架构师关注的是业务和系统的性能等非功能性约束。全栈不是全能，只要覆盖了所使用的技术栈就是全栈，例如LNMP，Linux＋Nginx＋Mysql＋PHP。全栈架构师关注的是业务所采纳的全部技术栈，以及技术栈所涉及的系统性能、安全，高可用等诸多因素。
全栈（full stack developer）好像起源于facebook中对工程师的一种称谓，全栈架构师估计是老曹的杜撰。全栈的出现大概有4个方面：系统的性能瓶颈定位，团队间的沟通障碍，业务的救火灭火，以及团队的资源紧张。尤其的小型创业团队，战力的有限会导致全栈的产生。
和习武一样，我想试图探讨一下全栈的套路，很多能力不是通过当头棒喝产生的。郭大侠需要降龙十八掌，令狐冲以无招胜有招也需要独孤九剑。我觉得全栈的技术栈可以主要分为3个切面：技能，性能 和效率。下面逐一简要阐述：
全栈应该掌握4种编程语言：Java，Objc/C/C++, Python，JavaScript。 语言没有优劣，不同语言有各自的胜场。
从下向上看一下 全栈的所需技能，第一个就是操作系统，可参考《老曹眼中的Linux基础》。
数据是系统的核心，必须要了解文件系统，对象存储和关系型数据库，只有NoSQL至少要关注redis和mongodb，更多可以可参考《NoSQL与大数据》。
网络是一个覆盖更广的领域，至少要了解七层协议模型，DNS，TCP/IP，HTTP，以及网络类型对网络编程的影响，会上只有简单举例，以后择机仔细探讨一下。
安全是个与非门，没事一切都好，有事就是大事。基本上，可以从传输，网络，代码和数据四个层面掌握有关安全的基础知识。
至于架构方法，现在最热的莫过于微服务架构了。服务的划分与业务密切相关，服务独立后要考虑服务的发现和服务间的通信，最后是服务治理，可以从这四个方面专研相关的技术。
云服务的出现使得小团队可以做大事情，关于混合云的解释可参考老曹的旧文《理解一下混合云》。
从趋势来看，大数据必将成为工程师团队的重要战力，包括专业知识，数学算法，计算环境三个方面。就计算环境而言，涵盖了Hadoop的生态圈，如果只有一个必备技能，老曹觉得就应该是Spark了，可以参考《架构大数据应用》旧文。
个人以为，性能在诸多非功能性约束中第一重要，直接影响用户体验。首先要从业务和代码层面保障性能，而单元测试是一个必要条件。正像PingCAP CTO 黄东旭所说的，“talk is cheap， show me the tests."
接下来是运行时调优，或者认为是单机性能。从加载和依赖开始，到 JVM调优，再到Linux 内核参数调优。 对于 JVM 调优，给朋友做个广告，中生代技术群中的 江南白衣 （公众号：春天的旁边）有一篇干货文章，特别向大家推荐。
数据库是整个系统中的慢性子，关注系统的性能，日志分析比不可少，LEK可能是第一首选。数据访问必须是高可用的，数据连接池的选择和使用都是考验功夫的。
缓存是减少负载，提高系统性的必备技术。可以从客户端，网络侧，服务端三个环节对缓存进行分类，具体可以参考《老曹眼中的缓存技术》。
负载均衡同样是一种以空间换时间的技术，具体可参考《老曹眼中的负载均衡》。
传输的性能可以依靠消息队列来提升，ZeroMQ可以用在系统内，而ActiveMQ是Java 程序猿的福音，对于高并发和高容错而言，RabbitMQ可能是不错的选择，Kafka是大量数据的传输必备。
啰哩啰嗦，只是想探讨一下全栈的套路，也许这本身就是一个伪命题。 延展阅读： 为什么未来是全栈工程师的世界？-博客-云栖社区-阿里云
技术在过去的几十年里进步很快，也将在未来的几十年里发展得更快。今天技术的门槛下降得越来越快，原本需要一个团队做出来的Web应用，现在只需要一两个人就可以了。
同时，由于公司组织结构的变迁，也决定了赋予每个人的职责将会越来越多。尽管我们看到工厂化生产带来的优势，但是我们也看到了精益思想带来的变革。正是这种变革让越来越多的专家走向全栈，让组织内部有更好的交流。
你还将看到专家和全栈的两种不同的学习模式，以及全栈工程师的未来。
技术的革新史
从开始的CGI到MVC模式，再到前后端分离的架构模式，都在不断地降低技术的门槛。而这些门槛的降低，已经足以让一两个人来完成大部分的工作了。
CGI
二十年前的网站以静态的形式出现，这样的网站并不需要太多的人去维护、管理。接着，人们发明了CGI(通用网关接口，英语：Common Gateway Interface)来实现动态的网站。下图是一个早期网站的架构图：
当时这种网站的URL类似于： https://www.phodal.com/cgi-bin/getblog
(PS：这个链接是为了讲解而存在的，并没有真实存在。)
用户访问上面的网页的时候就会访问，cgi-bin的路径下对应的getblog脚本。你可以用Shell返回这个网页：
123 #!/bin/sh echo Content-type: text/plain echo hello,world
Blabla，各种代码混乱地夹杂在一起。不得不说一句：这样的代码在2012年，我也看了有一些。简单地来说，这个时代的代码结构就是这样的：
这简直就是一场恶梦。不过，在今天好似那些PHP新手也是这样写代码的。
好了，这时候我们就可以讨论讨论MVC模式了。
MVC架构
我有理由相信Martin Fowler的《企业应用架构模式》在当时一定非常受欢迎。代码从上面的耦合状态变成了：
相似大家也已经对这样的架构很熟悉了，我们就不多解释了。如果你还不是非常了解的话，可以看看这本书后面的部分。
后台服务化与前端一致化架构
在今天看来，我们可以看到如下图所示的架构：
后台在不知不觉中已经被服务化了，即只提供API接口和服务。前端在这时已经尽量地和APP端在结合，使得他们可以保持一致。
软件开发的核心难题：沟通
软件开发在过去的几十年里都是大公司的专利，小公司根本没有足够的能力去做这样的事。在计算机发明后的几十年里，开发软件是大公司才能做得起的。一般的非技术公司无法定制自己的软件系统，只能去购买现有的软件。而随着技术成本的下降，到了今天一般的小公司也可以雇佣一两个人来做同样的事。这样的演进过程还真是有意思：
在这其中的每一个过程实质上都是为了解决沟通的问题。从瀑布到敏捷是为了解决组织内沟通的问题，从敏捷到精益不仅仅优化了组织内的沟通问题，还强化了与外部的关系。换句话说，精益结合了一部分的互联网思维。
瀑布式
在最开始的时候，我们预先设计好我们的功能，然后编码，在适当的时候发布我们的软件：
然而这种开发方式很难应对市场的变化——当我们花费了几年的时间开发出了一个软件，而这个软件是几年前人们才需要的。同时，由于软件开发本身的复杂度的限制，复制的系统在后期需要大量的系统集成工作。这样的集成工作可能要花费上大量的时间——几星期、几个月。
当人们意识到这个问题的时候，开始改进工作流程。出现了敏捷软件开发，这可以解释为什么产品经理会经常改需求。如果一个功能本身是没必要出现的话，那么为什么要花功夫去开发。但是如果一个功能在设计的初期就没有好好设计，那么改需求也是必然的。
敏捷式
现有的互联网公司的工作流程和敏捷软件开发在很多部分上是相似的，都有迭代、分析等等的过程：
但是据我的所知：国内的多数互联网公司是不写测试的、没有Code Review等等。当然，这也不是一篇关于如何实践敏捷的文章。敏捷与瀑布式开发在很大的区别就是：沟通问题。传统的软件开发在调研完毕后就是分析、开发等等。而敏捷开发则会强调这个过程中的沟通问题：
在整个过程中都不断地强调沟通问题，然而这时还存在一个问题：组织结构本身的问题。这样的组织结构，如下图所示：
如果市场部门/产品经理没有与研发团队坐一起来分析问题，那么问题就多了。当一个需求在实现的过程中遇到问题，到底是哪个部门的问题？
同样的如果我们的研发部门是这样子的结构：
那么在研发、上线的过程中仍然会遇到各种的沟通问题。
现在，让我们回过头来看看大公司的专家与小公司的全栈。
大公司的专家与小公司的全栈
如果你经常看一些关于全栈和专家的技术文章的时候，你就会发现不同的人在强调不同的方向。大公司的文章喜欢强调成为某个领域的专家，小公司喜欢小而美的团队——全栈工程师。
如我们所见的：大公司和小公司都在解决不同类型的问题。大公司要解决性能问题，小公司都活下去需要依赖于近乎全能的人。并且，大公司和小公司都在加班。如果从这种意义上来说，我们可以发现其实大公司是在剥削劳动力。
专家
我们所见到的那些关于技术人员应该成为专家的文章，多数是已经成为某个技术领域里的专家写的文章。并且我们可以发现很有意思的一点是：他们都是管理者。管理者出于招聘的动机，因此更需要细分领域的专家来帮助他们解决问题。
全栈
相似的，我们所看到的那些关于成为全栈工程师的文章，多数是初创公司的CTO写的。而这些初创公司的CTO也多数是全栈工程师，他们需要招聘全栈工程师来帮助他们解决问题。
两种不同的学习模型
而不知你是否也注意到一点：专家们也在强调“一专多长”。因为单纯依靠于一个领域的技术而存在的专家已经很少了，技术专家们不得不依据于公司的需求去开拓不同的领域。毕竟“公司是指全部资本由股东出资构成，以营利为目的而依法设立的一种企业组织形式；”，管理人们假设技术本身是相通的，既然你在技术领域里有相当高的长板，那么进入一个新的技术也不是一件难的事。
作为一个技术人员，我们是这个领域中的某个子领域专家。而作为这样一个专家，我们要扩展向另外一个领域的学习也不是一件很难的事。借鉴于我们先前的学习经验，我们可以很快的掌握这个新子域的知识。如我们所见，我们可以很快地补齐图中的短板：
在近来的探索中发现有一点非常有意思：如果依赖于20/80法则的话，那么成为专家和全栈的学习时间是相当的。在最开始的时候，我们要在我们的全栈工程和专家都在某个技术领域达到80分的水平。
那么专家，还需要80%的时间去深入这个技术领域。而全栈工程师，则可以依赖于这80%的时候去开拓四个新的领域：
尽管理论上是如此，但是专家存在跨领域的学习障碍——套用现有模式。而全栈也存在学习障碍——如何成为专家，但是懂得如何学习新的领域。
解决问题的思路：不同的方式
有意思的是——成为专家还是成为全栈，取决于人的天性，这也是两种不同的性格决定的。成为管理者还是技术人员看上去就像一种简单的划分，而在技术人员里成为专家还是全栈就是另外一种划分。这取决于人们对于一个问题的思考方式：这件事情是借由外部来解决，还是由内部解决。下面这张图刚好可以表达我的想法：
而这种思维依据于不同的事情可能会发生一些差异，但是总体上来说是相似的。当遇到一个需要创轮子的问题时，我们就会看到两种不同的方式。
对于全栈工程师来说，他们喜欢依赖于外部的思维，用于产生颠覆式思维。如Angular.js这样的框架便是例子，前端结合后端开发语言Java的思维而产生。而专家则依赖于内部的条件，创造出不一样的适应式创新。如之前流行的Backbone框架，适应当时的情况而产生。
全栈工程师的未来：无栈
全栈工程师本身不应该仅仅局限于前端和后台的开发，而可以尝试去开拓更广泛的领域——因为全栈本身是依赖于工程师本身的学习能力，正是这种优秀的学习能力可以让他们可以接触更广泛的知识。
全栈的短板
如果你也尝试过面试过全栈工程师，你会怎么去面试他们呢？把你知道的所有的不同领域的问题都拿出来问一遍。是的，这就是那些招聘全栈工程师的公司会问你的问题。
人们以为全栈工程师什么都会，这是一个明显的误区——然而要改变这个误区很难。最后，导致的结果是大家觉得全栈工程师的水平也就那样。换句来说，人们根本不知道什么是全栈工程师。在平时的工作里，你的队伍都知道你在不同领域有丰富的知识。而在那些不了解你的人的印象里，就是猜测你什么都会。
因此，这就会变成一个骂名，也是一个在目前看来很难改变的问题。在这方面只能尽可能地去了解一些通用的问题，并不能去了解所有的问题。在一次被面试全栈工程师的过程中，有一个面试官准备了几个不同语言（Javascript、Java、Python、Ruby)的问题来问我，我只想说Ciao——意大利语：你好！
除了这个问题——人们不了解什么是全栈工程师。还有一个问题，就是刚才我们说的成为专家的老大难问题。
无栈
让我毫不犹豫地选择当全栈工程师有两个原因：
中小学：编程语言 -> 高中：操作系统、内核、游戏编程 -> 大学： 硬件、Web开发 -> 工作：后端 + 前端
而在当时我对SEO非常感兴趣，我发现这分析和Marketing似乎做得还可以。然后便往Growth Hacking发展了：
而这就是全栈学习带来的优势，学过的东西多，学习能力就变强。学习能力往上提的同时，你就更容易进入一个新的领域。
程序员：如何成为一个全栈的工程师？-博客-云栖社区-阿里云
全栈工程师，英文 Full Stack developer，是指那些掌握多种技能，并能利用多种技能独立完成产品的人。当然，现在「全栈工程师」很吃香，非常吃香！这是因为在移动互联网时代，IT 系统变得愈加复杂，需要拥有全局思维的工程师来搞定各种「疑难杂症」。不仅要玩得转前端，还要搞得定后端，总之各种技术都懂，所以其重要性可见一斑。
近日，移动开发精英俱乐部围绕「如何成为一个全栈的工程师？」进行了讨论，主持人是优才学院的创始人伍星老师，让我们一起看看大神们的精彩言论吧！（本文系国内 ITOM 管理领军企业 OneAPM 工程师整理）
程序员眼中的「全栈」
伍星-优才创始人：全栈，最早来自于 Facebook 的「我们只招全栈工程师」，从表面看是指技术栈，是完成一套产品所面要的全部技术和技能。谷歌在它的书中也提出，它们只招创意型人才，其实这是一致的、相通的！
饶培泽：全栈，在我看来是一种态度，无路遇到何种问题都能积极的去解决。全栈，也不是说会什么，而是因为有好奇心与驱动力，所以什么都想搞明白，学习起来自然能快速上手。
iOS小码哥：全栈，也可以说「我是一块砖，哪儿需要我，我就往哪儿填。」代表着快速学习的能力和超强的适应能力。
梦航：全栈，在一定程度上能更好的做出架构，减少维护成本。
卓竞劲：我支持思想和知识层面的「全栈」，而非刻意技能上的全栈。
饶培泽：其实，能从前端写到后端的人不少，但是能专职来做吗？这么说吧，很多公司的后端都能写前端，但可不敢让他们写产品级别的代码。如果后端人才如果能去了解前端的知识点，合理去进行整合互补，这样是我们所鼓励的。
药交汇：全栈围绕产品服务，重点是考虑问题的角度、广度。个人理解也可以看成责任感的一种体现，前端、后端都可以也不代表全栈。只不过是围绕着问题的解决方案，其根本还是本着对一件事情负责的态度，展开全方面的跟踪。
伍星-优才创始人：从谷歌对创意型人才的描述可以看出，这更多体现在能够主动地承担工作和解决问题。比如谷歌讲过一个例子，Adwords 是几个非相关工程师主动解决了小问题带来大收益的。
Facebook 的人才培养一开始是不分工的，「新兵营」之后才分工，并且轮岗很多，这中间暗含了：学习能力要相当强，我想学什么，都能学什么，需要我做什么，都能胜任。
所以我们对全栈提出如下见解。首先要技术全面，作为全栈工程师，其技术当然要比较全面。从前端到后端、从运维到优化、从 PC 到移动都难不倒。 但又有自己比较精通的一方面。也就是说，作为全栈工程师既要有「专深」，同样也要有「广博」，这样才能在解决问题时不受局限，才能融会贯通。
第二就是思维和心态。全栈工程师以积极主动的姿态来面对和解决工作中的问题。以全局的观点来看待自己所从事的项目， 而不只是自己负责的一小部分。以做成产品、做成一件事的观点来看待整个开发流程，而不仅仅是技术实现。 因为只能这样的心态和观点，他才会积极主动地去学习其他技术，用其他技术解决问题
第三是上升能力，全栈工程师并不意味着全能，什么都会。但是全栈工程师有良好的基础技能。 这个技能，既包括计算机科学的基础，也包括英语基础，有了这个基础， 加上积极的态度，开放的心胸，就能快速地学习所需要的技术，比如像 Swift 语言，那都不是事儿。 并应用在所需要的开发工作中。
第四就是职业价值，像 Facebook 说，他们只喜欢全栈工程师，创业公司也会说，我们需要全栈工程师。无论是在大公司，还是创业公司， 全栈工程师都将成为抢手人才！那是因为，全栈工程师不但技能全面，而且心态积极，学习能力强！
伍星-优才创始人：所以全栈不是一种技能，而是一种能力。学习能力，开放心态是优先的！
李睿君：其实后面有段时间觉得全栈需要一方面熟悉自己本身专业的领域，另一方面需要关注另一段的技术，这样在需要另一端技术，或是沟通时都能有帮助
着建彬：对感兴趣的东西不要当成「工作」来做，其实兴趣才是最大的动力。我觉得全栈应该是由「兴趣」驱动的。
伍星-优才创始人：即使是领域专家，他对别的也会有了解和研究的。优秀的技术人员，对所有的技术应该有一种天然的好奇心和折腾劲
药交汇：我前端和后端都经历过，其实，在前期人员不全的情况下，结合业务并外出调研梳理了产品线框图、PRD、流程图，到制定了设计规范，到协调资源，然后制定研发周期，最后到输出...... 曾一度以为这就是全栈，但是后来思考，这些只不过是本着对事情负责的态度，才驱动做了很多研发之外的事。就算一个人的技术全栈精通也要服务于根本产品。
伍星-优才创始人：项目进度和管理，比全栈本身要难。因为技术还是死的，人是活的，而且多种多样的。就像业务架构师，本身曾经技术应该不错，即使学新技术，应该也是有特殊长处和见解的，不过不学不写罢了。这种人是标准的技术 leader ，技术能力并不一定是以某特定语言的写码能力而界定。
一般而言，全栈工程师在产品和沟通这块都有优势，由于技术全面，他能和各方沟通的比较愉快 。甚至和产品经理也沟通好。我也算是一个全栈，此前和各个产品经理沟通都很愉快。因为他不理解的地方，我会和他讲清楚，分析清楚，为什么这个不能做，为什么那样做不好，那样做更好，有理有据，其实，产品经理也是讲道理的，不像我们在网络上经常「吐槽」的那样。如果再加上本身的技术声望和良好沟通的方式，程序员和产品经理相处其实会很和谐的。
如果成为一个全栈工程师？程序员：如何成为一个全栈的工程师？-博客-云栖社区-阿里云
王威：我的理解是，不仅自己领域的精通，然后其他部分也应该快速学习。在我看来，如果想成为全栈的话，还得靠上项目了。在普通公司的话，一般每个人只关注自己的领域，对跨领域的项目一般不会碰，可以自己利用业余时间来写，比如原本做APP的，有空可以写一下后端的东西，其实开始那一步比较困难。
张洋：全栈不只是技术，还需要心态、责任等方方面面。
江月：我觉得 facebook 要求全栈，并不是希望程序员技术全面但不精通。而是至少有一个领域精通，而且可以快速研究另外一个领域的技术点。
伍星-优才创始人：能成为全栈，意味着技术能达到一定高度，而高度，肯定是以长处见知的。我个人更倾向于认为，一专多能。
王威：成为全栈的话，还得靠上项目了。。。在普通公司的话，一般每个人只关注自己的领域，对跨领域的项目一般不会碰，自己私下来写，比如原本做 APP 的，自己私下写后端的东西，其实开始那一步比较困难。
药交汇：关键是责任感的转变，由「被动」到「主动」，才能实现自我超越。
拯救与逍遥：我个人看法，不是先有了「我要成为全栈」的目标，而是对技术的好奇和追求，以及积极应对当前业务发展的不断挑战，最终才能锻炼出了全栈。
薄建业：我觉得，最好的方法就是项目驱动；从另一方面也说明，说为全栈，在一定程度上，也是被逼出来的。
王威：我比较赞成项目驱动型。比如 APP 端的，例如做个类似于云笔记的软件，那么后端数据该怎么保存，接口该怎么定，该用哪种语言来实现后端，在分析你想要的目标的时候就能找到该用哪种技术该学哪种技术。比如后端用 PhP 写，这时候就会推动自己去学 PHP，比如自己是做安卓，那么语言衔接上，有可能选择 JAVA 做后端，这时候就学 J2EE 的东西，围绕这个需求来实现，然后学数据库......其实说到底还是得有」目标项目」来进行推动。
林曦：后端概念太泛了，不同业务需求和规模需要的技术支撑完全不同。
王威：比如做高并发，可以 NodeJs 、 Golang 、 Erlang ，或者干脆用 Java、PHP 等等。其实做项目的第一步，后端写出业务服务接口，在业务量上来之后考虑比如性能优化，比如负载均衡，或者再比如后端架构分层等等。
文彦峰：其实，接入也有很多要做的，一般要和终端一起做，路由、负载、流量控制、安全、监控、旁路、优化 TCP 协议栈、内核参数再到硬件的支持等等。做业务，比如网关、鉴权、微服务框架、服务治理、缓存、消息中间件；存储，单机房如何保证数据不丢，多机房是单向同步，双向同步，出了异常怎么通过日志恢复，数据的检查，静态检查点的选择。怎么做分片，怎么扩容不影响原来的分片？
王威：所以说到底还是得有这个项目需求，围绕着需求来分析需要的技术，然后再研究技术了。感觉纯按照兴趣来学新的技术，作为对这一个技术有个优缺点简要了解，在需要的时候能快速学习。我个人还是觉得，想成为一个「全栈」，就找一个想法并实现它。
周渊：比如，你觉得 NBA 好看，想要做一个 APP 能提醒比赛，那么每天下班后，没事写几个小时代码，三个月后，你就会发现做成了。
林曦：我觉得做个「入门型」的全栈比较容易，真正能做到都有一定深入的了解很难，融会贯通更难。
拯救与逍遥：先自学基础入门，进阶的话，可以随公司项目，初期不能直接参与，但是我们可以主动思考技术方案，然后参照其他同事最后落地的方案，对比总结。能力慢慢提升，真正上手的机会总会有的！
周渊：最重要就是，Just Do It ！
林曦：不过大公司相对有一个好处，就是能遇到「牛人」的概率也比较高，所以开发过程中，某一个部分遇到瓶颈的时候想要找人讨论或者请教，找他们也是比较好找的。
周渊：高人点拨，确实重要，但是建立在你入门的基础上。
拯救与逍遥：很多时候，我们不能做最想做的事情，而且要停下来推动一下，阻碍我们继续前行的事情。但是，有些坑，有些历练是必须的，别人说一万遍，我们还是得自己历练。而且很多技术选型，都是在真正落地之后，才暴露出问题。
王威：采坑是必然的！运气好的话，采坑的代价低，运气不好的话，采坑代价可能毁掉整个项目。不过有些坑，有可能是在技术选型的时候就会暗含的，这个时候确实不好找。
王威：我们业务在往图数据迁移的时候也踩了很多坑，因为我们是社交软件，所以很多需求是基于用户关系的，比如喜欢、不喜欢、好友等等。。。最开始觉得 neo4j 挺方便的，导入数据的时候发现，免费版就是个坑爹的玩具。。。收费版貌似5千刀一个月还说多少，巨贵。。。
王威：创业有这个好处就是人少，一个人当多个人用，这个时候就有很多机会去摸新的东西，不过缺点就是没人带，自己摸石头采坑。。。
王威：不过对于我来说收益大于采坑风险。。。所以还是得围绕这个需求，一圈一圈的挖掘更好的解决方式，这个是一种学习的过程。尤其是在风险可控范围内，绝对鼓励大家尝试新的东西。
到最后你的选择很多时候依赖你团队的水平，怎么把这些人水平带起来，你这些才能做细
最好的成长就是在业务中成长
林曦：架构也是活的，需要不断生长，不断修改。不过，前期埋的坑也只有后期加班吞了，没有一劳永逸的架构！
董飞：我觉得重要的还是分享，别人帮你填了坑，你也可以帮别人填坑。而媒介就是博客，大家可以互帮互助。
王威：说到写博客，我觉得可以把思维给规范化，把想法记录下来的同时还能注意到以前没注意到得细节，绝对是学习新姿势最必要的补充。
伍星-优才创始人：曾经，我就主动地提出来帮公司承担一些的运维方面的事情。然后就自己学习，请教，后来很自然地就成为全栈了。当然，全栈并不意味着上班学别的，我们上班时间把公司的事情做好，这才是成为全栈的前提。
伍星-优才创始人：还有一点，就是我们在写代码的过程中，要考虑怎么优化，怎么写得更快更好，而不是像「搬砖」似的，简单的重复。「搬砖」工作很快就会被淘汰掉，积累核心竞争力才是发展的根本 。
王威：比如做APP，在写从服务端拉取数据的时候，就可以考虑一下他们为什么要提供这样的数据结构？这样的接口如何进行实现的？有这些疑问的时候，就会促进自己去看看去了解一下相关的知识，这样才能不断通向全栈之路。
当然，完成是一码事儿，完成好是另一码事儿。全栈的意义不是全都泛泛地去做，而是在做深自己的领域同时，也能借鉴其他的技术，至少在团队开发时候沟通成本会减少很多。
赵建彬：其实，产品并不会关心你代码怎么写，关键自己要写出让自己觉得满意的、高质量的代码。
薄建业：全站人才可以站在更高的视角，提供「一揽子」的解决方案，避免踩深坑！
文彦峰：热衷于技术，成全栈是早晚的事儿，技术全面某方面又比较深入，自然能解决别人解决不了的问题，能做别人做不了的事情，团队中的影响力，行业中的影响力，也自然就有了，形成正向循环，还是挺不错的！
伍星-优才创始人：就像罗辑思维跨年公开课说的那样，核心竞争力，就是你的不可替代性。我们不能单纯地说「全栈」好，很多初学者会被误导，是因为他们不了解什么是全栈，怎么才能成为全栈。就像武功也有练「走火入魔」的。
其实，加入一个快速成长的团队创业。是成为全栈的最快捷途径。这个团队，也可能是大公司内部创业团队。也可能是大家都把工作当作创业的团队。而没有好奇心，没有折腾劲，没有学习能力，没有开放心态，是不可能成为全栈的！
http://quanzhan.ucai.cn/intro （本文是优才学院创始人伍星对全栈的理解，发布后2014年4月份，到现在也没有改变，欢迎大家阅读。）
看一下工程师和架构师的区别，简单地，工程师关注的是功能和代码性能，而架构师关注的是业务和系统的性能等非功能性约束。全栈不是全能，只要覆盖了所使用的技术栈就是全栈，例如LNMP，Linux＋Nginx＋Mysql＋PHP。全栈架构师关注的是业务所采纳的全部技术栈，以及技术栈所涉及的系统性能、安全，高可用等诸多因素。
全栈（full stack developer）好像起源于facebook中对工程师的一种称谓，全栈架构师估计是老曹的杜撰。全栈的出现大概有4个方面：系统的性能瓶颈定位，团队间的沟通障碍，业务的救火灭火，以及团队的资源紧张。尤其的小型创业团队，战力的有限会导致全栈的产生。
和习武一样，我想试图探讨一下全栈的套路，很多能力不是通过当头棒喝产生的。郭大侠需要降龙十八掌，令狐冲以无招胜有招也需要独孤九剑。我觉得全栈的技术栈可以主要分为3个切面：技能，性能 和效率。下面逐一简要阐述：
全栈应该掌握4种编程语言：Java，Objc/C/C++, Python，JavaScript。 语言没有优劣，不同语言有各自的胜场。
从下向上看一下 全栈的所需技能，第一个就是操作系统，可参考《老曹眼中的Linux基础》。
数据是系统的核心，必须要了解文件系统，对象存储和关系型数据库，只有NoSQL至少要关注redis和mongodb，更多可以可参考《NoSQL与大数据》。
网络是一个覆盖更广的领域，至少要了解七层协议模型，DNS，TCP/IP，HTTP，以及网络类型对网络编程的影响，会上只有简单举例，以后择机仔细探讨一下。
安全是个与非门，没事一切都好，有事就是大事。基本上，可以从传输，网络，代码和数据四个层面掌握有关安全的基础知识。
至于架构方法，现在最热的莫过于微服务架构了。服务的划分与业务密切相关，服务独立后要考虑服务的发现和服务间的通信，最后是服务治理，可以从这四个方面专研相关的技术。
云服务的出现使得小团队可以做大事情，关于混合云的解释可参考老曹的旧文《理解一下混合云》。
从趋势来看，大数据必将成为工程师团队的重要战力，包括专业知识，数学算法，计算环境三个方面。就计算环境而言，涵盖了Hadoop的生态圈，如果只有一个必备技能，老曹觉得就应该是Spark了，可以参考《架构大数据应用》旧文。
个人以为，性能在诸多非功能性约束中第一重要，直接影响用户体验。首先要从业务和代码层面保障性能，而单元测试是一个必要条件。正像PingCAP CTO 黄东旭所说的，“talk is cheap， show me the tests."
接下来是运行时调优，或者认为是单机性能。从加载和依赖开始，到 JVM调优，再到Linux 内核参数调优。 对于 JVM 调优，给朋友做个广告，中生代技术群中的 江南白衣 （公众号：春天的旁边）有一篇干货文章，特别向大家推荐。
数据库是整个系统中的慢性子，关注系统的性能，日志分析比不可少，LEK可能是第一首选。数据访问必须是高可用的，数据连接池的选择和使用都是考验功夫的。
缓存是减少负载，提高系统性的必备技术。可以从客户端，网络侧，服务端三个环节对缓存进行分类，具体可以参考《老曹眼中的缓存技术》。
负载均衡同样是一种以空间换时间的技术，具体可参考《老曹眼中的负载均衡》。
传输的性能可以依靠消息队列来提升，ZeroMQ可以用在系统内，而ActiveMQ是Java 程序猿的福音，对于高并发和高容错而言，RabbitMQ可能是不错的选择，Kafka是大量数据的传输必备。
啰哩啰嗦，只是想探讨一下全栈的套路，也许这本身就是一个伪命题。 延展阅读： 为什么未来是全栈工程师的世界？-博客-云栖社区-阿里云
技术在过去的几十年里进步很快，也将在未来的几十年里发展得更快。今天技术的门槛下降得越来越快，原本需要一个团队做出来的Web应用，现在只需要一两个人就可以了。
同时，由于公司组织结构的变迁，也决定了赋予每个人的职责将会越来越多。尽管我们看到工厂化生产带来的优势，但是我们也看到了精益思想带来的变革。正是这种变革让越来越多的专家走向全栈，让组织内部有更好的交流。
你还将看到专家和全栈的两种不同的学习模式，以及全栈工程师的未来。
技术的革新史
从开始的CGI到MVC模式，再到前后端分离的架构模式，都在不断地降低技术的门槛。而这些门槛的降低，已经足以让一两个人来完成大部分的工作了。
CGI
二十年前的网站以静态的形式出现，这样的网站并不需要太多的人去维护、管理。接着，人们发明了CGI(通用网关接口，英语：Common Gateway Interface)来实现动态的网站。下图是一个早期网站的架构图：
当时这种网站的URL类似于： https://www.phodal.com/cgi-bin/getblog
(PS：这个链接是为了讲解而存在的，并没有真实存在。)
用户访问上面的网页的时候就会访问，cgi-bin的路径下对应的getblog脚本。你可以用Shell返回这个网页：
123 #!/bin/sh echo Content-type: text/plain echo hello,world
Blabla，各种代码混乱地夹杂在一起。不得不说一句：这样的代码在2012年，我也看了有一些。简单地来说，这个时代的代码结构就是这样的：
这简直就是一场恶梦。不过，在今天好似那些PHP新手也是这样写代码的。
好了，这时候我们就可以讨论讨论MVC模式了。
MVC架构
我有理由相信Martin Fowler的《企业应用架构模式》在当时一定非常受欢迎。代码从上面的耦合状态变成了：
相似大家也已经对这样的架构很熟悉了，我们就不多解释了。如果你还不是非常了解的话，可以看看这本书后面的部分。
后台服务化与前端一致化架构
在今天看来，我们可以看到如下图所示的架构：
后台在不知不觉中已经被服务化了，即只提供API接口和服务。前端在这时已经尽量地和APP端在结合，使得他们可以保持一致。
软件开发的核心难题：沟通
软件开发在过去的几十年里都是大公司的专利，小公司根本没有足够的能力去做这样的事。在计算机发明后的几十年里，开发软件是大公司才能做得起的。一般的非技术公司无法定制自己的软件系统，只能去购买现有的软件。而随着技术成本的下降，到了今天一般的小公司也可以雇佣一两个人来做同样的事。这样的演进过程还真是有意思：
在这其中的每一个过程实质上都是为了解决沟通的问题。从瀑布到敏捷是为了解决组织内沟通的问题，从敏捷到精益不仅仅优化了组织内的沟通问题，还强化了与外部的关系。换句话说，精益结合了一部分的互联网思维。
瀑布式
在最开始的时候，我们预先设计好我们的功能，然后编码，在适当的时候发布我们的软件：
然而这种开发方式很难应对市场的变化——当我们花费了几年的时间开发出了一个软件，而这个软件是几年前人们才需要的。同时，由于软件开发本身的复杂度的限制，复制的系统在后期需要大量的系统集成工作。这样的集成工作可能要花费上大量的时间——几星期、几个月。
当人们意识到这个问题的时候，开始改进工作流程。出现了敏捷软件开发，这可以解释为什么产品经理会经常改需求。如果一个功能本身是没必要出现的话，那么为什么要花功夫去开发。但是如果一个功能在设计的初期就没有好好设计，那么改需求也是必然的。
敏捷式
现有的互联网公司的工作流程和敏捷软件开发在很多部分上是相似的，都有迭代、分析等等的过程：
但是据我的所知：国内的多数互联网公司是不写测试的、没有Code Review等等。当然，这也不是一篇关于如何实践敏捷的文章。敏捷与瀑布式开发在很大的区别就是：沟通问题。传统的软件开发在调研完毕后就是分析、开发等等。而敏捷开发则会强调这个过程中的沟通问题：
在整个过程中都不断地强调沟通问题，然而这时还存在一个问题：组织结构本身的问题。这样的组织结构，如下图所示：
如果市场部门/产品经理没有与研发团队坐一起来分析问题，那么问题就多了。当一个需求在实现的过程中遇到问题，到底是哪个部门的问题？
同样的如果我们的研发部门是这样子的结构：
那么在研发、上线的过程中仍然会遇到各种的沟通问题。
现在，让我们回过头来看看大公司的专家与小公司的全栈。
大公司的专家与小公司的全栈
如果你经常看一些关于全栈和专家的技术文章的时候，你就会发现不同的人在强调不同的方向。大公司的文章喜欢强调成为某个领域的专家，小公司喜欢小而美的团队——全栈工程师。
如我们所见的：大公司和小公司都在解决不同类型的问题。大公司要解决性能问题，小公司都活下去需要依赖于近乎全能的人。并且，大公司和小公司都在加班。如果从这种意义上来说，我们可以发现其实大公司是在剥削劳动力。
专家
我们所见到的那些关于技术人员应该成为专家的文章，多数是已经成为某个技术领域里的专家写的文章。并且我们可以发现很有意思的一点是：他们都是管理者。管理者出于招聘的动机，因此更需要细分领域的专家来帮助他们解决问题。
全栈
相似的，我们所看到的那些关于成为全栈工程师的文章，多数是初创公司的CTO写的。而这些初创公司的CTO也多数是全栈工程师，他们需要招聘全栈工程师来帮助他们解决问题。
两种不同的学习模型
而不知你是否也注意到一点：专家们也在强调“一专多长”。因为单纯依靠于一个领域的技术而存在的专家已经很少了，技术专家们不得不依据于公司的需求去开拓不同的领域。毕竟“公司是指全部资本由股东出资构成，以营利为目的而依法设立的一种企业组织形式；”，管理人们假设技术本身是相通的，既然你在技术领域里有相当高的长板，那么进入一个新的技术也不是一件难的事。
作为一个技术人员，我们是这个领域中的某个子领域专家。而作为这样一个专家，我们要扩展向另外一个领域的学习也不是一件很难的事。借鉴于我们先前的学习经验，我们可以很快的掌握这个新子域的知识。如我们所见，我们可以很快地补齐图中的短板：
在近来的探索中发现有一点非常有意思：如果依赖于20/80法则的话，那么成为专家和全栈的学习时间是相当的。在最开始的时候，我们要在我们的全栈工程和专家都在某个技术领域达到80分的水平。
那么专家，还需要80%的时间去深入这个技术领域。而全栈工程师，则可以依赖于这80%的时候去开拓四个新的领域：
尽管理论上是如此，但是专家存在跨领域的学习障碍——套用现有模式。而全栈也存在学习障碍——如何成为专家，但是懂得如何学习新的领域。
解决问题的思路：不同的方式
有意思的是——成为专家还是成为全栈，取决于人的天性，这也是两种不同的性格决定的。成为管理者还是技术人员看上去就像一种简单的划分，而在技术人员里成为专家还是全栈就是另外一种划分。这取决于人们对于一个问题的思考方式：这件事情是借由外部来解决，还是由内部解决。下面这张图刚好可以表达我的想法：
而这种思维依据于不同的事情可能会发生一些差异，但是总体上来说是相似的。当遇到一个需要创轮子的问题时，我们就会看到两种不同的方式。
对于全栈工程师来说，他们喜欢依赖于外部的思维，用于产生颠覆式思维。如Angular.js这样的框架便是例子，前端结合后端开发语言Java的思维而产生。而专家则依赖于内部的条件，创造出不一样的适应式创新。如之前流行的Backbone框架，适应当时的情况而产生。
全栈工程师的未来：无栈
全栈工程师本身不应该仅仅局限于前端和后台的开发，而可以尝试去开拓更广泛的领域——因为全栈本身是依赖于工程师本身的学习能力，正是这种优秀的学习能力可以让他们可以接触更广泛的知识。
全栈的短板
如果你也尝试过面试过全栈工程师，你会怎么去面试他们呢？把你知道的所有的不同领域的问题都拿出来问一遍。是的，这就是那些招聘全栈工程师的公司会问你的问题。
人们以为全栈工程师什么都会，这是一个明显的误区——然而要改变这个误区很难。最后，导致的结果是大家觉得全栈工程师的水平也就那样。换句来说，人们根本不知道什么是全栈工程师。在平时的工作里，你的队伍都知道你在不同领域有丰富的知识。而在那些不了解你的人的印象里，就是猜测你什么都会。
因此，这就会变成一个骂名，也是一个在目前看来很难改变的问题。在这方面只能尽可能地去了解一些通用的问题，并不能去了解所有的问题。在一次被面试全栈工程师的过程中，有一个面试官准备了几个不同语言（Javascript、Java、Python、Ruby)的问题来问我，我只想说Ciao——意大利语：你好！
除了这个问题——人们不了解什么是全栈工程师。还有一个问题，就是刚才我们说的成为专家的老大难问题。
无栈
让我毫不犹豫地选择当全栈工程师有两个原因：
- 这个世界充满了未解的迷，但是我只想解开我感兴趣的部分。
- 没有探索，哪来的真爱？你都没有探索过世界，你就说这是你最喜欢的领域。
中小学：编程语言 -> 高中：操作系统、内核、游戏编程 -> 大学： 硬件、Web开发 -> 工作：后端 + 前端
而在当时我对SEO非常感兴趣，我发现这分析和Marketing似乎做得还可以。然后便往Growth Hacking发展了：
而这就是全栈学习带来的优势，学过的东西多，学习能力就变强。学习能力往上提的同时，你就更容易进入一个新的领域。
程序员：如何成为一个全栈的工程师？-博客-云栖社区-阿里云
全栈工程师，英文 Full Stack developer，是指那些掌握多种技能，并能利用多种技能独立完成产品的人。当然，现在「全栈工程师」很吃香，非常吃香！这是因为在移动互联网时代，IT 系统变得愈加复杂，需要拥有全局思维的工程师来搞定各种「疑难杂症」。不仅要玩得转前端，还要搞得定后端，总之各种技术都懂，所以其重要性可见一斑。
近日，移动开发精英俱乐部围绕「如何成为一个全栈的工程师？」进行了讨论，主持人是优才学院的创始人伍星老师，让我们一起看看大神们的精彩言论吧！（本文系国内 ITOM 管理领军企业 OneAPM 工程师整理）
程序员眼中的「全栈」
伍星-优才创始人：全栈，最早来自于 Facebook 的「我们只招全栈工程师」，从表面看是指技术栈，是完成一套产品所面要的全部技术和技能。谷歌在它的书中也提出，它们只招创意型人才，其实这是一致的、相通的！
饶培泽：全栈，在我看来是一种态度，无路遇到何种问题都能积极的去解决。全栈，也不是说会什么，而是因为有好奇心与驱动力，所以什么都想搞明白，学习起来自然能快速上手。
iOS小码哥：全栈，也可以说「我是一块砖，哪儿需要我，我就往哪儿填。」代表着快速学习的能力和超强的适应能力。
梦航：全栈，在一定程度上能更好的做出架构，减少维护成本。
卓竞劲：我支持思想和知识层面的「全栈」，而非刻意技能上的全栈。
饶培泽：其实，能从前端写到后端的人不少，但是能专职来做吗？这么说吧，很多公司的后端都能写前端，但可不敢让他们写产品级别的代码。如果后端人才如果能去了解前端的知识点，合理去进行整合互补，这样是我们所鼓励的。
药交汇：全栈围绕产品服务，重点是考虑问题的角度、广度。个人理解也可以看成责任感的一种体现，前端、后端都可以也不代表全栈。只不过是围绕着问题的解决方案，其根本还是本着对一件事情负责的态度，展开全方面的跟踪。
伍星-优才创始人：从谷歌对创意型人才的描述可以看出，这更多体现在能够主动地承担工作和解决问题。比如谷歌讲过一个例子，Adwords 是几个非相关工程师主动解决了小问题带来大收益的。
Facebook 的人才培养一开始是不分工的，「新兵营」之后才分工，并且轮岗很多，这中间暗含了：学习能力要相当强，我想学什么，都能学什么，需要我做什么，都能胜任。
所以我们对全栈提出如下见解。首先要技术全面，作为全栈工程师，其技术当然要比较全面。从前端到后端、从运维到优化、从 PC 到移动都难不倒。 但又有自己比较精通的一方面。也就是说，作为全栈工程师既要有「专深」，同样也要有「广博」，这样才能在解决问题时不受局限，才能融会贯通。
第二就是思维和心态。全栈工程师以积极主动的姿态来面对和解决工作中的问题。以全局的观点来看待自己所从事的项目， 而不只是自己负责的一小部分。以做成产品、做成一件事的观点来看待整个开发流程，而不仅仅是技术实现。 因为只能这样的心态和观点，他才会积极主动地去学习其他技术，用其他技术解决问题
第三是上升能力，全栈工程师并不意味着全能，什么都会。但是全栈工程师有良好的基础技能。 这个技能，既包括计算机科学的基础，也包括英语基础，有了这个基础， 加上积极的态度，开放的心胸，就能快速地学习所需要的技术，比如像 Swift 语言，那都不是事儿。 并应用在所需要的开发工作中。
第四就是职业价值，像 Facebook 说，他们只喜欢全栈工程师，创业公司也会说，我们需要全栈工程师。无论是在大公司，还是创业公司， 全栈工程师都将成为抢手人才！那是因为，全栈工程师不但技能全面，而且心态积极，学习能力强！
伍星-优才创始人：所以全栈不是一种技能，而是一种能力。学习能力，开放心态是优先的！
李睿君：其实后面有段时间觉得全栈需要一方面熟悉自己本身专业的领域，另一方面需要关注另一段的技术，这样在需要另一端技术，或是沟通时都能有帮助
着建彬：对感兴趣的东西不要当成「工作」来做，其实兴趣才是最大的动力。我觉得全栈应该是由「兴趣」驱动的。
伍星-优才创始人：即使是领域专家，他对别的也会有了解和研究的。优秀的技术人员，对所有的技术应该有一种天然的好奇心和折腾劲
药交汇：我前端和后端都经历过，其实，在前期人员不全的情况下，结合业务并外出调研梳理了产品线框图、PRD、流程图，到制定了设计规范，到协调资源，然后制定研发周期，最后到输出...... 曾一度以为这就是全栈，但是后来思考，这些只不过是本着对事情负责的态度，才驱动做了很多研发之外的事。就算一个人的技术全栈精通也要服务于根本产品。
伍星-优才创始人：项目进度和管理，比全栈本身要难。因为技术还是死的，人是活的，而且多种多样的。就像业务架构师，本身曾经技术应该不错，即使学新技术，应该也是有特殊长处和见解的，不过不学不写罢了。这种人是标准的技术 leader ，技术能力并不一定是以某特定语言的写码能力而界定。
一般而言，全栈工程师在产品和沟通这块都有优势，由于技术全面，他能和各方沟通的比较愉快 。甚至和产品经理也沟通好。我也算是一个全栈，此前和各个产品经理沟通都很愉快。因为他不理解的地方，我会和他讲清楚，分析清楚，为什么这个不能做，为什么那样做不好，那样做更好，有理有据，其实，产品经理也是讲道理的，不像我们在网络上经常「吐槽」的那样。如果再加上本身的技术声望和良好沟通的方式，程序员和产品经理相处其实会很和谐的。
如果成为一个全栈工程师？程序员：如何成为一个全栈的工程师？-博客-云栖社区-阿里云
王威：我的理解是，不仅自己领域的精通，然后其他部分也应该快速学习。在我看来，如果想成为全栈的话，还得靠上项目了。在普通公司的话，一般每个人只关注自己的领域，对跨领域的项目一般不会碰，可以自己利用业余时间来写，比如原本做APP的，有空可以写一下后端的东西，其实开始那一步比较困难。
张洋：全栈不只是技术，还需要心态、责任等方方面面。
江月：我觉得 facebook 要求全栈，并不是希望程序员技术全面但不精通。而是至少有一个领域精通，而且可以快速研究另外一个领域的技术点。
伍星-优才创始人：能成为全栈，意味着技术能达到一定高度，而高度，肯定是以长处见知的。我个人更倾向于认为，一专多能。
王威：成为全栈的话，还得靠上项目了。。。在普通公司的话，一般每个人只关注自己的领域，对跨领域的项目一般不会碰，自己私下来写，比如原本做 APP 的，自己私下写后端的东西，其实开始那一步比较困难。
药交汇：关键是责任感的转变，由「被动」到「主动」，才能实现自我超越。
拯救与逍遥：我个人看法，不是先有了「我要成为全栈」的目标，而是对技术的好奇和追求，以及积极应对当前业务发展的不断挑战，最终才能锻炼出了全栈。
薄建业：我觉得，最好的方法就是项目驱动；从另一方面也说明，说为全栈，在一定程度上，也是被逼出来的。
王威：我比较赞成项目驱动型。比如 APP 端的，例如做个类似于云笔记的软件，那么后端数据该怎么保存，接口该怎么定，该用哪种语言来实现后端，在分析你想要的目标的时候就能找到该用哪种技术该学哪种技术。比如后端用 PhP 写，这时候就会推动自己去学 PHP，比如自己是做安卓，那么语言衔接上，有可能选择 JAVA 做后端，这时候就学 J2EE 的东西，围绕这个需求来实现，然后学数据库......其实说到底还是得有」目标项目」来进行推动。
林曦：后端概念太泛了，不同业务需求和规模需要的技术支撑完全不同。
王威：比如做高并发，可以 NodeJs 、 Golang 、 Erlang ，或者干脆用 Java、PHP 等等。其实做项目的第一步，后端写出业务服务接口，在业务量上来之后考虑比如性能优化，比如负载均衡，或者再比如后端架构分层等等。
文彦峰：其实，接入也有很多要做的，一般要和终端一起做，路由、负载、流量控制、安全、监控、旁路、优化 TCP 协议栈、内核参数再到硬件的支持等等。做业务，比如网关、鉴权、微服务框架、服务治理、缓存、消息中间件；存储，单机房如何保证数据不丢，多机房是单向同步，双向同步，出了异常怎么通过日志恢复，数据的检查，静态检查点的选择。怎么做分片，怎么扩容不影响原来的分片？
王威：所以说到底还是得有这个项目需求，围绕着需求来分析需要的技术，然后再研究技术了。感觉纯按照兴趣来学新的技术，作为对这一个技术有个优缺点简要了解，在需要的时候能快速学习。我个人还是觉得，想成为一个「全栈」，就找一个想法并实现它。
周渊：比如，你觉得 NBA 好看，想要做一个 APP 能提醒比赛，那么每天下班后，没事写几个小时代码，三个月后，你就会发现做成了。
林曦：我觉得做个「入门型」的全栈比较容易，真正能做到都有一定深入的了解很难，融会贯通更难。
拯救与逍遥：先自学基础入门，进阶的话，可以随公司项目，初期不能直接参与，但是我们可以主动思考技术方案，然后参照其他同事最后落地的方案，对比总结。能力慢慢提升，真正上手的机会总会有的！
周渊：最重要就是，Just Do It ！
林曦：不过大公司相对有一个好处，就是能遇到「牛人」的概率也比较高，所以开发过程中，某一个部分遇到瓶颈的时候想要找人讨论或者请教，找他们也是比较好找的。
周渊：高人点拨，确实重要，但是建立在你入门的基础上。
拯救与逍遥：很多时候，我们不能做最想做的事情，而且要停下来推动一下，阻碍我们继续前行的事情。但是，有些坑，有些历练是必须的，别人说一万遍，我们还是得自己历练。而且很多技术选型，都是在真正落地之后，才暴露出问题。
王威：采坑是必然的！运气好的话，采坑的代价低，运气不好的话，采坑代价可能毁掉整个项目。不过有些坑，有可能是在技术选型的时候就会暗含的，这个时候确实不好找。
王威：我们业务在往图数据迁移的时候也踩了很多坑，因为我们是社交软件，所以很多需求是基于用户关系的，比如喜欢、不喜欢、好友等等。。。最开始觉得 neo4j 挺方便的，导入数据的时候发现，免费版就是个坑爹的玩具。。。收费版貌似5千刀一个月还说多少，巨贵。。。
王威：创业有这个好处就是人少，一个人当多个人用，这个时候就有很多机会去摸新的东西，不过缺点就是没人带，自己摸石头采坑。。。
王威：不过对于我来说收益大于采坑风险。。。所以还是得围绕这个需求，一圈一圈的挖掘更好的解决方式，这个是一种学习的过程。尤其是在风险可控范围内，绝对鼓励大家尝试新的东西。
到最后你的选择很多时候依赖你团队的水平，怎么把这些人水平带起来，你这些才能做细
最好的成长就是在业务中成长
林曦：架构也是活的，需要不断生长，不断修改。不过，前期埋的坑也只有后期加班吞了，没有一劳永逸的架构！
董飞：我觉得重要的还是分享，别人帮你填了坑，你也可以帮别人填坑。而媒介就是博客，大家可以互帮互助。
王威：说到写博客，我觉得可以把思维给规范化，把想法记录下来的同时还能注意到以前没注意到得细节，绝对是学习新姿势最必要的补充。
伍星-优才创始人：曾经，我就主动地提出来帮公司承担一些的运维方面的事情。然后就自己学习，请教，后来很自然地就成为全栈了。当然，全栈并不意味着上班学别的，我们上班时间把公司的事情做好，这才是成为全栈的前提。
伍星-优才创始人：还有一点，就是我们在写代码的过程中，要考虑怎么优化，怎么写得更快更好，而不是像「搬砖」似的，简单的重复。「搬砖」工作很快就会被淘汰掉，积累核心竞争力才是发展的根本 。
王威：比如做APP，在写从服务端拉取数据的时候，就可以考虑一下他们为什么要提供这样的数据结构？这样的接口如何进行实现的？有这些疑问的时候，就会促进自己去看看去了解一下相关的知识，这样才能不断通向全栈之路。
当然，完成是一码事儿，完成好是另一码事儿。全栈的意义不是全都泛泛地去做，而是在做深自己的领域同时，也能借鉴其他的技术，至少在团队开发时候沟通成本会减少很多。
赵建彬：其实，产品并不会关心你代码怎么写，关键自己要写出让自己觉得满意的、高质量的代码。
薄建业：全站人才可以站在更高的视角，提供「一揽子」的解决方案，避免踩深坑！
文彦峰：热衷于技术，成全栈是早晚的事儿，技术全面某方面又比较深入，自然能解决别人解决不了的问题，能做别人做不了的事情，团队中的影响力，行业中的影响力，也自然就有了，形成正向循环，还是挺不错的！
伍星-优才创始人：就像罗辑思维跨年公开课说的那样，核心竞争力，就是你的不可替代性。我们不能单纯地说「全栈」好，很多初学者会被误导，是因为他们不了解什么是全栈，怎么才能成为全栈。就像武功也有练「走火入魔」的。
其实，加入一个快速成长的团队创业。是成为全栈的最快捷途径。这个团队，也可能是大公司内部创业团队。也可能是大家都把工作当作创业的团队。而没有好奇心，没有折腾劲，没有学习能力，没有开放心态，是不可能成为全栈的！
http://quanzhan.ucai.cn/intro （本文是优才学院创始人伍星对全栈的理解，发布后2014年4月份，到现在也没有改变，欢迎大家阅读。）
UPDATE：这篇答案写在问题添加了“补充说明”说明之前，对于“Full Stack Developer”的定义是我根据自己的理解来写的，现在看来我（以及另外一些朋友）的理解和补充说明里引用的那一段是不同的。所以这个答案与题目描述并不相符，仅供参考，请大家注意。
简单来说我以下所说的 FSD 可能更像是“全才大牛”，对任何一个领域的了解都达到了该领域的专业人士的平均程度，更像是 Engineer × N ；而补充说明以及 庄生 （抱歉由于重名太多不知道该at哪一个）、
等朋友所说的 FSD 则是各领域都有一定的了解（但不必达到该领域的专业人士的水平），足够独立完成一个项目的各个方面，强调了解新领域的勇气和能力（前提自然是有充分的兴趣）。
对于后一种 FSD ，我是十分赞同将其作为一个目标而奋斗的，理由和方法其他几位也说了很多的（我很赞同独自完成一个项目，途中了解些感兴趣/有用到的、但之前不了解的新领域，永远保持一颗好奇心，真的受益匪浅）。
而对于前一种 FSD （也是我下面即将讲到的），先声明我绝对不是也不想“装逼”，做以下几点说明：
====================
窃以为 full stack 不是那么简单的事情。当然，不同的地方可能有不同的标准，且听我慢慢道来。
既然大家都在以 Web 为例，那我也说 Web 好了。不过事实上 full stack 也有可能是其他方面的。
租个 VPS ，从装系统配环境开始，然后拿个 PHP Python Ruby Nodejs 什么的写个后端（少不了用一些框架吧， 后端框架多如牛毛，不说 PHP ， Python 用个 django 、 Ruby 弄个 rails ，都挺方便吧），再给它撸个好看的页面（表现层多半也会用个 bootstrap 之类的，如果设计能力强一点的话就用一些更轻便的 helper frame 然后主要自己手写；逻辑控制层高端一点弄个 backbone 甚至 angular 之类搞个重 AJAX 、带前端模板及路由的新潮 HTML5 应用）。弄好以后上线，性能出问题了，看看日志 Google 一番调调参数，甚至多买一两台 VPS 来弄个负载均衡什么的。再要不，我们换成实体机，然后顺便玩玩网络和虚拟化什么的？
这样算不算 full stack 呢？也许在一些小公司（不过现在很多互联网创业公司水平都很高，所以也不能完全看大小）可以算是了。但在真正高水平的公司，以上的任何一点都达不到相应领域“工程师”的标准。
装个系统调调参数甚至弄个简单的负载均衡就叫运维了？你确定这不是网管？从几台机器到成百上千台机器是有一个量变到质变的（虽然经过这个质变以后，对于运维工程师来说两者就差别不大了），更别说弄个机房，搞个异地数据中心什么的。不说CCNP，CCNA总该有吧？再者，如果不说这么大（这么大了可能就涉及到“架构师”了），往小一点说，也有很多可深挖的：性能调优只是根据网上的文章随便调调参数？我见过不少牛逼的 Web 运维都读过 Apache 和 nginx 甚至部分 kernel 代码。没有自动化的监控程序和运维工具难道得死死守在机器前一遍遍地敲命令？合格的运维不但熟练使用已有的工具，还会根据需要自己写脚本、工具，因为现实情况太复杂通用工具不一定适合。很多公司里，运维还要兼顾安全问题，那么又是一个大坑。备份、冗余、风控个个门道都很深。
再说后端。会用 django 或者 RoR 写点东西很厉害？这些本来都是 RAD 框架，就是拿来快速开发、快速上手的，降低了门槛。但不同的程序员编程功底和代码质量还是会对最终成果造成很大影响。滥用 ORM 导致性能低下的例子我就不多说了。明明用了这样的框架还能写出带有 SQL 注入的程序也不少见，有的甚至还存在逻辑安全漏洞，至于什么加盐、防 CSRF 、 XSS 、 replay attack 、 session fix 、应用层 DoS 等等，多少人都是只听说过名字知道个大概然后用一个“厉害”的框架就以为一劳永逸？不知道原理也没看过框架代码，不知道框架到底是怎么实现的、是否有一定局限……再说软件工程方面。写几个测试数据就叫单元测试了？提前写测试数据再开发就成 TDD 了？三天两头重构就叫敏捷了？ QA 、版本控制、协作、文档，都不是那么简单的事吧。
然后说前端。 HTML CSS 本来就是以方便表示内容和布局样式而开发的，只是“会写”应该不算什么难事吧？何况还有各种布局、排版库。 JS 灵活得很，有一点 C 语法基础的人学起来也很快，感谢 jQuery ，就算是不知道什么是闭包、不知道 JS 原型继承等等的三脚猫功夫也能实现大多数需求了。那么这样就是前端工程师？真是这样的话为何前几天知乎还有人问好的前端工程师为什么这么难找？能写出在所有浏览器表现一致并且方便维护的样式需要不少经验积累和勤奋实践，对浏览器渲染原理的了解也不可少。这还只是第一步，加上 JS 这玩意儿以后复杂度其实陡然上升了。在一个真正的大项目里，要保证各个组件正常运行不是一件容易的事， JS 本来就缺乏一些“软件工程”特性，导致大型代码组织不便，糟糕的 JS 程序很容易就污染了命名空间、搞错了作用域、漏掉了异常、弄错了类型、在异步和回调之中迷失……一不小心，就搞挂了页面，调起来还麻烦（就算现在有了 Chrome ）。这还没算上性能、兼容性、安全等等问题呢。这也是为什么前端工具/技术特别多的原因之一。好的前端工程师不但紧跟技术前沿，还乐于知道这些牛逼的技术都是怎么实现的，然后灵活运用。
可能有人会说人的精力有限， full stack 有了广度自然要牺牲一下深度。那么我想说，再怎么牺牲深度，如果各领域都像上文举的反例那样，那肯定是不够的。那样可能只算是一个爱折腾的 geek 而不是工程师。我一个大二学生就能很好地完成开头提到的情景，并且还可以再深一点（比方网络方面有个差不多CCNA的水平和一些经验， PHP 自认为还是比较扎实的= =，对于安全、性能优化、分布式等方面也有一些了解……），但我也只觉得自己大多数时候还只是“折腾”而已，还有太多不足和有待提高之处。事实上，上述任何一个领域中的真正的工程师都肯定能凭借自己的学习能力和极客精神轻松地在业余时间完成开头所说的那个例子：看看 github 上那些有趣的个人开源项目和搭建起来的 demo 吧，大部分作者的本职应该都只是前端、后端或其他等等的其中之一。更不用说还有很多工程师的博客也是自己写（我是指写一个博客系统）、自己搭的。
full stack 一定是很难的。其实我自己作为一个互联网领域的学徒，也面临着这样的困惑：我发现自己什么都会一点、什么都不算精（按照某些标准大概已经算是一个“full stack”了吧）。到底以后应该怎样呢？是朝真正的 full stack 努力还是好好专精一个？看了不少招聘要求，现在就算是创业小团队也很少会直接招 full stack 的，所以觉得大概是先做好一个性价比高一些？不知道题主为何想要成为一个 full stack 呢，是因为已经是某一领域的工程师想要做做其他方面么（这个也会影响到“怎样成为”这个问题）？
不好意思，似乎跑题了。到最后自己还反倒提了个问。只是希望抛砖引玉，更踏实的回答多一些，不要太浮躁，把全栈说得太过轻易。
手机打字，如有差错还望指出，谢谢。
简单来说我以下所说的 FSD 可能更像是“全才大牛”，对任何一个领域的了解都达到了该领域的专业人士的平均程度，更像是 Engineer × N ；而补充说明以及 庄生 （抱歉由于重名太多不知道该at哪一个）、
等朋友所说的 FSD 则是各领域都有一定的了解（但不必达到该领域的专业人士的水平），足够独立完成一个项目的各个方面，强调了解新领域的勇气和能力（前提自然是有充分的兴趣）。
对于后一种 FSD ，我是十分赞同将其作为一个目标而奋斗的，理由和方法其他几位也说了很多的（我很赞同独自完成一个项目，途中了解些感兴趣/有用到的、但之前不了解的新领域，永远保持一颗好奇心，真的受益匪浅）。
而对于前一种 FSD （也是我下面即将讲到的），先声明我绝对不是也不想“装逼”，做以下几点说明：
- 对于各个领域来说，我所举的那些例子都是我在对该领域“简单了解”之后接触到的很有限的一些概念、技术，是一些例子而已。该领域的大部分专业人士所能够做到的，但绝不是说懂了这些就是专业人士，也更谈不上“炫耀”（我自己也不会啊，所以有错误肯定在所难免，还望指正）。
- 这种各领域都达到专业水平的全能大牛（至少在我看来如此）真的存在么？是的，我见过一些。他们的知识广度和深度让我由衷佩服。而他们中的很多其实在工作中也只是某个领域的专业工程师而已。
- 以我有限的知识水平和学习经历来看，能够做到这个程度需要付出极大的努力。而所谓的“给大家泼冷水”其实倒不如说是给自己泼冷水——我也一度觉得似乎能一个人搞定一个项目（就像下面即将谈到的那个“反例”一样）就是什么都行的 FSD 了，但遇到了他们之后，我真的意识到差距真的不是一般大。因而我才产生了疑问：在我短暂的大学生涯里，把这样的“全栈”当成奋斗目标真的可行、值得么？是不是先把一件事情做好更好呢？
- 最后，下面的回答是以“基于 Web ”的全栈“开发者”例的，所以有些朋友吐槽怎么不说 native app 、怎么不说 PS 、画画之类的……好吧，可能是我太年轻了。
====================
窃以为 full stack 不是那么简单的事情。当然，不同的地方可能有不同的标准，且听我慢慢道来。
既然大家都在以 Web 为例，那我也说 Web 好了。不过事实上 full stack 也有可能是其他方面的。
租个 VPS ，从装系统配环境开始，然后拿个 PHP Python Ruby Nodejs 什么的写个后端（少不了用一些框架吧， 后端框架多如牛毛，不说 PHP ， Python 用个 django 、 Ruby 弄个 rails ，都挺方便吧），再给它撸个好看的页面（表现层多半也会用个 bootstrap 之类的，如果设计能力强一点的话就用一些更轻便的 helper frame 然后主要自己手写；逻辑控制层高端一点弄个 backbone 甚至 angular 之类搞个重 AJAX 、带前端模板及路由的新潮 HTML5 应用）。弄好以后上线，性能出问题了，看看日志 Google 一番调调参数，甚至多买一两台 VPS 来弄个负载均衡什么的。再要不，我们换成实体机，然后顺便玩玩网络和虚拟化什么的？
这样算不算 full stack 呢？也许在一些小公司（不过现在很多互联网创业公司水平都很高，所以也不能完全看大小）可以算是了。但在真正高水平的公司，以上的任何一点都达不到相应领域“工程师”的标准。
装个系统调调参数甚至弄个简单的负载均衡就叫运维了？你确定这不是网管？从几台机器到成百上千台机器是有一个量变到质变的（虽然经过这个质变以后，对于运维工程师来说两者就差别不大了），更别说弄个机房，搞个异地数据中心什么的。不说CCNP，CCNA总该有吧？再者，如果不说这么大（这么大了可能就涉及到“架构师”了），往小一点说，也有很多可深挖的：性能调优只是根据网上的文章随便调调参数？我见过不少牛逼的 Web 运维都读过 Apache 和 nginx 甚至部分 kernel 代码。没有自动化的监控程序和运维工具难道得死死守在机器前一遍遍地敲命令？合格的运维不但熟练使用已有的工具，还会根据需要自己写脚本、工具，因为现实情况太复杂通用工具不一定适合。很多公司里，运维还要兼顾安全问题，那么又是一个大坑。备份、冗余、风控个个门道都很深。
再说后端。会用 django 或者 RoR 写点东西很厉害？这些本来都是 RAD 框架，就是拿来快速开发、快速上手的，降低了门槛。但不同的程序员编程功底和代码质量还是会对最终成果造成很大影响。滥用 ORM 导致性能低下的例子我就不多说了。明明用了这样的框架还能写出带有 SQL 注入的程序也不少见，有的甚至还存在逻辑安全漏洞，至于什么加盐、防 CSRF 、 XSS 、 replay attack 、 session fix 、应用层 DoS 等等，多少人都是只听说过名字知道个大概然后用一个“厉害”的框架就以为一劳永逸？不知道原理也没看过框架代码，不知道框架到底是怎么实现的、是否有一定局限……再说软件工程方面。写几个测试数据就叫单元测试了？提前写测试数据再开发就成 TDD 了？三天两头重构就叫敏捷了？ QA 、版本控制、协作、文档，都不是那么简单的事吧。
然后说前端。 HTML CSS 本来就是以方便表示内容和布局样式而开发的，只是“会写”应该不算什么难事吧？何况还有各种布局、排版库。 JS 灵活得很，有一点 C 语法基础的人学起来也很快，感谢 jQuery ，就算是不知道什么是闭包、不知道 JS 原型继承等等的三脚猫功夫也能实现大多数需求了。那么这样就是前端工程师？真是这样的话为何前几天知乎还有人问好的前端工程师为什么这么难找？能写出在所有浏览器表现一致并且方便维护的样式需要不少经验积累和勤奋实践，对浏览器渲染原理的了解也不可少。这还只是第一步，加上 JS 这玩意儿以后复杂度其实陡然上升了。在一个真正的大项目里，要保证各个组件正常运行不是一件容易的事， JS 本来就缺乏一些“软件工程”特性，导致大型代码组织不便，糟糕的 JS 程序很容易就污染了命名空间、搞错了作用域、漏掉了异常、弄错了类型、在异步和回调之中迷失……一不小心，就搞挂了页面，调起来还麻烦（就算现在有了 Chrome ）。这还没算上性能、兼容性、安全等等问题呢。这也是为什么前端工具/技术特别多的原因之一。好的前端工程师不但紧跟技术前沿，还乐于知道这些牛逼的技术都是怎么实现的，然后灵活运用。
可能有人会说人的精力有限， full stack 有了广度自然要牺牲一下深度。那么我想说，再怎么牺牲深度，如果各领域都像上文举的反例那样，那肯定是不够的。那样可能只算是一个爱折腾的 geek 而不是工程师。我一个大二学生就能很好地完成开头提到的情景，并且还可以再深一点（比方网络方面有个差不多CCNA的水平和一些经验， PHP 自认为还是比较扎实的= =，对于安全、性能优化、分布式等方面也有一些了解……），但我也只觉得自己大多数时候还只是“折腾”而已，还有太多不足和有待提高之处。事实上，上述任何一个领域中的真正的工程师都肯定能凭借自己的学习能力和极客精神轻松地在业余时间完成开头所说的那个例子：看看 github 上那些有趣的个人开源项目和搭建起来的 demo 吧，大部分作者的本职应该都只是前端、后端或其他等等的其中之一。更不用说还有很多工程师的博客也是自己写（我是指写一个博客系统）、自己搭的。
full stack 一定是很难的。其实我自己作为一个互联网领域的学徒，也面临着这样的困惑：我发现自己什么都会一点、什么都不算精（按照某些标准大概已经算是一个“full stack”了吧）。到底以后应该怎样呢？是朝真正的 full stack 努力还是好好专精一个？看了不少招聘要求，现在就算是创业小团队也很少会直接招 full stack 的，所以觉得大概是先做好一个性价比高一些？不知道题主为何想要成为一个 full stack 呢，是因为已经是某一领域的工程师想要做做其他方面么（这个也会影响到“怎样成为”这个问题）？
不好意思，似乎跑题了。到最后自己还反倒提了个问。只是希望抛砖引玉，更踏实的回答多一些，不要太浮躁，把全栈说得太过轻易。
手机打字，如有差错还望指出，谢谢。
中央在下一盘很大的棋
受苏格拉底大神的启迪，我也来谈谈全栈。
禅师：成为全栈工程师，这个问题等于如何成为全才，有可能吗
码农：有可能，不过可能性比较低，因为达芬奇这类人毕竟是百年一遇的奇才。不过，因为我热爱这个行业，也有一定天赋，所以只做好软件全栈的话我想还是可能的
禅师：你玩过三国志这个游戏吗
码农：我还开发过
禅师：你喜欢什么样的武将，诸葛亮怎么样？
码农：不错，虽然他武力只有20，不过智力有100，不过游戏出战不是单打独斗，我可以给他搭配武力100，智力20的吕布，在战场上所向披靡
禅师：对于一个武力65，智力65的武将，你怎么处理
码农：砍头或让他下野，浪费军粮和黄金
禅师：但是他很全面啊，两项能力综合130分，比诸葛亮和吕布的综合分还要高
码农：话虽如此但他还是太平庸，无法独挡一面
禅师：赵云怎么样
码农：这是我最喜欢的武将之一，武力97，智力80，还有一个姜维也是，武力91，智力91，这是我心中全才的标准
禅师：首先，请把一个能力发展到90，如果你还有余力把另一个能力发展到90，再称呼自己全栈吧，否则你只是一个全面发展又全面平庸的废材。
码农：我明白了，我想facebook和google标榜的全栈，也肯定不是一个c++，java，ios，php，blabla都只会编写hello world的全栈。
禅师：成为全栈工程师，这个问题等于如何成为全才，有可能吗
码农：有可能，不过可能性比较低，因为达芬奇这类人毕竟是百年一遇的奇才。不过，因为我热爱这个行业，也有一定天赋，所以只做好软件全栈的话我想还是可能的
禅师：你玩过三国志这个游戏吗
码农：我还开发过
禅师：你喜欢什么样的武将，诸葛亮怎么样？
码农：不错，虽然他武力只有20，不过智力有100，不过游戏出战不是单打独斗，我可以给他搭配武力100，智力20的吕布，在战场上所向披靡
禅师：对于一个武力65，智力65的武将，你怎么处理
码农：砍头或让他下野，浪费军粮和黄金
禅师：但是他很全面啊，两项能力综合130分，比诸葛亮和吕布的综合分还要高
码农：话虽如此但他还是太平庸，无法独挡一面
禅师：赵云怎么样
码农：这是我最喜欢的武将之一，武力97，智力80，还有一个姜维也是，武力91，智力91，这是我心中全才的标准
禅师：首先，请把一个能力发展到90，如果你还有余力把另一个能力发展到90，再称呼自己全栈吧，否则你只是一个全面发展又全面平庸的废材。
码农：我明白了，我想facebook和google标榜的全栈，也肯定不是一个c++，java，ios，php，blabla都只会编写hello world的全栈。
知乎用户
资深程序员、技术译者/作者、创业者(IT EDU)
最近招人，碰到有些人的简历里突出自己是是全栈工程师，用的是高亮「全栈」的字眼，生怕别人看不见，但是过来面试就不行了，基础知识都不懂。 感觉「全栈」害人不浅啊，搞的现在的技术人员相当浮躁。
所以我的建议是，不要在乎自己是不是全栈工程师，起码首先应该有一门深入的技术吧？由深到广，这是一个知识学习积累的过程，不是个Title。
所以我的建议是，不要在乎自己是不是全栈工程师，起码首先应该有一门深入的技术吧？由深到广，这是一个知识学习积累的过程，不是个Title。
阿里P9，好写代码，好为人师，好读书不求甚解
我感觉大家讨论的热火朝天，却有几个关键的问题都没有定义清楚
1）什么是全栈工程师 ？
有的人说是精通前端，精通后端，精通底端
------按照这个标准，地球上估计都找不出一个“全栈工程师”；
有的人说是懂前端，懂后端
------按照这个标准，我估计大部分目前做后端都可以称为“全栈工程师”，毕竟哪个写后台的一个页面都没写啊 ？大部分目前做app的也可以算“全栈工程师”，毕竟哪个做app的完全不知道后端怎么写啊？ 但如果这就是“全栈工程师”了，未免有点夸张了；
所以，如何定义“全栈工程师”就是一个很难的问题。我个人倾向于所谓的“全栈工程师”，应该是“精某端，懂另外一端”，“精”自然就是精通，能够玩各种花样，熟悉各种机制；“懂”就是知道怎么一回事，知道能够完成什么工作，知道常见的功能如何完成。
2）什么情况下需要“全栈工程师” ？
有的人说以后全部都只要“全栈工程师”，我觉得这完全是胡扯！分工合作是人类社会进步的一个很大的推动力，难道软件业发展到今天，反而要反其道而行之了么 ？肯定不可能。术业有专攻，分工合作才能促进整体效率的提升。
所以，“全栈工程师”真正能够发挥很大作用的，一个应该是如很多人所说的“创业”，自己创业，刚开始没那么多人那么多钱，要尽快做出产品，那么”全栈“就是一个必备的条件了；另外一个是”做原型“，比如说有了新产品想法，不太可能一下子扑100个人上去搞，很多时候都是先投3~5个人先试试，这个时候”全栈“也是很有优势的。
但无论是创业，还是新产品，一旦上了规模，必然要开始分工合作，全栈可能就慢慢退出，或者转型为类似产品的角色，起到一个胶水的作用
3）你要成为”全栈工程师“么？
我觉得看个人兴趣，毕竟前端和后端或者底端差异很大，不是想成为就成为的。
前端偏向于艺术，后端偏向于工程，底端偏向于数学，一个人很难同时具备这三种截然不同的素质。比如说像我这种码农，完全没有审美观，颜色分辨不超过10种，让我做前端，做出来的只能说能用，远远达不到美观的要求。
但保持适当的兴趣还是有必要的，做不出美观的前端，能作出能用的，一开始也不错
所以我觉得每个人都可以去尝试一下。
1）什么是全栈工程师 ？
有的人说是精通前端，精通后端，精通底端
------按照这个标准，地球上估计都找不出一个“全栈工程师”；
有的人说是懂前端，懂后端
------按照这个标准，我估计大部分目前做后端都可以称为“全栈工程师”，毕竟哪个写后台的一个页面都没写啊 ？大部分目前做app的也可以算“全栈工程师”，毕竟哪个做app的完全不知道后端怎么写啊？ 但如果这就是“全栈工程师”了，未免有点夸张了；
所以，如何定义“全栈工程师”就是一个很难的问题。我个人倾向于所谓的“全栈工程师”，应该是“精某端，懂另外一端”，“精”自然就是精通，能够玩各种花样，熟悉各种机制；“懂”就是知道怎么一回事，知道能够完成什么工作，知道常见的功能如何完成。
2）什么情况下需要“全栈工程师” ？
有的人说以后全部都只要“全栈工程师”，我觉得这完全是胡扯！分工合作是人类社会进步的一个很大的推动力，难道软件业发展到今天，反而要反其道而行之了么 ？肯定不可能。术业有专攻，分工合作才能促进整体效率的提升。
所以，“全栈工程师”真正能够发挥很大作用的，一个应该是如很多人所说的“创业”，自己创业，刚开始没那么多人那么多钱，要尽快做出产品，那么”全栈“就是一个必备的条件了；另外一个是”做原型“，比如说有了新产品想法，不太可能一下子扑100个人上去搞，很多时候都是先投3~5个人先试试，这个时候”全栈“也是很有优势的。
但无论是创业，还是新产品，一旦上了规模，必然要开始分工合作，全栈可能就慢慢退出，或者转型为类似产品的角色，起到一个胶水的作用
3）你要成为”全栈工程师“么？
我觉得看个人兴趣，毕竟前端和后端或者底端差异很大，不是想成为就成为的。
前端偏向于艺术，后端偏向于工程，底端偏向于数学，一个人很难同时具备这三种截然不同的素质。比如说像我这种码农，完全没有审美观，颜色分辨不超过10种，让我做前端，做出来的只能说能用，远远达不到美观的要求。
但保持适当的兴趣还是有必要的，做不出美观的前端，能作出能用的，一开始也不错
所以我觉得每个人都可以去尝试一下。
知乎用户
Programmer，Geeker，Dreamer.
个人感觉“宽度”很重要，“深度”更重要，尤其是现在这个高度专业化的社会，分工非常具体。
对于开发者来说，很多时候coding真的只是一种乐趣，而可能做出一个活生生的产品，就更乐不可言了。而且一般喜欢coding的人，好奇心肯定不小，一旦钻进了开发的领域，会被各种不同领域的技术亮瞎眼睛：-）
我个人比较菜，属于典型的蜻蜓点水式学习，当然这是之前，目前正在形成一套自己的学习机制。本科专业是机械，感觉很无趣，骨子里对“计算机”感兴趣，所以就各种去自学。先是从C语言开始，Turbo C敲个a+b就乐坏了，那时候沉浸在自己井底之蛙的世界里，事后想想真的略傻！之后不知轻重地跑去参加ACM，整算法，结果鼻青脸肿。大一下开始玩Linux，心灵得到一些慰藉。
之后进入一个团队，先学Java，没怎么学好；后来进入了嵌入式组，在这里泡了一年，多少对ARM，DSP，嵌入式Linux，甚至CPLD，FPGA之类有过了了解，还十分大胆地写了几行Verilog代码，而在那里面最让我着迷的无疑是嵌入式Linux了。然后大四整一年参加了一个比赛，做控制，写uCOS之上的机器人控制代码，偶尔也会写底层的驱动（不过整个系统采用的是DSP + FPGA，大部分驱动是负责FPGA的队友写的）。
闲暇之余，自己还对Web开发十分热衷，CSS和JS的世界也别样精彩，但也只是会皮毛罢了。
所以总结来看，凡是作为一个开发者，你就有可能接触到各种开发技术，因为你太长时间在计算机的世界里面，很多词汇耳濡目染。什么前端（Front End），后端（Back End），桌面（Desktop），移动客户端（Android，iOS），Web，嵌入式（Embedded），工具链（Tool Chain），服务器（Server），数据库（Database），用户体验（UX），等等。
可以参考之前的回答，如果一个开发者啥都会，但是又做不出什么实际有价值的东西，那还是相当于啥都不会；待你的宽度和视野足够了，能够宏观看待技术学习的时候，但是深入学习某一个你最感兴趣的技术的时候了。贪多求全，必死无疑！
再回到Full Stack Developer，看了那个链接，基本赞同作者试图传达的观点，但是可以把技术层面的东西再从其他方面分类。我个人对Full Stack的理解，从底层到上层，应该包含操作系统，工具链，数据库，分布式系统，用户态的桌面应用程序开发，移动客户端应用开发，基于浏览器的互联网产品，针对专用系统的算法开发等等。即是从操作系统一路到应用层面，不在于你会多少工具，而在于你掌握了多少核心思想。很多东西确实是相通的，人最重要的是能思考，有解决问题的能力，能够举一反三。
对于操作系统（比如Linux）来说，我觉得读内核的源代码可能不是必须的，但是对操作系统每一个关键模块工作原理的理解是必须的；而对工具链（比如gcc）来说，了解他们之后你对自己的源代码如何被转换成及机器代码就会更深的理解，就可能会更加严谨地编程，也能利用工具链的某些特性提高你的程序性能，发现bug后的除错可能也会相对容易；对于服务器这边，高可用，高并发是比较核心的问题，能够工作的服务器现在很容易搞到，但是高性能的服务器（不是靠硬件，靠优化配置）就比较考验人了，同理对于数据库产品来说，可能最核心的是scheme设计和性能优化，缓存之类的，学习的时候了解了基本的SQL，就要去深入了解数据库的原理了；前端的东西是直接更用户打交道，这个时候就要有足够的敏锐度，发现用户的痛点，才能够做出体验良好的产品；移动客户端稍显特殊，但是本质无异，先了解一下Android的整体架构，为什么选用Java作为第三方开发语言之类的问题会对之后的产品开发有不少帮助。
上面啰嗦了这么多，我想表达的就是，全栈的开发者不在于“会用”多少技术，而在于“懂”多少技术；只有掌握了技术的原理，才能说是“会”了这个技术。
因此我建议大家一定要多看原理性的东西，并且多实践，这样才能朝着Full Stack Developer一步一步迈进，同时锻炼自己的思维能力，解决问题的能力，还有沟通能力（和客户）。
最近看书比较多，也在不停地思考一些东西，跟大家共勉。
对于开发者来说，很多时候coding真的只是一种乐趣，而可能做出一个活生生的产品，就更乐不可言了。而且一般喜欢coding的人，好奇心肯定不小，一旦钻进了开发的领域，会被各种不同领域的技术亮瞎眼睛：-）
我个人比较菜，属于典型的蜻蜓点水式学习，当然这是之前，目前正在形成一套自己的学习机制。本科专业是机械，感觉很无趣，骨子里对“计算机”感兴趣，所以就各种去自学。先是从C语言开始，Turbo C敲个a+b就乐坏了，那时候沉浸在自己井底之蛙的世界里，事后想想真的略傻！之后不知轻重地跑去参加ACM，整算法，结果鼻青脸肿。大一下开始玩Linux，心灵得到一些慰藉。
之后进入一个团队，先学Java，没怎么学好；后来进入了嵌入式组，在这里泡了一年，多少对ARM，DSP，嵌入式Linux，甚至CPLD，FPGA之类有过了了解，还十分大胆地写了几行Verilog代码，而在那里面最让我着迷的无疑是嵌入式Linux了。然后大四整一年参加了一个比赛，做控制，写uCOS之上的机器人控制代码，偶尔也会写底层的驱动（不过整个系统采用的是DSP + FPGA，大部分驱动是负责FPGA的队友写的）。
闲暇之余，自己还对Web开发十分热衷，CSS和JS的世界也别样精彩，但也只是会皮毛罢了。
所以总结来看，凡是作为一个开发者，你就有可能接触到各种开发技术，因为你太长时间在计算机的世界里面，很多词汇耳濡目染。什么前端（Front End），后端（Back End），桌面（Desktop），移动客户端（Android，iOS），Web，嵌入式（Embedded），工具链（Tool Chain），服务器（Server），数据库（Database），用户体验（UX），等等。
可以参考之前的回答，如果一个开发者啥都会，但是又做不出什么实际有价值的东西，那还是相当于啥都不会；待你的宽度和视野足够了，能够宏观看待技术学习的时候，但是深入学习某一个你最感兴趣的技术的时候了。贪多求全，必死无疑！
再回到Full Stack Developer，看了那个链接，基本赞同作者试图传达的观点，但是可以把技术层面的东西再从其他方面分类。我个人对Full Stack的理解，从底层到上层，应该包含操作系统，工具链，数据库，分布式系统，用户态的桌面应用程序开发，移动客户端应用开发，基于浏览器的互联网产品，针对专用系统的算法开发等等。即是从操作系统一路到应用层面，不在于你会多少工具，而在于你掌握了多少核心思想。很多东西确实是相通的，人最重要的是能思考，有解决问题的能力，能够举一反三。
对于操作系统（比如Linux）来说，我觉得读内核的源代码可能不是必须的，但是对操作系统每一个关键模块工作原理的理解是必须的；而对工具链（比如gcc）来说，了解他们之后你对自己的源代码如何被转换成及机器代码就会更深的理解，就可能会更加严谨地编程，也能利用工具链的某些特性提高你的程序性能，发现bug后的除错可能也会相对容易；对于服务器这边，高可用，高并发是比较核心的问题，能够工作的服务器现在很容易搞到，但是高性能的服务器（不是靠硬件，靠优化配置）就比较考验人了，同理对于数据库产品来说，可能最核心的是scheme设计和性能优化，缓存之类的，学习的时候了解了基本的SQL，就要去深入了解数据库的原理了；前端的东西是直接更用户打交道，这个时候就要有足够的敏锐度，发现用户的痛点，才能够做出体验良好的产品；移动客户端稍显特殊，但是本质无异，先了解一下Android的整体架构，为什么选用Java作为第三方开发语言之类的问题会对之后的产品开发有不少帮助。
上面啰嗦了这么多，我想表达的就是，全栈的开发者不在于“会用”多少技术，而在于“懂”多少技术；只有掌握了技术的原理，才能说是“会”了这个技术。
因此我建议大家一定要多看原理性的东西，并且多实践，这样才能朝着Full Stack Developer一步一步迈进，同时锻炼自己的思维能力，解决问题的能力，还有沟通能力（和客户）。
最近看书比较多，也在不停地思考一些东西，跟大家共勉。
不是好人，保持最坏的恶意揣测
赞同上面
的说法。
我觉得Full Stack关键不在于你已经会什么，以及你已经会的东西有多深刻。而是在于，你能够会什么。
当一个可以随意切换自己角色并且顺利适应各种技术甚至不是技术的挑战的工程师，那就可以称得上是一个Full Stack了。
这需要的不仅仅是热情，更需要适合自己的方法和强大的学习能力以及近乎不要脸的抗失败打击能力。
一家拙见。
我觉得Full Stack关键不在于你已经会什么，以及你已经会的东西有多深刻。而是在于，你能够会什么。
当一个可以随意切换自己角色并且顺利适应各种技术甚至不是技术的挑战的工程师，那就可以称得上是一个Full Stack了。
这需要的不仅仅是热情，更需要适合自己的方法和强大的学习能力以及近乎不要脸的抗失败打击能力。
一家拙见。
Learning without limit
从全栈工程师到全栈员工，软件吞噬世界的步伐又进了一步。以下是 Chris Messina的文章
在我离开 Google快两年之后，我开始意识到职业环境正在发生的变化。传统的管理纪律正在渐渐瓦解。要想在职场上成功，需要的技能比以往更加多样而难以定义。如今，要想在职场上有所成就，你必须成为一个真正的博学者，成为一名全能全栈员工。
什么是全栈员工（full-stack employee）？
就像“全栈工程师（full-stack engineer）”和“全栈创业（full-stack startup）”一样，全栈员工（full-stack employee）拥有超强的综合技能，有着无法估量的价值。他们可以在快速演进、变革的技术浪潮中如鱼得水。他们可以在事实稀缺、观点横飞的过剩信息中凭直觉做决定。全栈员工能够熟练运用设计语言，明白使用卡通字体无异于犯罪行为，轻车熟路地嘲弄Keynote、Sketch抑或是Skitch。他们清楚用户界面（UI）和用户体验（UX）的区别。
他们可以和人讨论工程问题，能搞清楚算法、编程，也能理解前端的等级和后端的等级根本不是一回事。虽然他们可能并不亲自编程，但他们知道GitHub、StackOverflow都是做什么的。如果必要，他们会暴力破解一段“复制粘贴”的脚本，在CSV文件中进行基础分析。
他们是最新锐的社交应用的用户，深谙自我推广 之道。他们既可以在听众面前循循善诱地耐心讲故事，也可以在看了3分钟kickstarter视频后就能指出：亮明要点的时间不能长于一段Instagram、Vine短视频。注意力就是这个时代的硬通货。
全栈员工对新的想法、最棒的实现路径、提升生产力和与愉悦度的事情有着“贪得无厌”的胃口。他们对世界及其运转规则充满好奇心，想知道如何留下自己的印记。正是这一点使他们与过去时代的人们区分开来。开始一份工作时，全栈员工不会戴上“眼罩”埋头苦干，而是始终与行业的发展保持同步，因为他们清楚：变革往往出现在边缘地带，不能只盯着脚下的一亩三分地。
一名全栈员工是什么样子的？
有了24小时在线的移动设备，工作和非工作之间的界限正在模糊，既然工作正在变得碎片化，全栈员工要清楚地意识到自己的生活方式也要随之变化，比如使用整体式单色衣柜、功能明确的厨具。
成为全栈员工意味着要在两极之间来回切换。他们既要适应单兵作战，自给自足（比如自己安排时间，使用自己的设备工作），也要能和团队高效协作。过去，在大型团队中，往往需要有一名 IT经理来决定使用何种技术。如今，随着人们越来越多地使用个人设备工作，员工需要自己来搞定跨设备、跨平台沟通等问题。就拿企业协作工具来说。Slack可以整合所有东西，而微软却只对自己平台上的工具开放特权。如果你不能接入其他人的 API，你已经落后于时代了。全栈员工也是如此——他们至少应该熟知所有最新的应用，这样才不会落伍出局。
全栈员工必须要在自己的领域有深刻的洞见，同时也要机动地应对优先事项的转换，胜任不同的安排。组织的扁平化已经不是新现象，变革的动力可能来自顶层，也可能来自底层，有时候需要个体来决定事情的优先级。现场服务工程师（FSE，Field Service Engineer）应该遍布组织内部，却又不能分布的过于稀疏。即使不用监控每一位员工，他们也应该知道每一个人在做什么，保证他们在不熟悉的事情上不会手足无措。
要成为一名全栈员工不是一件容易的事，回报却也很丰厚。首先，他们可以更自由地按照自己的方式、在自己喜欢的地方（Teleport等服务可以帮助他们找到价廉的工作地点）、喜欢的时间工作。他们可以使用最新的工具，自给自足，自我管理。由于他们的工作涉及多领域、多学科之间的协作，会带来更宽广的视野，更丰富多彩的经历。在组织内部，他们的影响力也会不断上升，对组织的成败也将担负起更大的责任，团队的成功与否更加休戚相关。
这对雇主和管理者意味着什么？
对于企业和管理者来说，在人力市场上争夺全栈员工意味着很多准备工作。首先，你们做好准备来吸引、留住这些人才了吗？其次，你们团队的工作风格是否明确，你们对远程办公的支持如何？再次，你们允许的工作时间，支持员工自主安排工作计划吗？最后，你们会给他们留出健身、养生、陪伴家人的时间吗？
Google虽然充分考虑到了员工的健康、精神需求，但反过来也要求员工高度负责。 Google的员工可以以任何方式在任何时间、任何地点工作，只要能最大程度发挥创造力。但它同时希望员工能够随时参加一场临时安排的快速议事会。你的团队准备好了吗？
如果你还没有尝试过，不妨一试，来感受下”全栈员工“的工作环境是什么样子的。不同背景的人们在一个公共空间内彼此协作。他们一直在线，通过Slack等协作对话平台交流。大多数全员协作空间都是临时搭建，多种实体、虚拟的工具混合使用（白板、投影仪、会议室、视频会议设备等）。
对于职员和管理者来说，最需要培养的是”同理心“——员工和管理者都要对彼此有一种“同情的理解”，在彼此沟通、协作、要求时能够提出具体的需求。因为未来的工作需要高度的灵活性和自主性，但这并不意味着每个人给自己下达工作命令、工作指标。管理者的角色依然是必要的。
未来的工作是什么样子的？
说未来的职场将由全栈员工引领，无疑有些夸张，但这是一个显而易见的趋势。毫无疑问，工作的定义正在发生变化，员工的最大价值是应对不确定性，能够从海量的信息中提炼出有效的战略、战术。
而且，在工作机器人大规模“入侵”之前，我们只有10年的时间。他们正在取代体育新闻、驾驶、快递等重复性工作，人们要重新思考适合自己的角色。感知和综合的能力将是第一位的，而语言、辨析力和同感力在进行复杂、敏感的任务是都是必备技能。全栈员工将帮助我们向未来过渡，将成为新的混合经济中的关键角色。
在我离开 Google快两年之后，我开始意识到职业环境正在发生的变化。传统的管理纪律正在渐渐瓦解。要想在职场上成功，需要的技能比以往更加多样而难以定义。如今，要想在职场上有所成就，你必须成为一个真正的博学者，成为一名全能全栈员工。
什么是全栈员工（full-stack employee）？
就像“全栈工程师（full-stack engineer）”和“全栈创业（full-stack startup）”一样，全栈员工（full-stack employee）拥有超强的综合技能，有着无法估量的价值。他们可以在快速演进、变革的技术浪潮中如鱼得水。他们可以在事实稀缺、观点横飞的过剩信息中凭直觉做决定。全栈员工能够熟练运用设计语言，明白使用卡通字体无异于犯罪行为，轻车熟路地嘲弄Keynote、Sketch抑或是Skitch。他们清楚用户界面（UI）和用户体验（UX）的区别。
他们可以和人讨论工程问题，能搞清楚算法、编程，也能理解前端的等级和后端的等级根本不是一回事。虽然他们可能并不亲自编程，但他们知道GitHub、StackOverflow都是做什么的。如果必要，他们会暴力破解一段“复制粘贴”的脚本，在CSV文件中进行基础分析。
他们是最新锐的社交应用的用户，深谙自我推广 之道。他们既可以在听众面前循循善诱地耐心讲故事，也可以在看了3分钟kickstarter视频后就能指出：亮明要点的时间不能长于一段Instagram、Vine短视频。注意力就是这个时代的硬通货。
全栈员工对新的想法、最棒的实现路径、提升生产力和与愉悦度的事情有着“贪得无厌”的胃口。他们对世界及其运转规则充满好奇心，想知道如何留下自己的印记。正是这一点使他们与过去时代的人们区分开来。开始一份工作时，全栈员工不会戴上“眼罩”埋头苦干，而是始终与行业的发展保持同步，因为他们清楚：变革往往出现在边缘地带，不能只盯着脚下的一亩三分地。
一名全栈员工是什么样子的？
有了24小时在线的移动设备，工作和非工作之间的界限正在模糊，既然工作正在变得碎片化，全栈员工要清楚地意识到自己的生活方式也要随之变化，比如使用整体式单色衣柜、功能明确的厨具。
成为全栈员工意味着要在两极之间来回切换。他们既要适应单兵作战，自给自足（比如自己安排时间，使用自己的设备工作），也要能和团队高效协作。过去，在大型团队中，往往需要有一名 IT经理来决定使用何种技术。如今，随着人们越来越多地使用个人设备工作，员工需要自己来搞定跨设备、跨平台沟通等问题。就拿企业协作工具来说。Slack可以整合所有东西，而微软却只对自己平台上的工具开放特权。如果你不能接入其他人的 API，你已经落后于时代了。全栈员工也是如此——他们至少应该熟知所有最新的应用，这样才不会落伍出局。
全栈员工必须要在自己的领域有深刻的洞见，同时也要机动地应对优先事项的转换，胜任不同的安排。组织的扁平化已经不是新现象，变革的动力可能来自顶层，也可能来自底层，有时候需要个体来决定事情的优先级。现场服务工程师（FSE，Field Service Engineer）应该遍布组织内部，却又不能分布的过于稀疏。即使不用监控每一位员工，他们也应该知道每一个人在做什么，保证他们在不熟悉的事情上不会手足无措。
要成为一名全栈员工不是一件容易的事，回报却也很丰厚。首先，他们可以更自由地按照自己的方式、在自己喜欢的地方（Teleport等服务可以帮助他们找到价廉的工作地点）、喜欢的时间工作。他们可以使用最新的工具，自给自足，自我管理。由于他们的工作涉及多领域、多学科之间的协作，会带来更宽广的视野，更丰富多彩的经历。在组织内部，他们的影响力也会不断上升，对组织的成败也将担负起更大的责任，团队的成功与否更加休戚相关。
这对雇主和管理者意味着什么？
对于企业和管理者来说，在人力市场上争夺全栈员工意味着很多准备工作。首先，你们做好准备来吸引、留住这些人才了吗？其次，你们团队的工作风格是否明确，你们对远程办公的支持如何？再次，你们允许的工作时间，支持员工自主安排工作计划吗？最后，你们会给他们留出健身、养生、陪伴家人的时间吗？
Google虽然充分考虑到了员工的健康、精神需求，但反过来也要求员工高度负责。 Google的员工可以以任何方式在任何时间、任何地点工作，只要能最大程度发挥创造力。但它同时希望员工能够随时参加一场临时安排的快速议事会。你的团队准备好了吗？
如果你还没有尝试过，不妨一试，来感受下”全栈员工“的工作环境是什么样子的。不同背景的人们在一个公共空间内彼此协作。他们一直在线，通过Slack等协作对话平台交流。大多数全员协作空间都是临时搭建，多种实体、虚拟的工具混合使用（白板、投影仪、会议室、视频会议设备等）。
对于职员和管理者来说，最需要培养的是”同理心“——员工和管理者都要对彼此有一种“同情的理解”，在彼此沟通、协作、要求时能够提出具体的需求。因为未来的工作需要高度的灵活性和自主性，但这并不意味着每个人给自己下达工作命令、工作指标。管理者的角色依然是必要的。
未来的工作是什么样子的？
说未来的职场将由全栈员工引领，无疑有些夸张，但这是一个显而易见的趋势。毫无疑问，工作的定义正在发生变化，员工的最大价值是应对不确定性，能够从海量的信息中提炼出有效的战略、战术。
而且，在工作机器人大规模“入侵”之前，我们只有10年的时间。他们正在取代体育新闻、驾驶、快递等重复性工作，人们要重新思考适合自己的角色。感知和综合的能力将是第一位的，而语言、辨析力和同感力在进行复杂、敏感的任务是都是必备技能。全栈员工将帮助我们向未来过渡，将成为新的混合经济中的关键角色。
软件攻城师傅
我觉得所谓“全栈工程师”是自我设限，是格局小的表现。
应该把这个概念升格为“全栈人”。这是一种什么样的人呢？他们自己思考产品方案，自己设计交互，自己开发(管他什么前端后端左端右端呢，全包！)，自己给自己提bug，自己运维上线，自己运营找市场，自己做客服听客户骂。总之就是脱离了低级趣味的、全能的人。
应该把这个概念升格为“全栈人”。这是一种什么样的人呢？他们自己思考产品方案，自己设计交互，自己开发(管他什么前端后端左端右端呢，全包！)，自己给自己提bug，自己运维上线，自己运营找市场，自己做客服听客户骂。总之就是脱离了低级趣味的、全能的人。
No comments:
Post a Comment