我参与过的许多项目，大型项目都变成了遗留的，散落的胡须，结果，开发变得异常困难。有时，由于进行更改的地狱般的困难，项目刚刚终止。今天，我将向您介绍我在项目中的工作经验，以及为什么将这些内容全部写给您。当然，一切都非常主观。
因此，我像一名水手一样努力工作，并且想尝试浇水并防止船下沉，但是该项目的质量稳步下降，原因有很多。
您会很容易识别它们，它们是普通患者，我只是提醒您：
- 架构la脚，难以实施新的解决方案
- 编码错误
- 没有自动测试
结果，根据项目在最初的1-2年中的发展结果，获得了遗留的，肮脏的代码，纠结有秘密通道的纠结的隧道以及岩画ala的混合物，“这样的作品，为什么我不知道”。
我不会过多地讨论这个问题，这是重构中的第一大话题，直接得出我的结论。
开发的产品是集体的专业知识
如果团队中有1位真正投入的超级开发人员，并且工作良好，那么他将不会独自清理，因为团队不断犯错，并且总是会拖累项目。
当然，您可以尝试给当前的团队一个重构任务，然后那些进行焊接的人员将重做他们自己的工作结果，并给出相同的结果，也许比第一次更好。
因此，如果没有团队升级，您不应期望进行根本的质量升级。
这是一个恶性循环1-团队的专业知识还不够，但是重构开始了，并且注意，编写它的是同样的人。
或者，您可以安排一个好的领导者来进行审查并清理这些错误（尽管他会尽力而为），但最终，这将使工作不佳的人感到头疼，然后替换开发人员，或者他们自己离开，然后再次，您将获得开发人员的替代品。
这将是该项目的自然选择。
人们害怕更改密码
欢迎，这是针对程序员的心理学会议。
程序员真的很害怕更改代码，并且可以理解：
- 没有足够的测试
- 代码如何工作尚不清楚
- 日期在
- 没有资源
- 管理层不会理解（正常，但是如果管理层着火了，一切都会好起来的）
结果，将导致项目拖延的旧的令人困惑的遗留代码视为“最好不要碰”，结果这种“不要碰”将永远存在，甚至更糟的是，迫使您以某种方式编写代码，从而导致其他技术问题。然后他们也将项目拉低了。
我们接受一个项目，肮脏的代码，团队的恐惧，将其乘以时间，我们将获得巨大的技术债务，这种债务立于不败之地，并且不允许团队正常运转并快速开发项目。
该项目开始崩溃，截止日期被破坏，新功能对该项目而言变得更加昂贵，开发人员开始变得紧张，有些请假，很难找到新功能，您明白了...
所以，我认为这是问题1，担心代码和风险。
根据经验，如果您留下技术债务，则可能是炸弹或至少是耙子。将它们保留为100、1000，您将获得一个雷区，不仅在雷区上（开发项目），而且您将无法爬网。
因此，要节省项目开发的平均速度而又不降低质量，唯一的方法就是要有上限，要注意质量，重构。
议会大火，每个人都知道，但是实际上上面的清单没有任何地方，所以您不能只接受它并对其进行重构，因为您得到的项目正在崩溃，为什么？
由于没有测试，因此代码的工作方式尚不清楚，因此，结果发现Vasya和Petya没有改变汽车图纸和装配体，而是磨了一下机器，锯了Solaris，然后又放回了Tavria，但没有成功。为什么？-哦，但是因为我们不知道这种影响/行为/任务
是的，您可以在没有测试的情况下进行重构，然后稳定下来，但是许多用户脚本或必要的代码执行脚本可能会丢失，或者稳定化可能需要很长时间。
因此，又有一个恶性循环-您不能独自留下代码，但也不能像以前那样重构它，因为存在巨大的风险。
事实证明，我们不需要旧版，但是摆脱它既可怕又危险，因此团队经常将旧版作为“最危险的选择”，以便为以后的项目提供更危险的解决方案。
测试是关键
事实证明，为了解锁重构并使其安全，您首先需要通过测试覆盖所有情况，然后当我们切割Solaris并将其组装到Tavria时，焊接将停止并说：“您好，我们需要Solaris，您在这里搞砸了。”
通过测试，您可以避免在重构过程中出错，例如 使其安全，然后您可以根据需要削减项目，而不必担心风险会起作用并且会出现问题。
因此，我们得到了一条链：
测试->重构->再见胡须和遗留物
听起来很简单，漂亮，但实际上很少有测试。或根本没有发生，并且有很多原因，与往常一样：
- 开发人员认为测试是一个单独的主题，并且不投资评估；他们与开发分开编写。如果项目管理人员如此认为并希望削减测试以达到截止日期，则将更加困难。
- 测试是时间，项目现在需要移交，没有时间为我们编写测试（理论上，这与第1点相同）
- 项目/组件很简单，为什么要进行测试，一切都非常简单并且可以在其中工作？
- 首先，我们将编写代码，然后通过测试进行覆盖。但是不，我们没有得到，项目没有停滞，没有时间。因此，这项任务永远存在于黑匣子中。
实际上有上百万个原因，但是事实是它阻碍了重构，结果使质量无法提高。
因此，测试是一项关键任务，如果没有测试，则即使不是不可能，项目的长期高质量开发也会非常困难。
该怎么办，休斯顿？
我之所以写这篇文章，是因为并不是每个人都理解它，并且至少有人会读它，并希望编写测试，重构，这意味着我写这篇文章是有原因的。
因此，每个人都有自己的作业-编写一个写得不好的模块，组件，某些东西，在那儿找到您想重构的东西，为此模块或组件编写测试，然后重构。
结果，您将了解测试是：
- 一种学习代码的方法。它甚至比阅读它更有效。
- 稳定性
- 真正的旧代码可以重构，并且项目的质量可以提高
我非常主观地一口气写下了所有内容，也许我是错的，这只是我的经验。我可能不知道，也许我只是碰到过这样的项目，但是这些信息仍然有用，并且如果您在阅读后仍在思考，那也很好。
我希望每个人都能得到良好的代码，测试和提高质量-这就是为什么我们被录用了，让我们工作顺利。
PS如果您愿意，请在评论中写下您的重构经验，每个人都会感兴趣。