酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
成为全栈工程师一般的学习路径是怎样的?
补充一下Full Stack Developer的定义和标准：，这样大家讨论怎样成为Full Stack Developer时不会偏的太远。
Is it reasonable to expect mere morals to have mastery over every facet of the development stack? Probably not, but Facebook can ask for it. I was told at OSCON by a Facebook employee that they only hire &Full Stack& developers. Well, what does that mean? To me,a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology...
，上知乎，求欢乐
既然原文是说，Facebook 工程师说 Facebook 只招 full stack engineer，那我就来说说 Facebook engineer 都是怎样的人啦。
我觉得任何一方面的具体经验都不重要，重要的是思维方式和学习能力。首先说思维方式，那就是不为自己设限，不会想着自己是前端工程师，所以后端的东西我就一点也不碰。Facebook 的工程师，级别越高就需要保持越大的影响力。如何创造更大的影响力，就是寻找当前杠杆效应最明显的问题来解决。有些问题你解决了的话，投入进去的时间每小时能换回来一千美元；有些问题你解决了的话，投入进去的时间每小时能换回来一百万美元。然而哪些问题更值得解决，这是动态的，往往还存在衰减效应。如果现在性能瓶颈在后端，你做了一个季度两个季度优化后，瓶颈就已经不在后端了，你再优化下去衰减效应就会越来越明显。等瓶颈变成前端了，你是不是就说因为你不懂，所以不愿意碰？那就相当于寄望于公司有个前端很懂性能优化的人来解决，但如果公司没有这样的人那就没有人来解决了。
Facebook 的众多海报当中，有一张写的是「任何一个 Facebook 的问题，都不是别人的问题」。有问题，你就需要去评估是否值得解决。如果值得解决，你就应该着手去解决，而不是假设公司内会有另外一个人比你更合适解决这个问题。这时候很可能你就需要去做你从来没有做过的事情，需要学习你原本可能完全不懂的技术。如果你是个专门做数学模型的博士，加入 Facebook 原本是打算做搜索结果优化的，结果发现这不是最急需解决的问题，JavaScript 性能才是最需要解决的问题，你怎么办？如果你以为 Facebook 需要的是你做数学模型的经验，那你就错了。Facebook 需要的是你完成博士学位的学习能力。你从来没做过 JavaScript 并且觉得 JavaScript 很恶心？正确的做法是立即在网上买几本 JavaScript 入门的书连夜看完，然后着手分析性能瓶颈并且解决。在你完成手动优化后，你还可以思考一下能否把这做成自动化，例如说在代码提交时分析 JavaScript 语法树并且指出可能成为性能瓶颈的地方，又或者说从用户浏览器那里收集性能数据扔到 Hive 然后再从中分析产生瓶颈的特征。这些都可能涉及到一些你没有做过也没有学过的东西，但问题摆在那里你就需要去解决，而无论这要求你去钻研什么。这就是我所说的学习能力。
这是高级工程师和初级工程师的主要差距。尽管在高级到初级这一维度上，美国工程师和中国工程师是有重叠的，但美国的教育体系和行业传统使得美国应届生比一般中国工程师更偏向于高级那一端。美国学生的优势在于，他们的教育体系让他们习惯面对开放性问题。一家公司万千问题当中，此时此刻哪一个最值得解决？这不是中国工程师擅长的问题，因为实在是太开放了。中国教育让人擅长在给定条件下解决问题，太开放反而不知道从何入手。此外因为绝大多数文献都是英文的，所以要钻研什么对于能读懂英文的人来说都可以非常成体系的学习，这对于很多拒绝阅读英文的中国工程师来说很不利。拒绝阅读英文意味着永远只能接受别人的二手资料，对于很多概念的理解只能停留在技师的层面，而无法上升到工程师或者科学家的层面。
匿名用户的回答：
这个回答竟然收到的赞同比我其他所有回答都高，看来我还是转型灌技术鸡汤好了。
补充下，首先我觉得好的开发者，即使不是全栈，也要融会贯通多种技术。我从来不认为一个只专精一种技术的人有可能成为好的开发者，即使是 C，即使是汇编。（当然其实反过来看，那些大神们哪个不会搞点其他的？比如几个做服务器端开发的大神居然不懂服务器管理？）
然后从广度和深度的组合看，我认为好的开发者大概有两种类型：
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++反正我掌握的部分足以我写 Cocos2d-x 了，反正公司安排的开发工作我都能完成。
没错，如果是这样，作为一个 C++程序员的话，我依然对不起我的工资。
但我的价值根本不在于是一个 C++程序员，而是我可以从前端到后端到运维提供一揽子方案，视野广阔，任何点都可以选择最合适的技术，如果是创业，我可以自己一个人完成这个纯应用层面难度的开发的全部工作。
如果不是创业，我的价值可能也就是个2w 多工资的架构师或者技术经理，这个价格远远对不起我这13年的付出。一个真正的全栈工程师，目标只有一个：创业。
，Live with less. Share with more.
做这样一个简单的app:
一个天气应用，干净清爽的界面，天气信息一目了然。它不仅可以精确预测未来10天的天气，还可以显示某地的历史天气信息。它具有自定义提醒功能，支持web版本，iOS版，Android版。
为什么想要做这样一个App？因为你喜欢旅行，但没找到一个天气app可以提供你下个月或者某个特定月份的天气信息；因为你懒你没有每天看天气预报的习惯，你想要在第二天温度达到30度以上或者温差有+/-7度的时候，获得温馨提示；因为你要成为一个Full Stack Engineer，你必须不断训练每个stack的能力。
你决定用mysql来存储用户数据，用nosql存储历史天气数据。你用Redis作为cache，缓存一些最常请求的天气数据。你用Python写后台，功能简单，后台不复杂，用户注册登录，抓取返回某城市的天气数据，某地的历史天气数据，很快便搞定。
后台开发并测试好了，接下来是web前端。你十分清楚一个好的UI设计对一个app的重要性，你也明白UI的设计不只是为了美观，更重要的是提高信息的可读性和程序的可用性。幸好你平日的积累这次派上用场了。你把之前保存下来的上百个优秀的UI设计作品拿来研究，你从书架上拿出Norman的那本经典 - The Design of everyday thigns 重新细读。最终你用白纸黑笔敲定了第一个版本的UI，简洁直观，没有任何多余的设计，所有元素的排列间距 大小颜色都恰到好处。你相信即使天气不好，但用户只要使用这个app都会有着愉悦的心情。
那么开始写前端吧。啊，别急，都忘了还有icon和logo，可是不会PS不会AI怎么办呢，学吧。你平日喜欢结交不同领域的朋友，正好几周前在一个活动上你认识一位朋友做设计的。她花一个下午的时间教你基本的PS和AI的使用，并对你的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
，Hexcles / Programmer / (Wanna be) Hacker
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 呢，是因为已经是某一领域的工程师想要做做其他方面么（这个也会影响到&怎样成为&这个问题）？
不好意思，似乎跑题了。到最后自己还反倒提了个问。只是希望抛砖引玉，更踏实的回答多一些，不要太浮躁，把全栈说得太过轻易。
手机打字，如有差错还望指出，谢谢。
，魅族营销中心招募设计师
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 来供他们试用：）？想绕过苹果的 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 给队友，而是更快更好的搞定事情。
，专业造轮子&
资本家压榨程序员劳动力已经升级成，一个人做前端、后端、客户端，只拿一份钱了吗&&
& 相关主题：专访APICloudCTO邹达：被逼出来的全栈工程师
发表于 12:28|
来源新闻资讯|
作者新闻资讯
摘要：移动互联网时代，APP就像一座巨大的金矿，除了听到无数的尖叫和呐喊。更多的是，“我已经有了改变世界的想法，就差一个APP了。”在这个CTO稀缺的时代，无数创业者死在了通往通往金矿的路上，除了卡顿、闪退等性能问题外，更大的问题在于—漫长的开发周期
移动互联网时代，APP就像一座巨大的金矿，除了听到无数的尖叫和呐喊。更多的是，&我已经有了改变世界的想法，就差一个APP了。&在这个CTO稀缺的时代，无数创业者死在了通往通往金矿的路上，除了卡顿、闪退等性能问题外，更大的问题在于&漫长的开发周期
APICloud邹达告诉记者：&如果某一款APP开发只需要一个Android和iOS的程序员花上一个月的时间，那么用APICloud只需要一个星期就够了。&
APICloud作为一款云端一体的开发工具旨在解决两个问题，首先是开发效率问题.邹达告诉记者：&在APP兴起之初，他就曾经帮助朋友做过APP开发，一个项目的周期是两到三个月，而每一次做完的东西在第二个项目却没有办法复用。
其次就是跨平台的问题，在跨平台方面H5的方式虽然方便快速，但是性能问题始终是过不去的坎。在理论上用APICloud开发出来的APP与原生的没有任何差别，我们希望未来在世界范围内我们平台是做的最快、最好的-&邹达对记者说。
做十年技术，还是一项技术做十年？
当记者问到这个问题是时邹达没有丝毫犹豫的说：&当然是后者，而我所理解的技术，不仅仅的是一项技术，而是一个方向。之所以能够一项技术做十年，是因为这项技术本身有潜力，随着技术的发展，自己也得到提升。
在笔者看来，相比于&十年技术，还是技术十年&最重要的问题在于选择什么样的技术。邹达也同样认为：&在2006年的时候还是飞利浦、诺基亚的时代，很多人都羡慕能做手机的人，但真正进去之后发现做手机没有什么技术含量，因为系统都是固定的，大部分代码都是写好的，只能做一些简单的修改，没有一个从无到有写软件的成就感。正因为如此特别羡慕那些做软件的工程师，有一个从无到有的成就感。当时手机里可以卖钱的只有浏览器、邮件，所以为了一种成就感就去做了浏览器。
不想做全栈工程师
从做浏览器开始邹达一直专注于浏览器的开发，直到创业，邹达被逼成一名全栈工程师。
前一段时间很多开发者在知乎上讨论如何成为全栈工程师，而邹达却坦言说：&我其实不想当全栈工程师，但是没办法，逼出来的。&
在APICloud创业之初，作为CTO的邹达负责了公司一切基础设施的搭建，除了应用引擎和服务以外，服务器部署，搭建，监控，前端，&&他坦言，想做全栈工程师。我看来没有压力是不够的，人都是被逼。
邹达还提到：& & &想成为全栈工程师除非创业，否则进入一个陌生的领域你的收入会降低许多。而且像服务器负载这类技术，在没有一定用户数量的情况下，很难达到一定的境界。许多领域内非常牛的工程师，都是公司来交学费，在负载压力很大的时候才能得到一定积累。
APP的兴起是在智能手机出现崭露头角的的2010年，邹达告诉记者：&那个时候就有朋友找他做APP有iOS也有Android。每次都要花掉几个月的休息时间。然而当下一个项目再来的时候，很多以前写过的很多相似的东西都不能复用。那个时候就在想有没有什么办法只写一次还可以重复利用？
许多优秀的项目一开始都是以解决痛点，APICloud也不例外。邹达甚至想过，哪怕这个东西做完卖不出，我还能自己用。在互联时代，APICloud用互联网的思维重新定义了移动开发。
今年2月份APICloud发布了第一款生态产品，更加关注Web开发者，不仅仅能用APICloud做出好的应用，而且可以有更多的方式去变现。在供大于求的行业，APICloud将会汇聚一大批优秀的开发者。如果APICloud有了这样一个成熟的生态链&模块开发者，服务提供商、API开发者，他们都能够通过这个平台去盈利，就是APICloud这个平台的价值，让它成为一个API开发的首选。
【声明：CSDN刊登此文出于传递更多信息之目的，并不意味着赞同其观点或论证其描述，如需更多合作请联系：mobile#csdn.net（发邮件时请将#换成@）】
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章