谨以此文献给每一个为成为优秀全栈project师奋斗的人。前端
节选自《Growth: 全栈增加project师指南》git
技术在过去的几十年里进步很是快,也将在将来的几十年里发展得更快。github
今天技术的门槛降低得愈来愈快,本来需要一个团队作出来的Web应用。现在仅仅需要一两我的就可以了。面试
同一时候,因为公司组织结构的变迁,以及到变化的适应度,也决定了赋予每一个人的职责将会愈来愈多。虽然咱们看到工厂化生产带来的优点。但是咱们也看到了精益思想带来的变革。正是这种变革让愈来愈多的专家走向全栈,让组织内部有更好的交流。编程
你还将看到专家和全栈的两种不一样的学习模式,以及全栈project师的将来。后端
从開始的CGI到MVC模式,再到先后端分离的架构模式,都在不断地减小技术的门槛。而这些门槛的减小,已经足以让一两我的来完毕大部分的工做了。微信
二十年前的站点以静态的形式出现。这种站点并不需要太多的人去维护、管理。markdown
接着。人们发明了CGI(通用网关接口。英语:Common Gateway Interface)来实现动态的站点。下图是一个早期站点的架构图:架构
当时这种站点的URL相似于: https://www.phodal.com/cgi-bin/getblogmvc
(PS:这个连接是为了解说而存在的,并无真实存在。)
用户訪问上面的网页的时候就会訪问,cgi-bin的路径下相应的getblog脚本。你可以用Shell返回这个网页:
#!/bin/sh echo Content-type: text/plain echo hello,world
Blabla,各类代码混乱地夹杂在一块儿。不得不说一句:这种代码在2012年,我也看了有一些。
简单地来讲。这个时代的代码结构就是这种:
这简直就是一场恶梦。只是,在今天好似那些PHP新手也是这样写代码的。
好了。这时候咱们就可以讨论讨论MVC模式了。
我有理由相信Martin Fowler的《企业应用架构模式》在当时必定很是受欢迎。代码从上面的耦合状态变成了:
相似你们也已经对这种架构很是熟悉了。咱们就很少解释了。假设你还不是很是了解的话。可以看看这本书后面的部分。
在今天看来。咱们可以看到例如如下图所看到的的架构:
后台在不知不觉中已经被服务化了。即仅仅提供API接口和服务。前端在这时已经尽可能地和APP端在结合。使得他们可以保持一致。
软件开发在过去的几十年里都是大公司的专利,小公司根本没有足够的能力去作这种事。在计算机发明后的几十年里。开发软件是大公司才干作得起的。通常的非技术公司没法定制本身的软件系统,仅仅能去购买现有的软件。
而随着技术成本的降低,到了今天通常的小公司也可以雇佣一两我的来作相同的事。
这种演进过程还真是有意思:
在这当中的每一个过程实质上都是为了解决沟通的问题。从瀑布到敏捷是为了解决组织内沟通的问题,从敏捷到精益不只仅优化了组织内的沟通问题,还强化了与外部的关系。
换句话说。精益结合了一部分的互联网思惟。
在最開始的时候,咱们预先设计好咱们的功能,而后编码。在适当的时候公布咱们的软件:
然而这种开发方式很是难应对市场的变化——当咱们花费了几年的时间开发出了一个软件,而这个软件是几年前人们才需要的。同一时候。因为软件开发自己的复杂度的限制,复制的系统在后期需要大量的系统集成工做。这种集成工做可能要花费上大量的时间——几星期、几个月。
当人们意识到这个问题的时候。開始改进工做流程。出现了敏捷软件开发。这可以解释为何产品经理会经常改需求。假设一个功能自己是否是必需出现的话,那么为何要花功夫去开发。但是假设一个功能在设计的初期就没有好好设计,那么改需求也是一定的。
现有的互联网公司的工做流程和敏捷软件开发在很是多部分上是相似的,都有迭代、分析等等的过程:
但是据个人所知:国内的多数互联网公司是不写測试的、没有Code Review等等。固然,这也不是一篇关于怎样实践敏捷的文章。
敏捷与瀑布式开发在很是大的差异就是:沟通问题。传统的软件开发在调研完毕后就是分析、开发等等。
而敏捷开发则会强调这个过程当中的沟通问题:
在整个过程当中都不断地强调沟通问题,然而这时还存在一个问题:组织结构自己的问题。
这种组织结构,例如如下图所看到的:
假设市场部门/产品经理没有与研发团队坐一块儿来分析问题,那么问题就多了。当一个需求在实现的过程当中遇到问题,到底是哪一个部门的问题?
相同的假设咱们的研发部门是这样子的结构:
那么在研发、上线的过程当中仍然会遇到各类的沟通问题。
现在,让咱们回过头来看看大公司的专家与小公司的全栈。
假设你经常看一些关于全栈和专家的技术文章的时候。你就会发现不一样的人在强调不一样的方向。
大公司的文章喜欢强调成为某个领域的专家。小公司喜欢小而美的团队——全栈project师。
如咱们所见的:大公司和小公司都在解决不一样类型的问题。大公司要解决性能问题,小公司都活下去需要依赖于近乎全能的人。并且,大公司和小公司都在加班。
假设从这种意义上来讲。咱们可以发现事实上大公司是在剥削劳动力。
专家
咱们所见到的那些关于技术人员应该成为专家的文章,多数是已经成为某个技术领域里的专家写的文章。并且咱们可以发现很是有意思的一点是:他们都是管理者。
管理者出于招聘的动机。所以更需要细分领域的专家来帮助他们解决这个问题。
全栈
相似的,咱们所看到的那些关于成为全栈project师的文章,多数是初创公司的CTO写的。而这些初创公司的CTO也多数是全栈project师,他们需要招聘全栈project师来帮助他们解决这个问题。
而不知你是否也注意到一点:专家们也在强调“一专多长”。因为单纯依靠于一个领域的技术而存在的专家已经很是少了,技术专家们不得不根据于公司的需求去开拓不一样的领域。毕竟“公司是指所有资本由股东出资构成。以营利为目的而依法设立的一种企业组织形式;”。管理人们假设技术自己是相通的,既然你在技术领域里有至关高的长板,那么进入一个新的技术也不是一件难的事。
做为一个技术人员,咱们是这个领域中的某个子领域专家。
而做为这样一个专家。咱们要扩展向另一个领域的学习也不是一件很是难的事。
借鉴于咱们先前的学习经验,咱们可以很是快的掌握这个新子域的知识。
如咱们所见,咱们可以很是快地补齐图中的短板:
在近来的探索中发现有一点很是有意思:假设依赖于20/80法则的话,那么成为专家和全栈的学习时间是至关的。在最開始的时候。咱们要在咱们的全栈project和专家都在某个技术领域达到80分的水平。
那么专家。还需要80%的时间去深刻这个技术领域。而全栈project师,则可以依赖于这80%的时候去开拓四个新的领域:
虽然理论上是如此,但是专家存在跨领域的学习障碍——套用现有模式。
而全栈也存在学习障碍——怎样成为专家,但是懂得怎样学习新的领域。
有意思的是——成为专家仍是成为全栈,取决于人的天性,这也是两种不一样的性格决定的。成为管理者仍是技术人员看上去就像一种简单的划分,而在技术人员里成为专家仍是全栈就是第二种划分。这取决于人们对于一个问题的思考方式:这件事情是借由外部来解决,仍是由内部解决。如下这张图恰好可以表达个人想法:
而这种思惟根据于不一样的事情可能会发生一些差别。但是总体上来讲是相似的。当遇到一个需要创轮子的问题时,咱们就会看到两种不一样的方式。
对于全栈project师来讲,他们喜欢依赖于外部的思惟。用于产生颠覆式思惟。
如Angular.js这种框架即是样例,前端结合后端开发语言Java的思惟而产生。
而专家则依赖于内部的条件,创造出不同的适应式创新。如以前流行的Backbone框架,适应当时的状况而产生。
全栈project师自己不该该仅仅局限于前端和后台的开发。而可以尝试去开拓更普遍的领域——因为全栈自己是依赖于project师自己的学习能力。正是这种优秀的学习能力可以让他们可以接触更普遍的知识。
假设你也尝试过面试过全栈project师。你会怎么去面试他们呢?把你知道的所有的不一样领域的问题都拿出来问一遍。
是的,这就是那些招聘全栈project师的公司会问你的问题。
人们觉得全栈project师什么都会,这是一个明显的误区——然而要改变这个误区很是难。最后。致使的结果是你们认为全栈project师的水平也就那样。
换句来讲。人们根本不知道什么是全栈project师。
在平时的工做里,你的队伍都知道你在不一样领域有丰富的知识。而在那些不了解你的人的印象里,就是推測你什么都会。
所以。这就会变成一个骂名,也是一个在眼下看来很是难改变的问题。
在这方面仅仅能尽量地去了解一些通用的问题,并不能去了解所有的问题。
在一次被面试全栈project师的过程当中,有一个面试官准备了几个不一样语言(Javascript、Java、Python、Ruby)的问题来问我,我仅仅想说Ciao——意大利语:你好!
除了这个问题——人们不了解什么是全栈project师。另外一个问题,就是刚才咱们说的成为专家的老大难问题。
让我绝不犹豫地选择当全栈project师有两个缘由:
当我第一次看到全栈project师这个名字的时候,我发现我已然是一个全栈project师。
因为个人学习路线比較独特:
中小学:编程语言 -> 高中:操做系统、内核、游戏编程 -> 大学: 硬件、Web开发 -> 工做:后端 + 前端
而在当时我对SEO很是感兴趣。我发现这分析和Marketing彷佛作得还可以。而后便往Growth Hacking发展了:
而这就是全栈学习带来的优点,学过的东西多,学习能力就变强。学习能力往上提的同一时候,你就更easy进入一个新的领域。
參考书籍
不少其它内容欢迎关注个人微信公众号(搜索Phodal):