复杂点无回报。你怎么称呼

作为软件开发人员，我的主要任务之一是控制复杂性。

但是，在某些项目中，有时候复杂度级别变得如此之高，以至于达到某种“无回报”的地步。超过这一刻，您将永远不会比需要从头重写所有内容的时间更短地将项目恢复到可接受的复杂度。

这个时刻在程序员方言中是否有名字（类似于戈德温巨魔定律）？

- 编辑 -

对不起，如果我不清楚。我认为这个“时刻”没有正式名称，或者不是一个严肃的指标。我正在考虑xkcd中“鲍尔默峰”的精神。

与其说是复杂性，不如说是可维护性问题。

这种现象被称为“技术债务”，一旦达到临界水平，该项目便即将破产。

这是你的意思吗？

“过度复杂点”在英语中称为：

哦，我的上帝，这是什么？

麻烦的是，这可能适用于实际上很简单的事物，但是以一种可怕的方式实现，使您有相同的反应。

因此，很难将非常复杂的东西与非常可怕的东西区分开。

但是：所有软件实际上倾向于发生的过程是这样的：

第1步：制定良好的规格，进行良好的设计，实施出色的东西。大家开心。

在第1步结束时，开发人员祝贺自己的设计具有出色的优雅性，并愉快地思考：“我在这里拥有美好的遗产，供他人日后添加，这将是美好的，世界将是一个美好的世界。更好的地方。”

第2步：进行一些更改，添加一些东西，包括新功能。步骤1中的体系结构使此过程相当轻松。[但是，糟糕的是，“关键因素”有所增加。]

在第2步结束时，开发人员祝贺自己的设计具有出色的优雅性，然后走开了开心的想法：“亲爱的，我很聪明，在第1步中做了所有这些津贴。这很好。我拥有美好的遗产在这里供其他人将来添加东西，这将是美好的，世界将变得更加美好。”

步骤3：进行更多的更改，添加更多的内容，添加更多的新功能，更改很多内容，实际上是在听用户反馈。

在第3步结束时，开发人员祝贺自己的设计具有出色的优雅性，并走了相当开心的想法：“该架构非常好，可以轻松进行如此多的更改。但是我有点不开心关于X，Y和Z，现在可以清理一点，但是!!!啊啊!!!我非常聪明，可以在步骤1中分配所有这些津贴。其他人将来会添加东西，这将是美好的，世界将变得更加美好。”

步骤4：与步骤3相同。

在第4步结束时：开发人员认为：“这些东西太好了，很难维护。它确实需要进行一些认真的更改。我真的不喜欢这样做。它需要重构。我想知道老板是做什么的会说，当我告诉他，这需要6周的时间，在此结束时，用户什么都看不到...但是通过这样做，我将再有5年的可口未来改装范围.... hmmm ..是时候去酒吧喝啤酒了。”

步骤5：需要进行大量更改。

在第5步中，开发人员互相说：“这段代码很烂。谁写的？他们应该被枪杀。它太可怕了。我们必须重新编写它。”

步骤5是致命的。在这里，关键因素变得非常糟糕，以至于代码不能再进行更多更改，而需要进行一些大更改。

步骤5的麻烦是希望将其丢弃并重新开始。这是致命的原因是“网景因素”。去谷歌它。公司此时处于DIE状态，因为重新开始意味着您从大约50％的假设而不是事实，150％的热情而不是知识，200％的傲慢而不是谦卑开始（“这些家伙是如此笨拙！”）。并且您引入了一堆新的错误。

最好的办法是重构。一次更改一点。如果架构有点累，请修复它。添加，扩展，改进。逐渐。在此过程的每个步骤中，都要进行测试，测试和更多测试。像这样的增量更改意味着10年后，当前和原始代码就像祖父斧头（“它有10个新的头部和3个新的手柄，但仍然是祖父的斧头”）。换句话说，没有太多共同之处。但是，您是逐步而谨慎地从旧变到新的。这样可以降低风险，并且对于客户来说，可以减少烦恼因素。

我同意，这一刻很难识别，可以通过适当的流程来避免。但是，问题在于如何称呼它。在实际经济学中，有一个“收益递减”的概念：在这一过程中，增加一种资源的投入会降低单位的整体利润。这当然适用于编码，甚至诸如抽象，重用之类的好东西也具有减少收益的观点。特定于编程的通用术语是“过度设计”。对于喜欢这样做的人，我喜欢乔尔（Joel）的术语“ 建筑宇航员 ”。

好的代码经常被误认为是带有新工具的新团队可以更便宜，更快，更可靠地完成它，只是发现

• 复杂性在于非文档要求
• 新工具比Flash网站承诺的更难使用
• 新团队并不像他们以前认为的那样“热”。

可能您所描述的时间确实到达了一些代码库（我曾经这样认为）。我从来没有亲身经历过旧代码导致项目瘫痪或重写代码以保存项目的案例。

在这种情况下，我不包括使用度量来识别特定的有问题的模块或设计，然后将其剔除并更换的情况。

这种理论上的“时刻”的真正问题在于，只有在事实发生之后才被人们认识。除非您的同事是精神病患者，否则对代码库的每次提交都必须相信这是对代码库的改进。只是回头看看随之而来的混乱，您可以看到您已经过去了这一“时刻”。

但我喜欢我们可以给它起个名字。您可以说：“绅士”，吸引了您的其他开发人员，“我们越过了可维护性Hellespont。给您的妻子发短信，让她知道您暂时不会再见到她了。”

我不知道是否有名字，但如果没有名字，我建议称它为“熔解点”

这不是一个非常有趣的问题。

确实，这是微不足道的。

它是如此琐碎，以至于我们已经开发出许多应对方法。

1. 瀑布方法。许多人花费大量时间来审查需求和设计文档，以确保管理复杂性。

2. 敏捷方法。更少的人花更少的时间讨论可以立即解决什么人的问题并向他们发布软件的问题。管理复杂性是因为每个人都专注于发布某些东西。

任何人唯一一次为“复杂性”而挣扎是因为未能遵循该方法并正确地管理自己的时间。

• 在瀑布方法中没有详细的监督。他们没有被迫在需求，体系结构，高级设计或详细设计审查中审查中间工作产品。

• 在敏捷方法中，没有冲刺截止日期或适当的用例优先级。他们并不专注于尽快将某些内容发布给用户。

应该通过设定目标来限制复杂性。

进行复杂的搏斗意味着目标设定不正确或未得到适当奖励。

没有“转折点”。如果复杂性管理某种程度上是一个问题，那么组织上已经有些问题了。

对于（大型）项目和代码，存在可视化和监视复杂性增加风险的方法。当合理地希望使用它们时，就不需要为不返回点指定一个新名称。（openHPI上有一个相关的MOOC：https ://open.hpi.de/courses/softwareanalytics2015/ ）

结构复杂性是一个普遍的设计问题-不仅是大型团队的软件设计。可视化是结构复杂性管理的第一步。矩阵和有向图也可以用于此目的。

降低结构复杂性的一些方法是http://www.buch.de/shop/home/suche/?fq=3540878890：

• 模块化
• 避免反馈循环
• 三角剖分

此外，还有公理化设计的概念：https：\ en.wikipedia.org \ wiki \ Axiomatic_design \通过这种概念，可以避免由于不必要的复杂性而引起的可靠性问题。

因此，有很多方法可用。最后，因为一个项目足够大，决定考虑它们总是决定性的。