铁还是优化？Badoo，Avito和Mamba-关于PHP性能
Badoo的PHP性能问题是最重要的问题之一。 PHP后端的质量直接取决于我们在开发和运营上花费的资源数量，服务的速度以及它对用户的印象。因此，在我们办公室的PHP开发人员社区第三次会议的主题上，我们进行了后端性能测试，并邀请了Avito和Mamba的同事进行讨论。
在讨论的过场成绩单下阅读，我很幸运地成为主持人：三家公司的基础设施如何安排，我们如何衡量生产力以及我们关注的指标，我们使用什么工具，如何在硬件和优化之间做出选择。2月15日，参加下一次Badoo PHP聚会：讨论Legacy。我们仅对讨论的部分进行了解密，在我们看来这是最有趣的部分。完整版本可通过视频获得。专家：- Semyon Kataev，Avito核心服务开发部主管
- 帕维尔·穆尔扎科夫（Pavel Murzakov） 普穆尔扎科夫，PHP Timlid在Badoo中
- 米哈伊尔·布洛夫（Mikhail Buylov） mipxtxMamba IT主管
讲述一个有关您的实践中的优化的故事：成功或失败都是很有趣的分享。
曼巴（Miamba）Mikhail Buylov
我有一个寓言。我们大约每六个月检查一次指标，并查看哪些指标变慢，无法正常运行，哪些指标需要优化。一旦我们注意到我们的symfony依赖容器，它就增长到52,000行。我们认为，一切都是罪魁祸首：每个请求20毫秒的开销。我们看到了。我们减少了。我们以某种方式试图将其分离，但是没有任何帮助。事实证明，我们有反垃圾邮件功能，需要处理20个数据库才能满足所有必要的请求。首先出现的解决方案并不总是正确的。更好地了解您的请求的踪迹，日志和基准，不要直接中断。这是一个故事。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
我们在PHP中拥有一个相当大的生态系统，因此我们会定期进行优化。我们正在成长，我们已经达到CPU的某个水平，我们了解我们需要购买硬件或进行优化。权衡每个选项的论据并做出决定。大多数情况下-支持优化，因为铁的需求量很大。在这些问题之一中，我们确定了一个整个团队，他们致力于在PHP脚本中查找各种非最佳的事物并对其进行优化。这实际上是“一滴一滴地”发生的：在这里他们找到了一个百分比，在这里他们找到了一个百分比-几个人在一个月内找到了一个百分比。在某个时候，我们的sishnik就在附近爱因斯坦。他决定看看自己能做什么：他晚上去了，启动了Perf，发现了PHP扩展中的几个问题-并在两个晚上将所有内容加速了13％！Semyon Kataev，阿维托
我有两个故事。一个关于文件，另一个关于超级开发人员。关于失败。我们有许多微服务，包括PHP。每个人都在Kubernetes工作。我从事这些微服务之一。 CPU利用率很高：他们花了一周的时间来优化和发现问题。原来，一位开发人员将Xdebug添加到基本映像中，以计算他（其他）服务中的代码覆盖率测试，此后，生产中的所有微服务都与Xdebug协作了四分之一！ 25分钟后，我们发现了这些固定的基本图像，并开始捕获意想不到的礼物：我重新推出了服务，并且开始更快地工作。在每个部署中，我们的服务映像都将重建，并且现在无需Xdebug。成功的历史。我们有许多微服务，并且它们变得越来越多。在这种情况下，RPC调用的数量成为问题。例如，在公告卡上-这是Avito中最常见的页面之一-渲染页面涉及大约30种微服务。此外，所有这些操作都没有非常明确地完成：似乎您正在调用某种抽象，并且在该抽象下，依次执行了对其他服务的五个RPC调用。多年来，公告卡已大大退化。一位实力雄厚的开发人员奋斗了四分之一，进行了优化，并提出了所有RPC要求。当他能够执行此操作时，他通过Guzzle多请求将它们并行化-而不是30个连续的同步请求，他收到了相同的30个请求，但并行请求，这极大地加快了工作速度。重构之后，卡的响应时间等于任何服务的最大响应时间。但是他需要整个季度来优化/重写公告卡的显示代码。告诉我们，您的PHP群集大小是多少，如何配置-至少是PHP-FPM，或者Apache遇到麻烦的地方？
曼巴（Miamba）Mikhail Buylov
我们有大约15,000 RPS。几年前购买了80个FPM服务器的集群。在每个群集上，将FPM（最多50个孩子）启动为静态对象。在黄金时段，它的峰值负载约为十。平均响应时间为100毫秒，我们尝试将其保持（当超过100毫秒时，我们开始搜索制动片）。我们有自己的绩效监控系统。我们在代码中分散了很多计数器，每个请求约120个。我们监视PHP代码内部发生的许多事件。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
一切对我们来说都是标准的：nginx，PHP-FPM。大约600台具有FPM的服务器。如果只讲PHP，那么大概有300多台服务器可用于各种目的，例如脚本，后台和其他。在配置功能中，有两个。首先，我们有一个BMA代理-这是移动代理。也就是说，在请求到达nginx之前，它会到达一个特殊的代理，该代理保存一个持久连接并将请求发送到nginx。第二个功能-有时您需要关闭CLI opcache（我们已在脚本计算机上将其打开）。一旦我们没有关闭它，就失去了30％的CPU。他们意识到自己的错误后，惊讶于您一次设置可以节省多少。我们有PHP补丁，但是它们几乎与性能无关。颇具竞争力的APCu锁具有一定的意义-当您需要向同一个钥匙写很多东西时。APCu的内部体系结构建立为具有全局键锁定，并且在密集记录期间会开始刹车。因此，我们在那里有一个自定义扩展来解决此问题。这仅部分与性能有关，因为它影响响应时间，但不影响CPU消耗。Semyon Kataev，阿维托
每分钟大约有200万个请求（〜33 kRPS）。用PHP编写的单片应用程序已经编写了11年以上。它正处于快速增长阶段。公司成立之初，在65台物理服务器上有65台LXC。在装有该应用程序的每个容器上，正在运行PHP-FPM，nginx和用于度量和日志记录的辅助软件。没什么特别的。多年来，我们从未为铁矿石添加铁。我们正在增加出席人数，广告数量，用户交易数量，并且我们一直在不断优化，改进代码，优化软件。在过去的几年中，CPU和内存消耗一直在下降：一个整体的65个容器对我们来说已经足够了。您如何衡量效果？您使用什么工具衡量客户的响应时间？
曼巴（Miamba）Mikhail Buylov
我们有一个日志收集系统。它记录两个指示符-从FPM开始到关闭功能的时间，直到脚本结束。需要第二个指标来查看关闭功能后会发生什么。我们测量JS。实际上，这是一个一般指标；经常会侵犯网络通道。结果，在俄罗斯内陆某地的装载开始变钝。因此，我们看起来像这样：“哦，跳了-这意味着某个地方掉下来了。” 再加上第三方广告会严重扭曲该指标。而且，最重要的是，垃圾邮件发送者来了，这通常是某种随机性。Semyon Kataev，阿维托
顺便说一下，我们曾经非常积极地使用Badoo的Pinba。我现在喜欢她。它收集了大多数指标，但随后切换到StatsD协议。现在，我们从不同的角度进行测量：从前端，从应用程序前端的服务器，从nginx以及从PHP应用程序本身。我们有一支敬业的表演团队。她从前线的表现开始，但后来转为后盾。从前端开始，它不仅收集JS，CSS和其他静态信息，而且还收集服务器响应时间。首先，我们专注于应用程序的响应时间。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
一切都与这些家伙告诉我们的相似。使用经典的Pinba for PHP，我们根据PHP来衡量PHP脚本的运行时间。但是，例如，我们还有针对Nginx的Pinba，它从Nginx的角度衡量响应时间。我们还会在客户端上收集指标。我们在看什么？一方面是响应时间。它与资源计划无关。如果不好，则需要对其进行改进，因为实际上它是服务质量。另一件事是，您需要以某种方式计划熨斗。我们的ITOps和监视团队监视所有硬件。网络上的磁盘上有一些栏。警报发生后有一些值-我们正在做一些事情。如实践所示，我们通常会针对CPU进行优化：我们会遇到它。Semyon Kataev，阿维托
在我们这里，PHP应用程序进行自我测量，并在register_shutdown_function（）中抛出指标。每个LXC都有一个StatsD服务器，该服务器收集这些指标并将其通过收集器发送到Graphite群集（包括ClickHouse），并在其中存储数据。这是一种自我诊断。每个容器上还包含nginx，即nginx + PHP-FPM。使用nginx，我们可以收集与PHP应用程序运行时间相关的外部指标。他们还面临着单独的服务器（我们称为avi-http）nginx，该服务器执行基本路由，该路由还收集更高级别的指标，例如响应时间，500个响应代码的数量等。您有什么工具来进行效果跟踪？您最常使用什么？
曼巴（Miamba）Mikhail Buylov
我们编写了自己的工具。当Pinba刚发布时-很久以前的2012年-这是MySQL的模块，通过UDP接收到类似的信息。很难取出图形；它的性能不是很优化。而且，我们没有比编写自己的《比拼巴更好》更好的了。它只是一个从PHP客户端接受它们的计数器服务器。我们在代码中分散了许多计时器：每次我们要测量时，都在代码中设置计时器的开始和结束。模块本身将计算计数器运行时间，将累积的计数器聚合到一个数据包中，然后将其发送到守护程序。界面本身将提取您需要的所有内容，并在所需的计数器上建立连接的图形。Pinba的问题之一是缺少自己的接口-有必要将数据传输到RRD（当时情况如此黑暗）。因此，我们编写了自己的界面。每次看到变化时，我们都可以安装脚本。在脚本中，所有汇总计数器都发送给我们，这些计数器也发送给我们。我们可以看到哪个计数器增长了，或者计数器的响应时间增加了，或者计数器的数量增加了。当性能下降时可以看到。我们开始以这种方式进行挖掘。在PHP 7之前，我们使用XHProf，然后它停止与我们一起构建。因此，我们切换到Xdebug。Xdebug仅在可见问题时才戳。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
人们普遍认为XHProf不会在PHP 7中构建。这是事实，但仅部分如此。如果从向导中获取XHProf，则实际上不会。但是，如果在GitHub上切换到名为“实验性”（或类似名称）的分支，那么一切对PHP 7来说都可以正常工作，可以进行生产。已检查。曼巴（Miamba）Mikhail Buylov
不，我换了。它对我不起作用。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
我想补充一下Pinba。您在某种程度上已经成为先知。我们也在某个时候失去了生产力。我们制作了Pinba2，速度非常快。可以用作Pinba的替代品。Semyon Kataev，阿维托
我们的一切都很谦虚。我们只是将绩效的方向引入了工作：我们收集指标，例如响应时间。我们使用StatsD。我们还没有定期使用任何探查器，但是我可以肯定，有些团队在用PHP编写的微服务中使用了它们。我认为，甚至有人中继新遗物。但是，在主要的整体应用程序的上下文中，到目前为止，我们只是在解决这个问题。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
在Zabbix的Grafana监视铁的历史。至于PHP部分，我们有Pinba，我们有很多计时器。我们在它们上构建方便的图形。我们使用XHProf，在生产中，我们会根据部分需求来驱动它。我们总是有新鲜的XHProf配置文件。我们有liveprof：这是我们的工具，您可以在我的文章中对其进行阅读。这一切都是自动发生的，您只需要观看即可。我们使用phpspy。这并不总是从我们开始：当某人想要看到某物时，他进入汽车并取下个人资料。原则上，Perf就是这种情况。Semyon Kataev，阿维托
XHProf有相同的故事。我们很久以前使用过它：它是几个开发人员的个人举措，实际上并没有取得成功。他停止收集。我们从路由器，控制器和各种模型的调用中收集了很多指标。数据中心内部网络的大约60-70％被带有度量标准的UDP数据包占用。目前，这对我们来说已经足够。现在，我们将寻找新的优化地方。既然我们已经达到了决定性的地步：贵公司是否有人系统地参与了容量规划？如何建立这个程序？
Semyon Kataev，阿维托
单片应用程序至少运行65 LXC至少五年。我们优化代码，对其进行改进：它具有足够的资源。我们的主要容量规划用于Kubernetes，其中约有400种或更少的实时微服务以PHP / Go编写。我们正在缓慢地从整体中切割碎片，但它仍在增长。我们不能阻止他。通常，PHP是一种很酷的语言。它快速实现业务逻辑。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
首先，ITOps和监视团队确保有足够的资源。如果我们开始接近阈值，同事会注意到这一点。他们可能主要负责全球容量规划。PHP部分具有主要的CPU资源，因此我们自己遵循它。我们为自己设定了标准：我们不应“吃掉”超过60％的集群。60％，而不是95％，因为我们拥有超踩，而且从处理器中挤出的内容比没有处理器时挤出的更多。为此，我们要付出这样的事实：在超50％的CPU消耗之后，我们可以以无法预测的方式增长，因为超读取内核并不完全诚实。曼巴（Miamba）Mikhail Buylov
我们进行了部署，发现我们的某些工作失败了-这样的容量计划。用眼睛！我们有一定的生产率余量，可以做到这一点。我们努力坚持下去。此外，我们还会进行事后优化。当我们看到某些问题已经消失时，如果一切都非常糟糕，我们会回滚。但这实际上是不会发生的。或者我们只是看到“这里不是最佳选择，现在我们将快速修复所有问题，一切都会按预期进行。”我们并不特别在意：这非常困难，并且排气不会很大。您正在谈论微服务。他们如何互动？是REST还是使用二进制协议？
Semyon Kataev，阿维托
Kafka用于在服务之间发送事件，JSON-RPC用于确保服务之间的交互，但不是完整的，而是其简化版本，我们无法摆脱它。有更快的实现方式：相同的protobuf，gRPC。这是我们的计划，但当然不是优先事项。拥有400多种微服务，很难将它们全部移植到新协议中。还有很多其他地方需要优化。我们现在绝对不能做到这一点。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
因此，我们没有微服务。有服务，还有Kafka，它是Google protobuf之上的自己的协议。也许，我们会使用gRPC，因为它很酷，它支持所有语言，并且能够很容易地绑定不同的片段。但是，当我们需要它时，gRPC还不存在。但是有一个protobuf，我们接了它。最重要的是，添加了不同的内容，因此它不仅是序列化，而且是完整的协议。曼巴（Miamba）Mikhail Buylov
我们也没有微服务。有些服务主要是用C编写的。我们使用JSON-RPC是因为它很方便。您在调试代码时只是打开了套接字，然后迅速编写了所需的内容。某些东西已经退还给您。Protobuf更加困难，因为您需要使用一些其他工具。开销很小，但我们认为您需要为方便而付出代价，这并不是一个大代价。您有庞大的数据库。当您需要更换其中之一的电路时，该如何做？某种迁移？如果这些迁移需要几天的时间，这将如何影响性能？
曼巴（Miamba）Mikhail Buylov
我们有大桌子，整体的。有一个碎片。碎片更改非常快，因为一次有许多并行更改。一张配置文件较大的桌子大约需要三个小时。我们使用没有读写功能的Perkonovskie工具。另外，我们部署更改以使代码支持两种状态。更改之后，我们还进行了部署：部署比应用任何方案都快。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
我们拥有最大的存储空间（我们称之为“ spots”）-这是一个庞大的分片数据库。如果我们使用“用户”表，那么她有很多分片。我不会确切告诉您一台服务器上将有多少张表：这个想法是有很多小表。实际上，当我们改变电路时，我们只是做一个改变。在每个小桌子上，它很快发生。还有其他存储库-已经有其他方法。如果有一个庞大的基础，那么就有Perconian工具。通常，我们根据需要使用不同的东西。最频繁的更改是在庞大的分片现货基础中进行的更改，我们已经在其中建立了流程。这一切都非常简单。Semyon Kataev，阿维托
可以为大多数流量提供服务的同一个整体应用程序每天部署五到六次。几乎每两个小时。就使用数据库而言，这是一个单独的问题。有迁移，它们会自动滚动。这是DBA审查。有一个选项可以跳过迁移并手动滚动。测试代码时，迁移将自动过渡到暂存阶段。但是在生产中，如果存在某种利用大量资源的可疑迁移，则DBA将手动启动它。该代码应适用于新旧数据库结构。我们经常会多次部署功能。对于两个或三个推出，可能会获得所需的状态。同样，有巨大的数据库，分片数据库。如果将所有微服务都算在内，那么每天肯定会有100-150个部署。我想知道您遵循的标准后端响应时间是多少？您何时知道需要进一步优化的内容，或者什么时间完成？是否有“医院平均值”值？
巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
没有。取决于端点。我们将分别查看所有内容。试图了解这有多重要。通常在后台请求某些端点。即使响应时间为20 s，这也不会以任何方式影响用户。这将在后台发生，没有区别。最主要的是一些重要的事情要尽快完成。也许200毫秒还是可以的，但是增加一点点已经很重要了。曼巴（Miamba）Mikhail Buylov
我们正在从HTML渲染转换为API请求。实际上，在这里，API的响应比大型的HTML响应要快得多。因此，难以区分例如100ms的值。我们专注于200毫秒。然后发生了PHP 7-我们开始关注100毫秒。这就是“医院的平均水平”。这是一个非常模糊的指标，表明该是现在至少应该看看那里了。因此，我们宁愿专注于部署并在部署之后缩短响应时间。Semyon Kataev，阿维托
我们为其中一个绩效团队做了草图。同事们评估了在各种情况下，通过加快页面加载速度，一家公司可以赚多少钱。我们计算了还有多少买家，交易，电话，过渡等。根据这些数据，可以理解，在某些时候，加速度不再有意义。例如，如果其中一页的响应时间从90毫秒加速到70毫秒，那么这将增加2％的购买者。而且，如果您从70毫秒加速到60毫秒，那么已经有0.1％的买家购买了，这通常包含在错误中。就像其他人一样，一切都很大程度上取决于我们正在处理的页面。通常，Avioto第75个百分点-大约75毫秒。我认为这很慢。我们现在正在寻找优化的地方。在过渡到微服务之前，一切对我们来说都快得多，我们正在尝试优化性能。
永恒的问题：铁还是优化？如何理解是值得购买硬件还是投资优化更好？边界在哪里？
Semyon Kataev，阿维托
我的意见：真正的程序员就是优化。在我看来，在Badoo，我的公司，Yandex等大型公司中，有许多不同级别的开发人员。既有初级开发人员/实习生，也有领先的开发人员。在我看来，最优化/修订的位置数总是被添加在那里。铁是最后一步。对于65 LXC上的整体，我们很长时间没有添加铁了。CPU利用率-20％。我们已经在考虑将它们转移到Kubernetes集群中。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
我非常喜欢Semyon的职位。但是我有完全相反的观点。首先，我将看一下熨斗。可以滴铁吗？会便宜吗？如果是这样，那么用铁更容易解决问题。开发人员可以做其他事情，这是有用的。开发人员时间要花钱。铁也要花钱，所以您需要进行比较。目前尚不清楚哪个更重要。如果两者成本相同，则硬件将获胜，因为开发人员此时将可以执行某些操作。具体来说，就PHP后端而言，我们不能这样做。优化的成本要比购买铁便宜得多。即将停止。在计划方面，我们有某种标准。如果我们将CPU消耗降低到低于它，那么我们将停止。另一方面，也有服务质量。如果我们发现响应时间不适合我们某个地方，则需要进行优化。曼巴（Miamba）Mikhail Buylov
在我看来，一切都取决于团队和项目的规模。项目越小，购买硬件就越容易，因为开发人员的薪水是固定不变的，并且工作的代码，使用该代码的用户都大不相同。如果用户很少，那么购买硬件和委托开发人员进行项目开发就容易了。如果用户很多，那么一名开发人员可以补偿大部分服务器成本。Semyon Kataev，阿维托
一切都取决于规模。如果您有一千台服务器，并且优化导致您不需要另外一千台服务器，那么进行优化显然更好。如果您有一台服务器，那么您可以放心地再购买两三台服务器，并在优化上得分。如果命令较小，则启动服务器购买。如果团队很大，而您有两个或三个数据中心，那么购买六个数据中心并不是那么便宜，也不是那么快。由于我们有一个PHP mitap，因此这句话听起来应该是：为什么我们一直需要这样的问题，为什么我们需要PHP？让我们重写Go，C，C＃，Rust，Node.js！
您认为重写方法通常是合理的吗？解决方案是否有问题，值得在此时进行并进行投资？
Semyon Kataev，阿维托
通常，PHP是一种非常好的语言。它确实使您能够解决业务问题。他足够快。所有性能问题都是错误，错误，遗留代码（某种价格过低的代码，以另一种方式可能以另一种语言出现的次优事物）的问题。通过将它们原始移植到Golang，Java，Python，您可以获得相同的性能。整个问题是有很多遗产。我认为引入一种新的语言是有意义的，以便扩大堆栈和增加就业机会。现在很难找到优秀的PHP开发人员。如果我们将Golang引入技术雷达，那么我们可以雇用地鼠。市场上很少有PHP shniks和gophers，并且一起已经有很多。例如，我们做了一个实验。我们聘请了愿意学习新语言的C＃开发人员-我们只是扩展了招聘堆栈。如果我们告诉人们我们将教他们如何用PHP编写代码，那么他们说最好不要这样做。如果我们为他们提供学习用PHP，Go编写程序的机会，并且仍然承诺提供使用Python编写程序的机会，那么人们将更愿意做出回应。对我来说，这是就业机会的延伸。在其他语言中，PHP确实缺少某些东西。但是总的来说，PHP足以解决业务问题和实施大型项目。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
我可能完全同意Semyon。重写只是没有意义的。PHP是一种相当有效的语言。如果将其与其他脚本化非编译语言进行比较，则它可能几乎是最快的。重写成Go等其他语言？这些是其他语言，它们还有其他问题。在它们上写起来仍然更加困难：不那么快，并且有很多细微差别。尽管如此，用PHP编写还是有些困难或不便的事情。一些多进程，多线程的东西最好用另一种语言编写。原则上讲，不使用PHP是合理的任务示例是任何存储。如果这是一项在内存中存储大量内存的服务，则PHP可能不是最好的语言，因为动态输入会导致PHP的内存开销很大。原来，您保存了一个4字节的int，并且消耗了50个字节。当然，我夸大了，但是仍然开销很大。如果您有某种类型的存储，那么最好使用具有静态类型的另一种编译语言来编写它。就像某些需要多线程执行的事情一样。曼巴（Miamba）Mikhail Buylov
为什么认为PHP不太快？因为它是动态的。 Go翻译是将代码从动态类型转换为静态类型的解决方案。因此，一切发生得更快。专门针对Go，在我的计划中有特定数据流的任务。例如，如果有某种数据流需要转换为更方便的格式，这是理想的选择。由守护程序引发，它在输入处接收一个数据流，然后发出另一个。一点记忆就吃。在这种情况下，PHP占用大量内存：您需要仔细确保已将其清除。转移到Go是向微服务的转移，因为您不会删节整个代码。您不会将其完整地重写。与从一种语言到另一种语言的翻译相比，翻译成微服务是一项更深层次的任务。有必要先解决它，然后再考虑要写哪种语言。最难的部分是学习如何进行微服务。Semyon Kataev，阿维托
在微服务中不必使用Go。许多服务都是用PHP编写的，并且具有可接受的响应时间。支持他们的团队自己决定，他们需要非常快速地编写业务逻辑并引入功能。实际上，它们有时比地鼠快。我们倾向于雇用地鼠，翻译成Go。但是我们仍然有大多数用PHP编写的代码，因此至少还要持续几年。没有真正的比赛，我们没有确定围棋的好坏。每天有六个版本发布到整体中。我们的聊天室“ Avito Deploy”具有已部署任务的列表。每个版本每天至少推出20个任务：每天至少五个或六个版本，人们在这些任务上完成了大约80个任务。所有这些都是在PHP中完成的。? -, ?
,
这非常困难。有一个心理时刻：我启动了一个新功能-完成。推出了一项巨大的新功能-您真年轻！当经理或开发人员说他删除了某个功能（已退役）时，他不会获得这种认可。他的作品不可见。例如，一个团队可能会因成功实施新功能而获得奖励，但是我没有见到任何因失效或试验性功能而获得的奖励。因此，结果可能是非常巨大的。一堆尚无人使用的遗留功能确实减慢了开发速度。在许多情况下，一个新人进入公司并重构一个永远不会被调用的无效代码，因为他不知道这是一个无效代码。我们正在尝试以某种方式与管理人员进行谈判，通过golog找出它的功能，与分析师一起考虑它带来了多少钱，谁需要它，然后才尝试削减它。这是一个复杂的过程。曼巴（Miamba）Mikhail Buylov
当我们到达时，我们便切断了无效代码。而且绝不可能总是迅速地削减它。首先，您编写一个代码，然后再编写另一个代码，然后再编写第三个代码，然后在其下方发现不需要此功能。她拉扯了很多依赖关系，这些依赖关系也需要修复。这并非总是可能的，管理人员需要报告它。经理设置任务，您对其进行评估。您说：“您知道，伙计，我会做六个月。您准备好容忍半年了吗？” 他说：“不，让我们考虑需要削减的内容，可以保留的内容。从根本上讲什么是必需的，什么需要玩。” 就是这样。巴杜（Pado）帕维尔·穆尔扎科夫（Pavel Murzakov）
当开发人员收到功能时，他会评估功能的开发难度和性能的难度。如果他发现一个或另一个，则与产品经理一起澄清这是否确实必要，以及我们是否可以在某处移除某物。有时，发生的变化并不重要，经理发现这件事很复杂或正在消耗资源时，会迅速做出让步。只是发生了：您说“让我们删除它”就可以了。碰巧有一个功能离开，然后我们注意到它的性能将不如我们期望的那样好。然后，您可以再次与经理交谈。通常情况下，一切都会成功结束。没有内置功能可以删除功能。这是偶尔执行的。我们看到有一些功能，我们提出并提供将其关闭的功能。我们将其关闭，观察其效果，然后将其裁剪。另一件事是死代码。对于死代码检测，我们有一个特殊的扩展，甚至是整个基础架构。我们看到了这个死代码。我们正在努力将其切断。另一个问题是，如果它真的死了并且请求从不输入，那么它就不会以任何方式影响性能。它影响可支持性。人们会不断地阅读它，尽管他们可能不会阅读。与性能没有特别的联系。15 Badoo PHP Meetup. , : SuperJob, ManyChat, , Badoo FunCorp .
, , YouTube-. , - .
, .
Source: https://habr.com/ru/post/undefined/
All Articles