恕我直言：神话般的全栈工程师

这是开发人员正在进行的系列文章中的第一篇，该系列文章 表达了他们对软件工程和计算机科学领域各种主题的看法。这里表达的观点仅是作者的观点。如果您不同意，请发表评论，当然要让我们知道您的看法。

我怀疑很多人会将这篇文章解释为“守门员”。尽管我可以理解这种观点，但我一直努力提供一个诚实的观点，以反映我过去几年（主要是初创公司）的经验。我还想明确声明我将专注于Web开发环境中的全栈。我完全支持从未编写过HTML或CSS的全栈工程师的想法，而这根本不是本文的重点。无需再费周折： 

如果开发人员生态系统中没有人能达成一致的一件事，那就是全栈工程师。在自学Webdev的过去一年中，我遇到了许多神话，并且学到了有关全栈开发的许多知识。

什么是全栈？

让我们从全栈工程师的一个通用的，绝对没有争议的定义开始：“个人负责设计系统的端到端功能。从最初的用户体验到分布式服务器上运行的后端代码。”

如果您对此定义有批评，那就好。那是因为，全栈工程并不是一件真事。没有科学模型可以描述什么是全栈。没有办法衡量一个人是否比其他人更适合全栈工程师。关于全栈的唯一共识是没有人同意它是什么。这也应该清楚表明您在本文中阅读的其他内容本质上都是观点。

为什么全栈如此浪漫？

即使对于全栈没有达成共识，每个人似乎都同意这是他们想要的东西。在他们的辩护中，全栈的概念非常诱人，与编程无关。Fullstack令人兴奋，因为它解决了构建复杂事物时最不可避免的问题之一：“无论您能为某件零件单独制造多好，集成的开销几乎总是不为零。”

集成可能意味着很多事情，但至少要包括组件配合在一起所需的通信。从理论上讲，全栈工程师将集成开销减少到几乎为0，因为它们控制着单独的组件，因此只需要与自己通信即可。虽然交流不是整合的唯一方面，但以我的经验来看，交流往往是瓶颈。有了对全栈工程的了解，一个人可能比两个，三个甚至四个人生产力更高（假设集成开销不可忽略）。尤其是从业务角度来看，支付一个人多付一些钱来做一份以前曾从事过4个工作的潜力的潜力令人着迷。

民意

我想根据流行的（普遍的）观点为全职工程师创建一个简单的模型。在在线阅读了许多不同的意见之后，我得出了全栈工程师的以下一般定义。全栈工程师是指能够执行构建端到端Web体验的整个过程的任何工程师。我在下面创建了一个模型，该模型正式化了对民意的解释：

最低可行全栈工程师（MVFE）：

使用版本控制

• 懂HTML

• 懂CSS

• 具有良好的编程基础知识

• 熟悉JavaScript前端开发（其他语言优先，JS不可协商）

• 了解分布式系统

• 至少知道一种主要的后端语言（可能是NodeJS，PHP或Java）

• 熟练掌握至少一个数据库/数据库

该定义立即引起一些问题，例如： 

• 它包括测试吗？

• 它包括设计吗？ 

• 它包括操作吗？ 

起初，似乎这些技能对于全职工程师来说并不是日常生活所必需的。但是请记住，全栈的价值来自预期的集成开销减少。即使操作与开发不同，也存在共享的表面积，要求两者彼此了解。一个全栈的工程师也许可以在开发团队的水平上不了解基础架构和云体系结构来解决问题，但是如果他们不会说通用语言，那么他们的潜在价值就会开始减少。如果尚不清楚，则此概念将远远超出操作。它包括由全职工程师负责且需要集成的系统（或产品过程）的任何方面。

流行意见不足的地方

根据我的经验，上述MVFE很少见。该个人资料描述了一个技能，需要数千小时的掌握才能，但不参与整体决策过程。从本质上讲，全职工程师的价值源于他们做出有效的单方面决策的能力（决策无需征得任何人的许可）。我敢肯定有些人最适合MVFE，但我敢打赌，他们之间相差无几。您可能将我对MVFE的看法总结为： 

在不了解全局的情况下成为一名全职工程师是非常不切实际的。

在我看来，全栈工程师的价值主要来自他们单手设计，架构，执行和操作整个端到端系统的能力。假设这是可能的，那么它几乎完全消除了集成开销。

全栈工程的现实

