您好，我叫Pavel，我在Mad Devs *掌声*中满座。在大量文章和材料的背景下，关于
不需要 全栈，不存在 全栈 ，
全栈不好的事实，人们认为
全栈与专业专家相比有什么优势 ，以及为什么
需要全栈 。
我想在文章开始时留下其他文章的链接列表，这些文章是关于全栈的，但是它们太多了，所以很抱歉。 我只想说关于为什么一个完整的堆栈好以及为什么一个完整的堆栈不好的资料已经足够了。 他们每个人至少有50％是真实的。
可能有些个人的情感和思想并没有声称是万不得已。
正如我已经说过的，我的名字叫Pavel，自从我获得编程资金后，即将过去7年了。 在这段时间里，我在履历表，访谈和其他地方给自己打电话：
在Frontend和DevOps方面具有知识和技能的后端开发人员 。 在职业生涯中，他总是以某种方式在项目的后端工作，但他从不惧怕前端或操作。 因此，他自豪地将这两个领域添加到他的描述中。 的确，随着Mad Devs的出现，并与MadOps团队一起完成了一个项目，我从描述中删除了DevOps，因为现在我认为我根本不理解它。 如您所知，所有比较的东西都是已知的。 我希望有一天能与那些可以说服我删除前端脚本的前端专家一起工作。 最主要的是不要遇到一个后退者，这将迫使您从简历中删除该后退者，否则将一无所有。
专家们最常提出的论点是，他们认为完整堆栈是很糟糕的声音： 而且，我同意他们的观点。
在过去的几个月中，我一直在研究Peklo Tool项目，该项目在后端使用Ruby，在前端使用VueJS，并使用Go来实现文本生成器。
我觉得有问题：
- 我认为Go上的这段代码可以编写得更好，并且可以更快地运行或使用更少的系统资源。
- 我觉得我的webpack配置可以配置得更好，现在里面有很多垃圾。
- 我认为可以使用现代CSS，SCSS功能或采用PostCSS或其他扩展来完成此布局。
- 我觉得可以优化轨道上的代码，例如，减少对数据库的查询。
- 我觉得索引需要在数据库中人为配置。
- 我觉得这个Dockerfile需要重写，以便减少（或增加）层。
- 等等，等等，等等...
我能感觉到一切。 而且，我真的很想做这一切。 而且，当出现空闲时间时，我会部分解决至少这些问题之一。
您问我：
为什么不立即在这里使用事物N，以免出现此类问题？我将回答：
我不知道N，这太好了，以至于我可以在特定情况下将其快速应用于项目中。 我只是花时间进行开发 ，请阅读问题：
没有完全的沉浸感 。
而且我不会撒谎，因为我从事的项目需要功能。 PekloTool是用于生成上下文广告活动的专业工具。 该工具还很年轻，开发已经进行了一年多，但仅在几个月前才正式投入生产。 结果，现在我们正在做对此类产品有用的所有功能。
我怎么知道功能是必需的，功能将是有用的？ 很简单，
因为我堆满了 。 我看到了整个项目。 我看到了项目的目标，看到了它的工作原理，看到了它的门槛，不仅是我上面写的技术性门槛，而且是用户会看到的门槛。
这就是本文的要点：我认为，现代的完整堆栈不应只是可以执行后端，前端或其他操作的编码器。 Fullstack是参与项目开发的人。 除了后端，前端等能力 完整的堆栈应该对项目的主题领域，UX / UI知识甚至一点营销都有了解。 Fulstack必须知道该项目如何完成其主要任务：是赚钱还是拯救世界。 整个堆栈应该与项目的“客户”距离很近。 任何项目都有一个“客户”，如果是外包公司，则是客户，在产品公司中，则是利益相关者或产品。 “客户”应在整个堆栈中看到该专家，您可以与该专家就有关项目的所有问题进行协商。
在新人Mad Devs的手册（公司第一天提供给您阅读的同一文件）中，有一个项目称为：“ Customer Affinity”（客户亲和力）（
Eng。- “ Customercloser”）。 我在上一段中描述了该术语的实质。 完整的堆栈应始终放在客户的帽子上；理想的选择是当“客户”与完整的堆栈一起进行冲刺任务时。 也就是说，完整的堆栈可以了解每个任务的出现历史，而不仅仅是解决给出的任务。 我相信，如果一个人仅执行任务并且工作到此结束，即使他执行后端，前端，移动电话等，这也不是全部。 这只是可以做前端的后端，反之亦然。
所以我写下了所有这些，读者可能有两种想法：
- 什么废话 。 在这里给自己每个人。 如果您这样认为，很可能您是一位狭narrow的专家，那么您的意见就很明确。 但是，如果您满座，我会“让您开心”。 您将失去大量有益的活动，这些有益的项目将使您的项目受益，也将失去获得重要能力的机会，这些能力将决定您职业的进一步发展；
- 这是产品所有者应具有的完整堆栈外观吗？ 是的，你是对的。 除以下几点外，产品所有者通常是整个项目的团队负责人。 我不会将领导素质归因于全部。 这是关于别的事情。 好吧，产品所有者应该能够考虑开发项目的成本，不需要全盘考虑与开发相关的财务。 从他的职位来说，已经有了发展的钱。 当然，他可以提供降低开发成本的选择，但只能以百分比或质量为单位，而不是以数量为单位。 也许有片刻我想念该产品应该能够做到的一些东西，但我可以，我已经堆满了。
我想描述硬币的另一面。 真
可悲 。 全栈的问题是它们过载。 这是显而易见的。 通常，我们执行大量任务，复杂功能。 我们仍然与客户保持联系，以提出我上面写过的功能和任务。 另外，从技术角度看整个项目时，通常会涉及基础架构，体系结构和其他方面。 信息越多，想法越多，想法越多，实现它们的机会就越大。 结果，您经常会想到：可能是NoSQL数据库，或者是GraphQL，或者其他。 这就是就业本身出现的地方。 我并不是在谈论我立即设法将所有内容转移到条件GraphQL的事实，但是您有时会自己接受一些较小的想法并实现它们。 总之，很忙。
你想要什么？ 我想尝试一个新的库，进一步研究Gitlab CI配置，在前端为自己准备一些有趣且相对较新的东西，例如Logux。 但是没有时间，您负责该项目。 我不会说这种
悲伤 ，只是悲伤。 相比之下，我得到了很大的嗡嗡声：从看到积极的用户评论开始； 当他们高兴地撰写有关某项功能的信息时，您几天没有睡觉； 用户数量增加时。
总而言之，我表达的观点是，狭窄和广泛的专家在项目，职业，环境和劣势方面都有自己的优势。 我认为，我将在以下材料之一中描述特定的专业优势和劣势，除非当然可以热烈接受。
我很高兴能全职参加，因为这是我喜欢的工作，我不介意在周末做，而且我很乐意做。