有相当一部分开发者, 在职业生涯抵达某一时刻时, 便会开启寻求“全栈”突破之旅, 其缘由往往在于能够加速自身成长速率, 急切渴望以双倍速度迅速冲破职场发展瓶颈, 进而进阶到更高一级的职位上去。作者 | 云昭于这般一个时代之中, 非但仅是老板们, 甚至于哪怕是那些工程师们, 也全都满心期望人人皆能够成为全栈的那种状态——要是初创公司或者处于科技前沿领域的行业在开展招聘工作之际, 通常情况下都会盼着候选者身为一名全栈工程师。唯有一份工资的条件下, 却能产出两份成果, 老板们面对如此这般的一类人才, 理所当然都会感到“幸甚至哉”同样的情形是, 有不小比例的开发者, 于职业生涯步入某一阶段时, 会着手迈向“全栈”方面的突破, 原因经常在于, 这样能够促使自身成长速率得以提升, 急切渴望凭借双倍的速度迅速冲破职场发展的阻碍, 进而升至更高一级别的岗位。你瞧, 要是讲全栈这一概念出现且兴起要是因最起初的技术组“LAMP”具备着超乎寻常的强大能力故而不得不采用的话, 那么当下全栈流行的状况, 大概是逃不出这两个缘由: 其一, 能够为老板创造收益, 其二, 是身为程序员最终的归处。1、全栈的雷区迷信全栈存在着很大的危险性, 其雷区具体表现在: 如今所强调的前期节省, 都会在日后变为成本, 这包括“畸形”的数据库, 大量等着去补偿的技术债务, 以及用户脸上那难以用言语去形容的愤怒表情。图源网络这同样是为何, 产品、开发、运维于沟通协作里, 明明各自表达观点, 然而所获取的结果常常是“鸡零狗碎”。因为一个人做到全栈很难那些觉得自身能够妥善处理多任务的人, 常常最终结果极为糟糕, 而全栈工程遂成为了一个关乎“长期上下文切换”的生产事例。存在这样一个多线程的典型难题, 设计一个具备恰当索引的Boyce Codd范式数据库模式, 并且实现一个高度可扩展的调用, 与此同时构建一个直观简洁的用户界面, 来展现与相应对象模型的交互, 之后, 支持并维护完整的实施以及过程里可能出现的所有问题。即便是一个多年经验的老兵看到这些可能都会退避三舍。原因在于, 前端复杂, 后端同样复杂, 二者皆有自身的优先级与实践。精通任何一个“端”, 都得历经多年摸爬滚打, 才勉强能做到。别忘了, 每个“端”都随时代在演进着。对于那些有着经验欠缺情况的工程师来讲, 全栈工程是不契合考量的, 原因在于认知负荷达到了过度的状态, 这容易显著地致使开发速度下降, 并且会促使更多错误产生出来, 其遗留的隐患影响深远。而对比于经验丰富的老兵来讲, 全栈工程也仅仅能够呈现出一份在当时勉强还能算得上说得过去的答卷效果, 然而在没过多久之后, 也会暴露出各种各样的问题状况。只是, 一旦某个领域持续迅猛发展, 那么就连经验过人的工程师也很费劲去跟上。虽然我们具备不少天赋, 然而大脑并非呈指数级, 于繁重的认知负荷状况下, 人们多线程处理的能力欠佳。而在繁重的认知负荷之下, 人们多线程处理的能力较弱。2、全栈为什么只适合小项目要是你前往招聘软件那儿去搜索“全栈”的话, 那么就会发觉要么招聘的一方是小公司, 要么那“全栈”会出现在前端工程师的岗位需求当中。这也并没有什么好奇怪的了, 这竟然能够使得人萌生出这样一种已经固定下来的印象, 那就是只有小的公司才会拥有全栈工程师。在这些组织当中, 高效的全栈工程属于需求, 同样, 早期创业公司在寻觅资金之际, 有时会倾向于打造一个“松散”的MVP, 这很可能是基于服务器端渲染框架构建的, 全栈工程师能够达成这点, 然而他们不能因初创公司无法招聘更专业的团队就被利用, 或是承受不公平的压力。此处要点在于, 要瞪大双眼, 当公司获取巨额资金之际, 就要自起始之处重新编写程式码。这并非关乎修补重构或扩展孱弱简约可复用最小化可行产品的事宜。公司极有可能将其摒弃, 再度着手, 借助一支资质达标的专业工程师队伍更强劲有力地将其搭建起来。倘若每个人能够接纳全栈工程存在的局限性, 而且心甘情愿承受相应后果, 不会因代码库存在的缺点去惩处团队, 那么就让全栈“自行畅快游动”啦。存在于一部分软件工程里的问题, 任何独自开展工作的全栈工程师都能够制定出可行的解决办法。常见的一般有两个用例:存在这样一些问题, 它们为人所熟知, 并且具备简单的特性, 能够借助服务器端渲染框架予以解决。Ruby on Rails等等众多框架可被列举。要是所需解决方案与这些框架正好全然相符, 那么经验丰富、熟稔这些框架的全栈开发人员团队完全有能力高效地进行构建。可是请记好, 虽说这仅仅能够满足短期的需求, 然而其在复杂性以及规模状况下的生存能力存在着上限的。全程参与软件从开发前端到后端的开发者, 是致力于针对一系列众人皆知的问题, 去设计出某些有限的选择的。任何工程挑战面前, 全栈都绝非最适宜之选。极有可能在不远的未来, 就非得对代码库予以重构, 从而转向规模适宜之服务, 或达成一种更为别出心裁之办法来应对新问题。3、大厂不配有全栈工程师在大型企业里, 很少能瞅见一位工程师大包大揽一切事务的那种情形。然而全栈类型的人才数量并不少。也就是说, 大型企业当中不存在全栈式工程, 可是全栈思维通常来讲是绝对不能缺少的。这是由于有着高效的协作运转机制。以前后端沟通协作为例。其中他们的多数工作, 每一个人均能够单独予以完成, 全然专注于自身的专业范畴之内, 并且以善意之态忽略了对方所存在的诸多顾虑, 然而, 一旦他们各自的责任领域出现了相互重叠的情节之际, 团队成员便会展开协作, 进而确定出最为妥善的解决方案来的。是哪些数据供用户所需进行访问抑或是编辑, UI 会依靠怎样的方式进而去调用 API , 数据合同的具体模样又是怎样的, 团队围绕这些问题一同开展协调工作, 而后分头着手去处理解决方案里各自对应的部分。经由把团队聚拢一块儿开展这类对话, 的确能够于短时间之内把进程缩减至一半, 然而一旦他们再度分开, 你便会恢复到全速状态, 要有更快的速率并有在各自职责里正确施行功能。与此同时, 全栈工程师至多仅能以一半的速率达成整个项目, 多任务处理以及上下文切换会使所有事情陷入两难境地如您所期, 鉴于职责有重叠, 每个团队成员都务必要清楚对方的专业范畴。但倘若在此方面专业知识不够深度, 尤其是针对那些尚处于职业生涯开端阶段的工程师来讲这般也OK。当然, 这并不是在讲, 大厂内部不存在具备全栈能力人才的情况, 相反, 通常处于较高层级的技术人员, 他们所拥有的全栈思维更为突出, 在沟通以及决策的过程当中, 发挥着至关重要的作用。4、全栈需在合作中精心打造全栈不是万金油。只有合作才是成长的正确路径。在软件工程师职业生涯刚开始不久的时候, 或许在别的职业当中也存在着这样一种趋向那就是试图一次性把所有东西都学会。然而实际情况总是会让人遭受挫折。依据1万小时定律, 后端需要1万小时, 前端需要1万小时, 算法需要1万小时, 运维需要1万小时……早晚是会垮掉的。设想一下, 尝试同步去攻读数学以及生物学这两个博士学位, 进而着手去处理一个深奥的难题。伴随着你自身注意力以及时间被分散开来的状况, 甚至你需要耗费许多年才能够完成其中一项博士学位。重点就在于, 等到那个时候, 这个深奥的问题已然依靠两位博士合作而被解决掉了, 如此一来可就尴尬了。然而要是两个人各自在专业术语方面存在专长, 并且时不时去沟通交流各自所在领域的研究进展情况, 即便该问题尚未被解决, 也极有可能会探寻到解决问题的方向。软件工程同样是这样的情况。当你做出决定, 即在相当长的一段时期当中, 专心致力于前端或者后端方面的工程, 接着去掌握如何在有着不同专业背景的人员所构成的团队里边, 顺利地实现较好的协作, 如此一来, 便能够取得更为快速的进步。在于此这原因, 一个团队的成员通常被予以安排得各有所长。成员通过合作学到跨学科知识, 此跨学科知识会帮助成员解决更多难题。久而久之的积累团队的成员就会变成“有主有辅”的全栈人才。5、写在最后大多数情形下, 对于企业来说, 全栈仅是一种选择, 可在工程师资源受限状况下, 达成一个并非最优的方案。当然, 存在一些特殊情况, 像特定用例里的特定工具, 全栈工程师能够交付近乎完美能正常运行不产生故障的功能代码。要知道, 对于有着多年经验的高级工程师来讲, 全面的专业知识能够合乎情理地变成一种最终的选择。然而, 这里得记住, 千万别把全栈视作那种能包治百病的万金油, 它不是用来解决所有问题的, 恰恰相反, 它是专门针对某一领域里确定的那些问题来求解的。所以呀, 全栈思考问题的这种方式是值得给予肯定的。技术栈的各层, 其发展速度相当快, 没有任何人能够掌握全部内容。职责呈现出多样化且专业化, 这是一种自然而然产生的结果。所谓的全栈, 往往借助合作, 能够以更快且更有效的方式达成目标, 而非一直独自去干、独自去学。真正称得上全栈工程师的人, 技术方面的工作仅仅是其中一半的内容。而另外一个起到关键作用重要部分, 是要跟其他团队构建起达成一致的合作关系, 以此来保证所编写的代码, 可以契合他们系统所设定的标准, 进而达成一致的目标。参考链接