在许多方面，全栈工程日新月异。本质上，全职工程师必须精通独立但高度相关的技术清单。这些技术（例如CSS，HTML和JavaScript）以半隔离的方式开发，从而产生了您需要学习的冗余概念和术语。导致全栈复杂性的另一个因素是第三方软件包管理系统（例如npm）的广泛采用。在诸如npm之类的平台出现之前，最佳实践和标准发展得比较缓慢，这意味着跟上它要容易得多。现在看来，每天都在发布一个新的“最佳”框架，尽管切换的收益通常很小，但社区往往会两极分化，并对那些不使用最新和最佳功能的人持偏见。npm软件包还具有使依赖关系变得不太统一的效果。在过去，情况可能不是最新的和现代的，但是界面通常要统一得多。如今，您最终需要十个软件包而不是一个，它们都使用自己的语法和特定于域的术语。 

需要明确的是，npm使webdev生态系统得以蓬勃发展并以很少的技术拥有。这并不意味着我们应该不了解它的成本，而是有成本的。

全栈工程师的实用简介

既然我们在同一页上讨论了全栈工程的目标和含义，那么现在该为更现实的全栈工程师提出一个简介了。该模型的目的是解决我对“大众意见”配置文件的关注，特别是在潜在整合领域。

切实可行的全栈工程师（RVFE）：“最低可行（MVFE）”配置文件中列出的所有内容。

原理：MVFE中列出的所有项目都是构建现代Web应用程序的基本要求。如果您缺乏MVFE的技能，则可能会建立网站，但绝对不是Web应用程序。

了解业务和客户需求。

基本原理：在传统团队中，了解需求并将其转化为可交付成果通常取决于产品组织。尽管有可能构建您个人不了解的价值，但它会直接影响您就该事物做出快速判断和决策的能力。另一方面，如果您构建的是您真正认同或至少理解的东西，您将有能力做出富有同情心和务实的决策。在我的全栈模型中，必须在外部进行集成的每个位置都会降低效率。如果您不了解客户需求和业务价值，则需要一直整合。

了解行销的角色以及行销与工程的共存方式。

原理：该特定项目有几个方面。我并不是说您需要成为一名营销专家才能全力以赴，只是您需要了解工程和营销如何共存。具体来说，您应该了解分析的重要性和作用，并熟悉将Google Analytics（分析）之类的服务集成到网站前端的过程。市场营销和工程学在很多地方都需要发挥出色，这是其中几个：

• 实施和报告A / B和Canary测试

• 将销售渠道概念（例如转化，展示次数，号召性用语（CTA）等）整合到产品中

• 了解页面设计，布局和响应能力如何影响上述概念

具有强大的项目和时间管理能力。

基本原理：如果尚不清楚，自给自足是全栈工程的基本方面。尽管自给自足的潜在好处是巨大的，但它也带来了一些不幸的现实。这些现实之一是，您负责的越多，其他人为您管理时间就越难。对于我来说，这一点尤为重要，因为我认识到很多人都是非常聪明的全栈工程师。但是，由于他们缺乏自律和时间管理技能，因此可能对他们没有帮助。 

项目管理至关重要，因为它是与团队沟通的最清晰，最简洁的方式之一。它使您承担责任，并使您的经理，合作伙伴和其他有关方面可以了解您的进度。最后但并非最不重要的一点是，它迫使您计划和组织工作。即使您不遵循开发方法，也应该提前计划所有事情。 

具有扎实的设计知识（至少足以与设计师合作）

原理：设计对于全栈过程是如此不可或缺，以至于我几乎可以说全栈工程师至少应该是平庸的设计师。至少，全职工程师应该对现代设计实践和工具感到满意。作为一个全栈开发人员，您对设计的了解越少，那么将设计要求/规格转换成确切的指定结果就越好。这就是为什么我实际上认为以全栈开发人员的身份学习设计会更容易的原因，因为它在开发过程中为折衷方案提供了更多的回旋余地。请记住，您无需成为艺术家即可学习设计。即使只是了解印刷技术，颜色理论和间距的基本知识，也会有很长的路要走。

可以设计，架构和实施端到端软件系统。

原理：如果人们可以就全栈的任何方面达成共识，那就是全栈工程师编写软件。我认为每个开发人员（无论是全栈开发人员还是其他开发人员）都应努力理解他们正在实现的逻辑，而不仅是通过这些动作。

此外，许多全职工程师将在可见性方面挣扎。如果您采用适当的体系结构过程，则无需阅读源代码，其他人就可以更轻松地看到您的意图。它与时间/项目管理直接相关，因为正确的架构设计也是明确的计划。

熟悉CSS最佳实践，现代的增补程序和库。

