作为一名全栈工程师，我每天的工作就是盯着代码编辑器里面各种的 React、Ruby on Rails 以及 AngularJS 等大量的遗留代码——从构建新 API，到数据模型，再到丰富的用户界面，我把构建端到端功能所需的所有技术都学了个遍。
不过，技术只是工作的一部分，我还需要与其他团队搞好关系，确保我编写的代码符合他们的系统标准。好在对我来说，这种类型的工作虽然压力很大，但也令人兴奋。广泛的责任范围为我带来了大量的学习机会，我也因此迅速成长。
我认为全栈是一份值得付出大量努力的工作，对我的个人和职业发展来说更是一份宝贵的经历，原因主要有以下五个。
更快速
如果工程团队对组织内的系统和工具缺乏大致了解，那么即便人数占优，速度也比不上一位全栈工程师：
知识碎片化：发现和编写技术规范需要更长的时间，因为需要多名工程师共同参与。
频繁的会议：在动手开发之前，经理可能需要召开很多会议来协调工程师。
工程师之间彼此“束缚”：为了等待其他人的进度，工程师经常很闲或者去干其他工作。
而我，由于拥有全栈开发能力，可以避开上述导致效率降低的大部分问题并快速行动。例如，我在一家中型创业公司学习了全栈技术，并构建了一个端到端的功能，前端 + 后端使用了两种不同的编程语言，接触了五个不同的代码库，最后在几个月内就开始创收。
这引起了高管们的注意，看到我可以独自开发这款产品，他们表示十分惊讶。因为根据他们的经验，构建类似的产品需要投入一个完整的团队，期间涉及各种协调，花费的时间也更长。
找到更多解决问题的方法
全栈意味着，对各种系统如何协同工作有着整体的把握，这种视角常常让我发现别人都看不到的答案和机会。
我个人对一些项目的贡献包括：
帮助停滞的项目重新启动。我通过各种角度调查一些失败项目，并帮助他们重新启动。例如，是否可以通过前端更轻松地实现后端的一些功能？使用 React 还是 Rails，哪个更快？我们可以在不同的代码库中实现这些功能吗？
团队之间的横向交流。在开发代码库 A 时，我发现了一些可能对代码库 B 有帮助的模式，于是我充当起了两个团队之间的桥梁，帮助推动他们采用可扩展的实践。
提高沟通能力
根据我的经验，寻找领域专家并与他们建立关系，是快速学习以及为技术栈的各个部分做出贡献的关键。为此，我学会了与不同的团队沟通，并与他们建立友好关系——这意味着，向其他团队自我介绍，寻求有关如何做出最大贡献的指导。
通常，我会提出以下问题：
介绍一下你们的代码审查流程？
代码库的长期目标是什么？
你们有哪些没时间解决的技术债务？
我个人最喜欢最后一个问题，这样我就可以帮助他们解决技术债务问题，从而与他们建立友好关系。等以后我需要帮忙合并 PR 时，他们也会愿意提供积极的帮助。
更好地了解业务
产品和营销团队可以描绘出用户行为，而全栈工程师也可以通过技术追踪用户行为。举个例子，将用户从注册到付款的完整体验映射到技术：
用户打开营销网页：Gatsby 静态站点应用程序。
用户登录/注册：NextJS 应用程序和移动应用。
创建新用户：在 Ruby on Rails 中构建的 GraphQL API。
用户提交订单：移动应用。
用户的付款流程：React 收费应用。
将用户体验映射成技术栈是一种超能力，这种能力可以帮助我清楚地了解为了改善用户流失率，我需要深入研究技术栈的哪些组件。例如，如何提高注册转化率，通常我会建议营销应用使用更好的交互按钮，将用户引到注册页面，改进 GraphQL API 的注册请求响应时间，或者简化 NextJS 应用中的注册表单。
总之，了解整个技术栈可以有效地将业务问题转化为技术解决方案，并带来独特的构思视角。
培养领导能力
由于有效地解决了一系列问题，我经常为技术提案提供意见，指导工程师，并协助管理项目。
此外，我也承担起了一些有趣的工作：
充当“粘合剂”：将工程师与正确的资源联系起来，加速他们的发展。
改善团队间的文化：在我看来，全栈意味着担负起整个系统所有的工作。我经常在各种会议中充当管理的角色，并创建了很多文档来促进团队之间的统一性。
最后的想法
代码库有边界，但业务无边界，很多业务问题都需要跨越多个代码库——这就是为什么我认为，开发人员应该培养能够承担起系统所有工作的技术和心态。
总的来说，我认为全栈开发人员的主要优势如下：
更快速；
找到更多解决问题的方法；
提高沟通能力；
更好地了解业务；
培养领导能力。
当然，全栈开发也有很多缺点。首先，你需要付出大量的时间和精力；其次，专业领域的深度也比不上专家；最后，经常需要独自工作，缺乏指导。
不过，无论你在小型创业公司工作，还是在大型企业就职，我相信每个人都可以在全栈开发中受益。
