现在全栈化已经成为了很多团队的默认标签，但是对于全栈到底意味着什么，为什么要全栈化我们的同学还是有些困惑的，我尝试着从自己的理解阐述一下，欢迎拍砖。
从生产线说起
话说当年亨利福特发明了生产线……
哦，不是亨利福特，其实细究历史，生产线也不是凭空发明的，其雏形来自于手工生产中的分工合作，而分工合作最早起源于中国，中国自先秦时期就在武器制造等领域实践了分工合作的方法来提高生产效率。
在生产线发明之前，所有的工作都是一个工匠按照工序顺序完成的，比如就制作陶器来说，从挖泥、运泥、扮土、制坯等等一系列工作都是同一个人完成的，这样这个工匠就具备完成工作的所有技能。
生产线模式彻底改变了传统的生产模式，工匠按照工序来分工协作，每个人只负责整个工序上的一个片段，通过机械传送带输送半成品。因为每个人的工作都是比较固定而简单的，所以工人不需要太多的培训就可以很熟练地完成工作，从而使整体效率得到了极大的提升，产品质量也得到了保证。
也许读者看到这儿会有点疑惑，这么看来千年前的工匠也是全栈化的，而我们今天竟然想回到千年前的工作模式去吗？关于这个问题，后面会给出回答。
瀑布式软件工程模型
传统的瀑布式软件工程模型其实就是生产线模式的翻版，大家根据工作职责来分工合作，看起来好像挺完美的，实际执行起来也还不错，产出了很多优秀的软件产品。但是随着软件行业的发展，大家越来越认识到这种工程模式的效率很低，已经无法适应现代软件发展的需要。
那为什么在制造业非常成功的生产线模式，到了软件工程领域就不适用了呢？
在回答这个问题之前，有必要重提一本旧书，叫做《人月神话》，为什么叫做神话呢，这本书的作者给大家讲了一个例子：1个妇女怀孕9个月可以诞生健康的孩子，请问9个妇女怀孕多久可以生出健康的孩子？
这个例子说明的是，有些事情不是简单地 人*月 就能计算出工作量的。
这本书给我们揭示了一个软件工程中最大的问题，那就是沟通成本随着人数的增加成指数级增加。
而软件工程和传统制造业有一个本质的不同，那就是：
软件工程是创造性劳动，所以软件工程的每一个环节，都有大量的沟通的需要
所以传统的生产线模式会给软件工程带来严重的效率问题，具体表现在工程师们大量的时间用于沟通协调，而无法从事真正的研发工作。关于软件工程的一些特点的详细分析，请参考我之前的帖子。
全栈化是解药吗？
我们需要重新回顾一下生产线解决的问题，就是生产线的每一个环节的工人都只需要面对一个相对简单的工作，所以能够做到很熟练，从而提高效率。如果我们只是把软件开发的所有事情都交给同一个人来完成，虽然这个某种意义上也是全栈，能够大大降低沟通成本，但是很显然并不能真正解决问题，因为这个人需要大量的时间来学习各种技能，同时完成软件开发的每一步的时间也必不可少，一个人开发软件会导致周期漫长，甚至超过人类寿命而变得完全不现实。
那有现实意义的全栈是什么？
我们通过一个简化版模型例子来说明这个问题，我们假设目前的工作时间类似下图：
上图中各个色块表达了各种工作在软件开发过程中所需要的时间成本，而红色的部分也就是沟通成本实际是涵盖了整个软件开发的生命周期。
而理想的全栈模式下，我们期望时间成本变成下图所示：
在理想的全栈模式下，我们希望能够把前端和测试工作分离到尽量和具体业务无关的组件层，而由开发来负责解决所有业务层面的问题，包括和业务相关的前端和测试工作（上图中的两个浅色小方块）。通过业务和组件的分离来最小化沟通成本（红色部分），通过组件复用来最大化组件团队的价值。
要想达到比较好的全栈模式，有一个非常关键的前提，那就是组件一定要能简单易用，不需要很高的学习成本和使用成本。这个前提意味着我们需要清楚地定义组件的问题域和使用场景，清晰的模型以便于学习和理解，和其他部分的交互协议（通常来说也就是API）也需要非常清楚而简单。而做到这个是整个全栈化中最难的部分，如果无法做好组件，那么全栈化的效率提升也就会变成海市蜃楼。
回到本文开头的生产线的例子，今天我们所说的全栈化，其实是工程组织的层次化和结构化之后，软件工程师在不同的抽象层次和维度上的全栈化，并不是说一个开发人员会掌握一切技能解决一切问题。恰恰相反，专业分工依然存在，但是分工合作的时候，大家尽量避免在同一个抽象层次上协作。我们在一个特定的抽象层次上解决问题的时候，虽然也需要了解上层的需求，但是更多的时候不需要和上层应用沟通实现细节，这样也就减少了沟通成本。
全栈化具体需要改变什么？
对于组件开发者来说
需要我们深入理解业务问题背后的可以被抽象出来的问题，建立相应的模型，提出并且实现合理的解决方案和提供形式。这个过程中，要求我们不仅仅能够解决问题，还需要分辨清楚哪些问题应该被抽象出来，哪些问题需要继续留在业务层。这件事情没有统一的标准，需要我们根据具体的问题来分析，站在使用者的角度来提出合理的交互协议。
全栈化的一个关键前提是简单易用的组件（工具），但是不是所有的场景都能够轻易抽象出简单易用的组件的，所以最主要的困难在于对于复杂的现实问题，我们能否找到合理的抽象问题域和解决方案。如果暂时还没有找到合适的抽象模型，我的建议是不要操之过急，而应该花更多地时间去了解和分析问题，找到一个合理的解决方案，而不是为了全栈而全栈。
对于应用开发者来说
需要我们对自己的产品承担全部的责任，熟悉各个组件的能力和交互形式，不再按照专业分工来完成工作任务划分，而是根据问题域来完成任务划分。团队中所有的同学都需要清楚地了解产品系统架构，以及不同架构层面所应该解决的问题范畴。
总结
总的来说，全栈化不是简单地让开发做所有的工作，而是通过合理的系统架构和组织架构，让大家更加有效率地协作，这才是软件工程全栈化的根本目的和方向。