原理：这与设计要求紧密相关。至少，您应该对CSS有足够的了解，可以确定性地将任何实际的设计模型转换为可扩展且可运行的表示形式。您对CSS越熟悉，您的生活就会越轻松。

在大多数情况下，学习CSS只是记住一堆关键字。您应该非常熟悉一些概念，例如flexbox和grid。基本上，可以使用flex或grid来构建世界上任何一个网站（当时是一个响应型网站）。我还建议您对Bootstrap和Material设计库感到满意。它们通常可以提高发展速度，许多雇主为您提供了解它们的要点。

至少知道一个单页应用程序框架（SPA）（如果只有一个，则必须是React）

我也希望我能生活在一个公社，在那里我们自己种植所有食物并提供我们自己的资源。不幸的是，我住在海湾地区，租金昂贵。尽管社区可以扔掉框架是可以的，但是如果您计划/需要在一家从事前端/全栈的公司工作，或者在两者之间进行任何工作，那么您可能会使用React。即使您不打算使用React，接受采访的人也知道React，这足以让您找到工作。

当前的JS生态系统显然存在很多问题，尤其是在框架和依赖项方面。话虽这么说，我不会割断鼻子来掩饰我的脸。除了生态系统问题之外，我什至不想回到编写普通HTML的原因（出于同样的原因，我不想在ASM中编写Web应用程序）。另外，我很想听到有人解释为什么服务器端模板比SPA更好？除了性能（因为现代设备在2019年几乎没有问题）之外，我觉得人们喜欢服务器端模板，因为这是他们惯用的方式。作为最近进入这个领域的人，SPA路线更加友好。

熟悉特定于域的前端概念（HTTP，CORS等）

原理：对于全栈和前端工程师来说都是如此。我猜您可以在理论上编写永远不会与服务器通信的前端，但这将是无聊的生活。除了请求/响应，您还应该了解很多其他特定于域的内容。老实说，现代实现并没有将这种废话抽象化，这在大多数情况下是不需要触摸的。 

具有较强的SQL和NoSQL技能。

原理：构建合理数量的全栈应用程序之后，您肯定会遇到仅单个数据存储模型还远远不够的情况。尽管看到一些工程师会滥用NoSQL数据库以避免使用关系替代方案给我留下了深刻的印象，在几乎所有这些情况下，与关系替代方案相比，最终导致工程师的工作量更多，并且复杂得多。关于SQL与NoSQL，有很多教条主义的看法，而诚实的现实是，它们既重要又有其地位。不要让不理解妨碍您根据自己的情况做出正确的决定。

对devops感到舒适。

原理：在大多数现代应用程序中，应用程序的运行位置和运行方式会对应用程序的构建方式产生巨大影响。我已经遇到了很多全栈工程师，他们认为他们应该与操作完全断开。尽管这是一个不错的幻想，但实际上，工程和操作本质上是交织在一起的。不仅如此，不能将两者结合起来会限制您可能建立的内容或使您产生的内容变得混乱。 

根据所构建的全栈应用程序的类型，了解操作可能就像了解Firebase上运行的代码所带来的影响一样简单。例如，在Firebase中，您可以使用firebase.config（）代替process.env。我将这种理解水平归类为“操作感知”，这基本上意味着您可能无法自己执行操作，但是您了解所做选择的含义。至少，全栈开发人员应该对操作有所了解。虽然，我会说要成为一名可靠的全栈工程师并且至少不处于初级开发人员级别是非常困难的。如果您不知道将在其上运行的服务器的扩展策略是什么，那么正确构建分布式应用程序将非常困难。 

具备所有级别的测试经验（单元，集成，端到端，UI，压力，A / B，蓝绿色，Canary）

基本原理：如果期望全栈工程师拥有应用程序软件，则他们需要参与测试，否则就不会进行测试。即使您拥有最出色的测试团队，他们也无法快速有效地测试没有人向他们解释的应用程序。因此，全栈工程师至少应乐于在与测试团队相关的情况下解释系统的行为。实际上，如果全栈工程师至少没有编写单元测试，那么您可能已经从全栈工程师那里损失了很多价值。如果他们没有编写代码，则意味着其他工程师不得不花时间理解代码，然后编写测试（从而降低了全栈工程师的价值），或者根本没有任何测试。显然，这两种选择都是不好的。

结论

最终，每个人对全栈工程的定义都会稍有不同。即使我们可以得到全世界的同意，第二天也会有一个新的名词。上面建议的个人资料是我个人经验以及我从他人中学到的东西的产物。我很想听听对人们不同意的方面的批评，以便我可以继续加深我的理解。