一旦您开始担心技术，很快就会出现担心的新原因。
恐惧循环像这样收紧：
- 较小的编辑会导致不可预测的，令人恐惧的或代价高昂的后果。
- 我们开始担心变化。
- 我们尝试使所有编辑尽可能地小和本地化。
- 代码库中充满了补丁，异常和特殊情况。
- 恐惧加剧。
当无害编辑意外地引起问题时，恐惧就开始了。 生产中的停机时间或只是一个令人讨厌的错误。 错误会引起管理人员的注意。 没有什么比像董事会议那样引起对
您的代码缺陷的恐惧了！
之所以这么麻烦，是因为开发人员无法预测变更的所有后果。 测试套件可能不足。 或者出现了仅在生产中观察到的特殊情况。 （例如，一个客户端的数据设置与其他客户端不同）。 无论是什么具体原因，结果都是：“我不知道会发生这种情况。”
几次类似的活动-现在开发人员和项目经理不希望触及其狭窄范围之外的任何事物。 他们像鸵鸟一样将头藏在沙子里。
问题在于这种行为将产生后果。 不可避免的是，代码库将开始恶化，对主要更改的需求将增加，并且在不发布的情况下进行重构的数量将增加。
当这些鸵鸟之一成为其他人的虫子的罪魁祸首时，恶性循环就结束了。 从这一刻起，恐惧的循环变得自我维持。 即使是很小的变化，其代价也将不断增长。 发布更改所需的时间也在增加。
引爆点
这可以通过三种方式结束：
- 座右铭“现在我们会做对的 ！”的基码重构（通常是在其他团队中进行） 另请参阅： 第二系统的综合症和“永远无法完成的工作，第一部分” 。
- 大规模外包。
- 将受影响的资产出售给另一家公司。
如何避免循环
当人们将技术问题视为个人问题时，恐惧的循环就开始了。 第一次，简单的代码更改导致重大且不可预测的后果时，您需要致电“技术特种部队” —一个专家团队。 他们将确定系统为何允许这样做以及将来进行哪些技术更改将有助于避免这种情况。
法庭是对失败的最坏反应。
“技术特种部队”与法庭之间的区别在于，特定人员如何处理此问题。 为了避免恐惧循环，需要明智的指导。 寻找具有DevOps和技术项目管理经验的人员。
如何打破循环
像许多强化循环一样，恐惧循环很难打破。 到目前为止，我还没有观察到成功退出这一案例的情况。 如果您的公司成立了，我很想听听您的经验！