ℹ️ 🤵🏻 🍔 该死的老客户关系管理 👩🏼 🎢 ❓

去年全年，我们的员工使用BPMS Camunda完成了CRM 2.0，仅完成了10个流程，而不是数百个状态，然后尝试将其推广到用户和服务，而又不放弃任何东西。我希望在最终从我们的生态系统中删除了第一个tcm-ku（所有Skyeng中最古老的部分）后，他们将共享耙并在这里找到。

同时，由于对该主题感兴趣，我发现了一个类似的案例-并决定向Finam的Dmitry Kosov询问他们放弃2010年代早期遗产的经验。

嗨，我是来自Bryansk的“ Seryozha”，他决定通过博客和关于PHP主题的截屏视频来吸收开发知识。今年，我想在我的活动中添加一个播客：邀请行业同事参加。在第一集中，讲述了从第一个Zend迁移到Symfony的故事。如果您需要更多技术细节，请查看Dima在YouTube上的演讲。好吧，在我们对报告进行讨论之后，您将知道：

如果您知道这是在发布正式代码之前一年的时间，那么如何避免迷失并寻找动力，

为什么有没有撒谎，没有撒谎的文件，

以及如何使用一个真实的项目和团队的示例来组织两年重构的过程而又不停止功能的生产。

喜欢阅读或听。

在2011年之间选择了哪些框架？以及如何在2016年选择新的

Dima，Finam：我专门为发布做准备：在爸爸中，我们正好有4,600个文件，而我们的代码不是供应商，也不是任何js。这个爸爸重16米。我们将在2011年12月做出第一个承诺，它的作者仍在工作，这是我们的团队负责人。

最初，正确选择了堆栈。甚至在2012年，它还是很现代的-第一个Zend还是很有意义的。然后我从事另一项工作，但我记得在春天末期的第12个地方，我们为新项目选择了堆栈。我们看了看：

Zend-第二个人刚刚问世，但还太年轻，他没有社区，

首先是Yii-但我们不喜欢ActiveRecord概念，

菲尔康

还有其他异国情调的东西

他们还选择了第一个Zend。那时，这是一个很好的相关选择。但是舌头向前。但是您要使用普通的名称空间，而不是通过下划线命名类。我想从开放源代码连接一些现成的库，当然，没有人在第一个Zend下编写。我想吸引员工加入团队-几次我们在寻找新人时，有一些是直接写在脸上：“我不会接受”。

最终，第一个Zend只是停止支持它。例如，在7.0，他们仍然发布了安全更新补丁，而我们自己对7.2和7.3进行了补丁。

在重新安置过程的开始我们花了一点时间。

没有全球性的风险-我们只是研究什么是现代的，相关的。与其他项目相比：我们不是公司中唯一的PHP团队。我们意识到Symfony对每个人都很满意-它看起来像一个可以使用多年的项目，拥有一个广泛的社区，许多现成的库，新的实用程序，等等。

我开始从事这项业务-起初，我只是在朝着Symfony的方向发展。当我到达时，我沉浸在项目的不同部分中，以便可以尽可能广泛地了解它-到大规模重构开始时，我就已经足够了解它了。我们开始后，另一个同志来了。我们让他沉浸在这个过程中-但尽量不吓他一跳。至少在一开始）

好。我们选择了一个框架。下一步是什么？

Skyeng Seryozha：有两种方法-您可以一次重写所有内容。您可以尝试缓慢地拖放。你从哪里开始？

Finam Dima：我们从霍利瓦尔开始，走哪条路。没有人有重写这样一卷的经验。例如，从我之前的工作中，我有重写小型自治服务的经验-我们在那里冻结了一个月的开发，重写了所有内容，然后继续。在这里，我们还不够一年。也许我们本来可以一年赚80％，但是，您知道...

有一个原则：前80％的工作需要80％的时间。其余20％的工作将花费另外80％的时间。

停止应用程序及其当前任务是不可能的。对于这种情况，恰好有两个概念：您正在使用当前应用程序执行某些操作，或者正在部署一个新的应用程序。我们取消了部署新代码的选项-因为有很多代码。结果，我们没有将Symfony应用程序部署在我们的旧应用程序旁边，而是在其之上。

