纽约-爆炸使摩天大楼震颤，一条已有83年历史的蒸汽管发出了强有力的信息，即纽约和美国其他城市下方的管道，电线和铁条的英里数正在老化，并且可能变得危险地不稳定。
我们已经收到以下消息：
因此，软件工程界当然可以意识到这些问题。
但是，我觉得我们整个社会都不喜欢这些问题如何困扰工作系统和应用程序。
正如史蒂夫·麦康奈尔（ Steve McConnell）所说：
...与金融债务不同，技术债务不那么明显，因此人们可以轻松地忽略它。
如果这是真的，我相信是这样，那么我担心政府和企业可能会推迟对黑客的定期维护和防御，直到为时已晚。[很像纽约市和蒸汽管。]
我的问题：
Answers:
与遗留系统维护相关的一个关键问题是缺少以下人员：a）急于应对这些系统，并且b）愿意继续维护它们。
我最近以类似的方式问了一个问题，即年轻的程序员是否对大型机感兴趣。共识倾向于否定。
维护遗留系统被视为职业自杀。在许多惯性支配的公司中，很少需要培训员工以保持在这些系统之上，从而导致人员方面的单点故障。我认识的许多在类似系统上工作的人都在寻找出路，因为他们认为该系统没有长远的未来，而只会损害职业。
在某些行业中，数据维护法规可能是确保合理监控旧系统的关键因素。我认为这在金融行业尤其是个问题。据我所知，这些规定通常是有时间限制的。
但是，我认为在实践中会发生以下情况：
在图表上会出现一个点，即过渡到一个更现代的系统的成本（使您能够绕过传统系统的缺点）将降至维护传统系统的成本以下，因为它更便宜。
IBM目前正在出售许多大型机，并且他们正在努力工作以确保大型机不会将大量年轻专业人员拒之门外。但是我认为在这个阶段还不够。他们在碳足迹和实际处理能力方面有一些USP。
但是，对于每一个因为可以在其上运行Linux而购买IBM大型机的人来说，它的用电成本更低，效率更高，因此您将有更多的人选择服务器场，因为他们更熟悉该领域还有更多的程序员。
最终，很大程度上取决于所涉及的行业。我在一个特定的行业工作，该行业多年来一直非常依赖大型机，并且仍在广泛使用。但是托管的解决方案变得越来越流行，可以整合大型公司的技能-消除了个别公司在故障点方面面临的一些问题-此外，一些供应商非常关注基于非大型机的解决方案针对该行业固有的问题。
因此，总而言之，我想我想说的是，总体而言，一旦维护与迁移的经济点支持迁移，那么就会朝着从旧系统迁移的方向发展。但是，对于大多数人来说，它几乎是不可见的，因为它不是新奇的，时髦的，而且不像下一件大事那样具有很公开的面孔。该迁移可能是向服务提供商或较新技术的迁移（尤其是在服务提供商受到直接影响的地方）。
我的经验-尤其是在网络方面-是采取了消除对遗留系统的依赖的措施。
大多数企业都已经无知的技术债务，甚至不知道的东西是不好的，直到它从字面上崩溃他们周围，并将它们发送到破产（如果它曾经到达这一点）。我真的看过那件事发生了，那不是很漂亮；更糟糕的是，我反复试图使企业主意识到不断增加的技术债务，并且必须将其修复，并且由于不愿花费所需的时间和资源来修复，因此每次都被拒绝。它。最终结果是10多年后，系统终于发生了灾难性的故障（我离开后），他们无法恢复，并倒闭了，因为在那十年中他们太愚蠢以至于无法意识到花一点钱来解决该问题总比完全忽略它更好。我可以抱怨那个公司荒谬的愚蠢长达数小时，而令我最大的困扰的是，如果没有所有者，那本来可以完全避免的 只是通过完全削减所有其他东西来快速赚钱。
试图告诉企业，其系统是否写得不好并且需要进行大量的重构（如果不是完全重写的话，这通常是很糟糕的事情，这通常是很难做到的），这非常困难。大多数时候，他们就会拍你失望，即使你警告他们，很难做出改变，或增加新的功能（以正确的方式，我的意思是，不只是层次感更强废话到桩），甚至可以考虑你一个因为您会看到系统当前状态下的问题，因此对业务不利。
老实说，我得出的结论是这是一场失败的战斗，那是不值得战斗的。足够聪明的人知道技术债务，不需要一再被告知，并且从一开始就意识到危险，其他人也不会听任何理由或警告，直到总为时已晚。最好的选择（当然，也是最不现实的）是让自然选择开始，让无知的人灭绝，只剩下聪明的人。我不知道再有什么脚踏实地的处理方式，因为我过去亲自尝试过的一切都被完全忽略了，降低了我在公司眼中（“抱怨”）的价值，甚至导致我被解雇，因为我“太专注”于解决“什么是” 坏了，没有人有适当的心态看它坏了。
纽约和其他美国城市下方的管道，电线和铁杆的英里数正在老化，并且可能变得危险地不稳定。
对于轶事，16-17世纪的巴黎也有同样的说法。在其下方挖出了如此多的洞和隧道（由于该地区的地质原因，加上了天然的洞），偶尔的建筑物会倒塌。
到整个城市街区塌陷时，已经发出指令，用砾石和骨头填充不必要的洞和隧道（它们也有人满为患的墓地问题）。这座城市幸存下来，直到发明了混凝土。
我的意思是，许多组织倾向于等待最后一分钟来进行任何软件维护，但是很多编码人员（例如土木工程师）都能快速，良好地完成工作。
我们幸免于Y2k错误。Y2036错误将迫使许多组织升级其硬件和软件。世界可能会在2012年终结。但是计算机科学家既不是社会学家也不是文学批评家。
哦，与此同时，俗话说得好：编写代码，就好像下一个维护者是一个恶毒的精神病患者，知道您的住所。
我忘记了，这些天我们怎么看待遗留代码？去年的代码，过去的十年的代码或上个世纪的代码？
金钱推动了围绕旧系统维护的对话。技术债务的形式是更改系统的成本增加。
我曾经使用过设计不佳和智能设计的系统。有趣的是，维护它们的成本相差不大。最大的问题是当前使用的体系结构不正确，通常会在扩展问题或需要进行重大更改时出现。您不容易将主要代码区域从单线程转换为多线程。
我遇到的最重要的问题是所使用的开发语言。较旧的系统是用当今不太流行的语言编写的，因此您必须训练更多或雇用更多经验丰富的（昂贵的）稀有资源。在这两种情况下，由于池较小，因此您也很难找到熟练的人，而这些人往往会带来与解决方案一样多的问题。
至于承诺的重写，大多数投入巨资的系统都无法证明重写的合理性。令人惊奇的是，软件可以保持运行和增强的时间。硬件更改（我公司支持的某些系统使用专用硬件）往往是我们面临的最大问题。增强功能通常仅受将旧代码与新功能集成的机制限制。
这已经是一个大问题。而且它没有变化的迹象。
在20世纪60年代和70年代，各种大型机构都从纸上账目转变为计算系统账目。他们以压倒性多数选择了COBOL。 大多数仍在使用那些COBOL系统的更新版本。有关此方面的一些统计信息，请参见http://cis.hfcc.edu/faq/cobol
我们常常每时每刻都会对此产生随机的提醒，例如当阿诺德·施瓦辛格（Arnold Schwarzenegger）几年前发现，如果没有六个月的发展，他就不能简单地削减20万名公务员的薪水（请参阅http：//www.infoworld。 com / d / developer-world / californias-cobol-conundrum-067进行验证）。
考虑到切换的风险，很难证明更改这些系统的合理性。曾经 这是我一生的现实。但是我认为没有任何理由可以改变我孩子的一生。或者他们的孩子的一生。
我有一些朋友维护的代码早于他们。我有一个朋友，在她第一次在公司工作30年后回到一家公司，发现她的程序仍以她什至不记得的语言运行，并且没有任何变化！
最后，让我以真实的故事结束这一切。
1970年代，一家公司成立是为了为交易者提供在线市场。PDP-11非常适合他们的性价比，因此他们选择了PDP-11。他们不断突破机器的性能极限，因此他们以高度优化的PDP-11组件编写了系统。几年后，PDP-11停止销售。但是生意很好，机器很耐用，二手替换很容易实现。他们保留了平台。在那之后的几年，替换变得越来越难了。做出了一个重大项目来替换交易平台。失败了 他们再次尝试。并再次失败。失败的主要原因是没人知道他们的交易系统是如何工作的，也没有人可以再阅读PDP-11的组装。然后得救了。有人创建了在Linux上运行的PDP-11汇编程序。
因此，正是在2000年，年交易额达到10亿美元的交易转到Linux机器上，通过以太网-decnet网桥模拟了PDP-11机器，该机器在以高度优化的PDP- 11装配。为了速度。
在过去十年中，我与上述公司没有任何关系。因此，我无法告诉您它们是否仍在仿真的PDP-11上运行。我知道十进制会极大地挤压他们的利润，因此他们还需要进行另一项迁移。（我之所以了解这个故事，是因为我采访了几个被解雇的人，然后问发生了什么事。）但是考虑到以前的失败，我会给他们提供一个比他们没有成功替换这个系统更好的机会。
从用户的角度来看，这听起来像是一个非常真实的担忧。为了避免或更好地避免出现这种情况，需要使该软件摆脱束缚。它的发布者应该免费设置源代码，或者从事维护和升级源代码的工作，直到最后一个用户停止使用它为止。否则，由于商业环境中的类似问题，他们很有可能会破产，从而使软件完全可以应对。
也就是说，软件著作权和限制性许可的期限应非常短，最后，软件及其代码库进入公共领域并停留在公共领域。因此，使得用户可以继续升级源，或者雇用某人来进行升级，从而延迟和/或避免了故障。
或者，如果您对自由软件的想法持开放态度，则可以使用诸如AGPL或GPL的自由许可证或其他自由软件许可证来编写程序。从我所看到的，当软件的源出于某种原因不再吸引开发人员的兴趣来改进它时，源库就会被蚕食并重新焕发生命。据我所知，Debian操作系统中的软件包倾向于遵循这个生命周期。
在支持各种政府和私营行业应用程序之后，我要说的是，大多数公司，至少是美国政府，都充分意识到使代码腐烂而不能紧贴最新安全趋势的危险。
我们通常必须使我们的软件具有各种敏感性的认证，而且大多数政府电子系统，即使是旧的电子系统，也需要定期更新以确保其安全性。
当然也有例外，黑客总是在移动，但总的来说，我认为人们很清楚，您不能只是丢东西而永远不会再碰它。
警告：这将是一些自由格式...
我认为有两种方法可以解决您的问题。
如果您考虑一下，一些航天飞机和卫星一直在运行最初发射它们的相同代码。另一方面，即使它们是（非常）远程的，也有一些被设计为可以更新的。
重要的是环境。显然，只要不修改环境，您的代码就不会过时。在这种情况下，代码腐烂实际上并不存在：代码本身（或生成的二进制文件）无法腐烂。如果您只是从完全不同的角度开始攻击它，则它可能会崩溃。不是说它腐烂了，而是因为它不适应环境。将其视为一个进化问题。
但是我们的环境在变化。无论如何，解决问题的关键是什么。我们的环境变化如此之快，以至于如今我们不会指望软件解决方案会随着时间的推移而发展。我们忽略了过去一年未更新的软件项目，并且会抱怨没有明确路线图的产品和客户支持。即使效果很好-您可以获得清晰的路线图，良好的支持，定期的更新...-挑战者将以指数级的增长浮出水面。我们经常会犯这样一个错误，即认为大型的老牌公司将始终占据主导地位，正是因为它们占据主导地位。但是，与畜群中占主导地位的元素变老的方式一样，超大规模软件/硬件/任何厂商的变老。还是有点懒。挑战者进入并扭转局面的速度甚至比5或10年以前确定的主导者更快。否则，当我们看到市场出现混乱（从经济上来讲，对不同领域产生影响）时，主导者将遭受良好的打击，勉强生存下来。也许这看起来并不完美，但这本身就是一个有机过程。
因此，从用户的角度来看，我认为问题并不大。从用户的角度来看，代码腐烂不会发生，因为他将使用替代方法（可能会进行无缝过渡/迁移……希望如此）。
现在假设我们没有从用户的角度看待事物，或者我们正在谈论的是一种不受竞争影响的系统-出于未知原因，政府发展，零星旅行等等...为了能够长期生存/生存，我们需要查看您参考的文字。也许还有更多关于可靠系统和容错系统的文献。虽然我们可能想进一步推进。我们不仅需要容错，还需要进化系统。
演化的问题在于，它引入了变化，而变化则引入了故障点。让我们现在看看这些，以及我们可以做些什么来解决它们。
在此过程中，我们仍然可以依靠基础结构/体系结构/工程的隐喻（毕竟，我们全都是软件工程师，尽管现在可以说没有像软件工程这样的东西）。有一个原因是管系统仍处于活动状态（有一些故障），而大笨钟仍在工作（有一些故障）或艾菲尔铁塔仍在站立。这是因为我们对基础架构的重要（或不太重要）元素进行了处理，而对软件我们应该做的也是：持续检查。这些实体的设计不一定要持续这么长时间，但是它们得益于永久性的监督以及在需要时及时进行的改进和维修。如果愿意，可将其称为修补程序。
另一方面，有些设计本来可以持久地运行，并且可以不间断地运行，甚至知道不可能进行连续检查。在这种情况下，我们将转向良好的设计和正式模型。对于给定的环境，可以量化可靠性要素（可用性，可靠性，安全性，完整性，可维护性）。统计数据会做剩下的事情，以便为剩下的事情和未来做计划。这就带来了一个问题：我们甚至有可能构建真正意义上可进化的系统吗？
清洁规范（Clean Code）中的杰夫·兰格（Jeff Langer）提出了类似的问题... ...未提及蒸汽管：）
如果您可以遵循四个简单的规则，这些规则可以帮助您在工作时创建良好的设计，该怎么办？如果遵循这些规则，您对代码的结构和设计有了深刻的了解，从而使应用SRP和DIP等原理变得更加容易，该怎么办？如果这四个规则促进了好的设计的出现，该怎么办？
我们中的许多人认为，肯特·贝克（Kent Beck）的“简单设计”的四个规则对创建设计良好的软件有很大帮助。
根据Kent（《极限编程说明》中的内容），如果设计遵循以下规则，则它是“简单的”：
为了运行所有测试……我们需要运行测试，这是技术债务的巨大指标。例如，如果有10000测试用例像美科利质量中心的系统和没有这些测试是自动化的，那就是已经建立起来的技术债务的一个明确的指标。
这就是Feathers和他的书“有效地使用旧版代码”的地方。