但是为什么呢。我们的数据库中有250多个表，如果除去某些服务板，则这些表大约有200个实体。它们之间的连接非常牢固，由于连接数量众多，很难将代码分解成一些自治的逻辑部分。不要中断它，无论如何，连接将不复存在：例如，呼叫和电话与经理和客户相连。因此，我们意识到：如果部署新应用程序，开始为其编写新功能，然后慢慢转移旧功能，则将导致双重工作。毕竟，我们将要转移到新应用程序的代码不能完全从旧代码中删掉。我们将不得不在两个地方支持他。

然后，我们想起了我们团队已经拥有的另一种经验。

这是重写层以访问数据的经验。因为从前，Mongo与第一个Zend一起被选为主要数据库。但是实践表明，这种选择不是很正确。

Skyeng，Seryozha，Seryozha：是的，您具有所有的关系连接，但是您选择了一个面向文档的数据库。

Dima，Finam：是的，当我到达时，这些家伙正处于从Mongo复制到PostgreSQL的过程中……我们想到了我们拥有数据访问层的想法。而且，由于我们已经知道如何重写层以进行数据访问，因此也许我们可以将其改宽一点，然后立即抓住ORM层。

如果您将应用程序想象成一个馅饼，那么它将分为5层：ORM，数据访问，业务逻辑，控制器，视图。我们可以触及2.5层-完全更改ORM和对数据的访问，以及部分更改-业务逻辑。不是算法本身，而是与这些算法一起使用的那些类和对象。我清楚地知道可以单独消化该理论，好吧，我做到了。

因此，我进入了我们的引导程序，在那里初始化了学说，规定了所有必要的设置-并给了伙计们一个代码审查，写着：“嗯，应该有人开始了。”

路径的开始可能看起来像这样。然后，我们应用了将猛parts象部分吃掉的原理。有时候，结果比我们想象的要多，但是为期两周的冲刺的基本任务是迈出第一步-我们确保在同一区域中没有特色任务。

我发现了错误，回滚了，推出了

Seryozha，Skyeng：尽管如此，重构还是至关重要的，您如何确保自己？

Finam Dima：我们有许多单元测试-它们涵盖了关键点。我们的测试仪可以自动执行许多功能测试。CRM的主要工作是处理数据。而且，要在没有数据的情况下进行测试，就不一定总是可以通过单元测试进行：发送包更容易，检查包是否正常处理，是否已创建带有必要参数的实体。

自然，我们动了很多手：特别是一些关键和重要的事情，例如相同的客户和电话。

我很清楚我是如何完成这项任务的。我打电话给我们的呼叫中心负责人，我们同意，当他们的工作量耗尽而只剩下服务员时，我会尽力而为，服务员会检查所有真实电话。我竭尽所能，看着日志，发现了一大堆错误，滚开了，统治了它们，警告了服务员，将其推出了，再次捕获了下一个捆绑，然后回滚了……如此反复。

Skyeng Seryozha：一路走来，但现在可能已经超过一半，您对此有何建议？

迪南（Finam）：我可能会建议早些时候在我们的应用程序之上部署相同的Symfony应用程序。为了确保我们编写的内容，所做的工作确实有效。我记得我们是如何部署它的，首先从控制台启动它，然后从控制器启动它，敲响了我们的业务逻辑层-并确保应用程序可以看到它，可以访问所有服务，提取所有方法，卸载结果。

我刚刚意识到，我们确实正确地编写了所有内容，因此激励人的力量是如此强大。要检查您是否朝着正确的方向前进，以确保您正确执行所有操作，应尽早完成。

不是第一步，而是当您已经写好东西时，就这样做，提前一年拍摄，组织这样的本地时间机器，确保您做的一切正确，这会给您带来力量。您将走得更远。

ps

感谢您的阅读和聆听。在这里可以找到更多的PHP播客。

如果您希望获得更多有趣的报告和对话，请“参加” 5月30日举行的第三次虚拟PHP会议。

该死的老客户关系管理