软件为什么会沦为遗留系统？
软件变成遗留系统是一个常见的问题，本文就来看看遗留系统形成的十大原因。
作者 | Martin F. Johansen
译者 | 弯月，责编 | 郭芮
出品 | CSDN（ID：CSDNnews）
以下为译文：
通常，开发人员不希望在遗留系统上工作，因为这些系统都很复杂，使用落伍的技术，而且还有很多维护任务。遗留系统还会阻碍公司的发展，因为在引入客户和市场所需的新功能时，遗留系统势必会拖后腿。
遗留系统在刚出现时当然并不是遗留下来的。最初可能也是采用最新最先进的技术构建的，开发人员热切而又快速地开发了这个系统。然而，时至今日这个系统就变成了没有希望、过时、晦涩难懂和无法维护的系统。
那么这中间究竟发生了什么？在本文中，让我们来看看软件成为遗留系统的十大原因。
开发人员的工作目的是为了积累经验而非构建软件
IT行业的发展十分迅速，各个公司都要求开发人员拥有最新技术的经验。许多开发人员都明白这一点，所以他们希望积累新技术的经验，为自己的简历加分，为下一份工作铺路。
通常，项目负责人都意识不到这一点，开发人员三言两语说这很有必要，项目负责人就接受了，甚至还会推波助澜，即便这种技术有点绕远，会延误项目，甚至降低质量。如果他们知道后果，那么断然不会接受。
许多开发人员都认为他们在当前公司或项目中的工作只是暂时的。因此，他们在选择技术时关心的并不是长期的后果，而是自己下一步的职业生涯。
为了抵制这种影响，首先需要承认这种现象确实存在，其次领导者必须明确关注公司的长期目标。领导者必须谨慎地做出技术选择并坚持下去。同时在改变技术选择时，必须谨慎评估，将公司的利益放在第一位。
学习新事物很有趣
学习很有趣，但学习本身赚不到钱，而且赚钱也不好玩。还有什么比在工作中一边学习一边赚钱更好的呢？大多数开发人员都非常喜欢在工作中学习。然而，这对于企业来说是一个问题，因为学习最新的技术通常会使公司受益，但正如我们在本文中列出的许多其他原因那样，拥抱新技术是导致软件成为遗留系统的另一个原因。
引入新技术通常会导致软件成为遗留系统，因为不同的方法会导致系统演变成东拼西凑的混合体，这会增加不必要的复杂性。此外，随着不断加入新的技术，旧技术就会过时。过时的代码量逐渐增加，而软件最终会变成遗留系统。
这是一个双重打击：开发人员的目的是学习新技术而不是工作，产出的软件也变成了遗留系统，而不是长期稳定可靠的软件。
有时，软件开发包括长期的工程作业，其中业务流程是自动化的。与学习和尝试新技术相比，通常这些工作被视为机械无聊的工作。
软件开发与其他建筑工作没有什么不同。通常，解决问题的方法都是众所周知的，解决问题时使用的工具和技术也是众所周知的。换句话说，开发人员需要接受这样一个事实：有时候在工作中你只需要构建软件，而学习新技术的机会非常小。原因很简单，因为公司的目标从来都不是让开发人员学习新技术。
当然，有时学习新技术也很有用。但这应该由公司领导层做出决定，认真学习符合公司利益的新技术。在这种情况下，很明确学习是公司战略的一部分，当然学习就不再是问题了。
在引入新技术时，领导层应认真考虑重构旧代码，让整个代码库与最新的技术保持同步。只有这样才能控制好软件的复杂性。
时尚
你可能会觉得很惊讶，IT界也有时尚？当然，我们这里说的可不是服饰时尚，但很类似。当今的社会不需要再担心衣不蔽体的问题，因此服装设计师发明了新的设计和颜色组合，生产出各种时尚的服装。差异化和一致性推动着时尚的发展：你不想和爷爷辈的人身着相同的衣服，但你却想和最喜欢的明星、创业家或音乐家穿相同款式的衣服。
软件界也可以看到相同的情况。
如今，构建软件已不再是一个问题，因此开发人员希望自己的产品从那些平庸的软件中脱颖而出，做到炫酷炸裂。于是，一系列不同的软件开发方式就这样诞生了，其实这背后并没有任何实际的专业理由。
今日时尚，明日老套
今天新颖闪亮的技术，到明天就会变得陈旧乏味。IT行业是出了名的发展迅速，只要开发人员学习了新技术，他们就会在下一个项目中拒绝使用原来的技术。一些软件系统就是旧时尚的博物馆，来也匆匆去也匆匆。这是遗留软件的特征之一。
因此，认识到一种时尚是很重要的，在接受技术之前应该仔细考量。
喜新厌旧
俗话说得好，情人眼里出西施。在你眼中新技术充满了优点，而回头再看旧技术就会看到各种问题。要看到新技术的问题并不容易，然而经过多年的使用后，缺点就会显现出来，因此对于新技术而言这些缺点并不明显。
因此，在比较技术时，考虑技术的方方面面非常重要。虽然这很困难，但技术方面的强有力决策可以保护软件免于沦落为遗留系统。
不必要的依赖和过于紧密的耦合
重用软件很重要，在软件生命周期中，能够重复使用的部分会越来越多。因此，会产生一个不断扩展的依赖项列表，通常这些依赖项都是包管理器（如maven或npm）引入的，或者是过于依赖Web服务的依赖项。
如果选择依赖时太随意，那么这些软件变成遗留系统的风险就会越来越大，这反过来又会导致依赖于该软件的其他部分变成遗留系统。我们应该尽力避免不必要的依赖项。
相关问题是与依赖关系的紧密耦合。紧耦合意味着有很多代码与依赖项交互，而且这种交互充满了依赖项的细节。这种厚实而紧密的集成基本上意味着，软件的命运与依赖项的命运息息相关。这种情况很常见，有时不可避免。但架构师应该仔细考虑是否真的需要紧耦合，如果没有必要性，那么就应该避免紧耦合，这样可以在依赖项变成遗留系统时，保护软件免于步后尘。
不必要的复杂架构
软件架构是软件开发中最高级别的结构。创建架构时所做的决定会产生长期影响，典型的例子是使用多种编程语言编程。现代Web应用程序可能需要合理地使用两种或三种不同的编程语言，但使用六种或更多种编程语言很可能会造成架构不必要的复杂性。
如果架构过于复杂，那么新来的开发人员就很难上手，这会导致代码质量随着时间的推移而不断恶化。
根本原因还是系统过于难以理解，而且修改代码时可能没有考虑到体系结构的相关细节。拥有一个尽可能简洁的架构可以减少这样的问题。
编程语言中不必要的部分
开发者社区非常关注代码的惯用写法，惯用写法会大力使用某种语言独有的属性，原因是人们相信惯用写法的代码更快，更不容易出错。
殊不知，惯用写法也有一些未知的弊端。首先，这些代码完全依赖于特定的编程语言。当这种编程语言被淘汰时，这些代码就变成了遗留问题。此外，如果代码中包含的惯用写法较少，而是采用了所有编程语言中更常见的结构，则更容易转换成其他编程语言。
另一个问题是复杂性。大多数现代编程语言都非常复杂，如果你没有在当前项目中遇到过这种情况，那么可以看看在线的编程语言益智游戏或测验。大多数拥有10年以上经验的牛人都掌握了大量编程语言的细节。他们的专业知识能够针对某些问题提出非常紧凑的解决方案。如果某个技术不够娴熟的人遇到这样的代码，那么他们将不得不花费几个小时搜索谷歌和与同事讨论，才能真正了解代码的实质内容。而这些成本往往都会被忽略，但这确实是解决方案成本的一部分。虽然一个更为简单的解决方案可能需要更多的代码和时间，但将来不会产生这类的成本。
毋庸置疑，修改过于花哨的代码很容易出错。而为奇特的解决方案编写代码亦是如此。
有些公司通过编程指南、静态分析和代码审查来降低他们使用的编程语言的复杂性。这些方式只不过是通过禁用语言中的一些结构来降低编程语言的复杂性。然而，随着时间的推移，这些指南都有可能改变和被人遗弃。
不限制开发人员
通常，软件系统都拥有精心选择的架构。新来的开发人员或技术水平比较低的开发人员可能不了解架构的决策。因此，开发人员可能会生成违反体系结构的代码，从而创建更复杂的体系结构。这种架构的变迁会隐含在代码中，因此其他开发人员并不知道。这会无形中增加复杂性。
换句话说，不限制开发人员通常都会增加系统的复杂性。
限制开发人员的方式有很多种。例如，根据开发人员的能力范围进行分类。然后，将开发人员划分到正确的分类。某些类别的修改应仅限于架构师。例如，选择引入新的编程语言。
这些限制应该通过静态分析辅助的代码审查来强制执行，这是控制复杂性的一种方法。
没有模块化的软件以及没有范围限制的模块
模块化软件的意思是说，将软件划分成小块，每一块的范围和大小都有限，而且责任明确。一直以来这种方式都很受欢迎，大多数人都赞同这种做法。
然而，随着时间的推移，模块会发展得过于庞大。其中一个原因是模块不受限制。例如，如果某个模块被限制为只包含无状态函数，那么它肯定不会超出该范围。还有比如，限制模块抽象与支付系统的交互。我们可以通过代码审查确保这类限制。
总结
在本文中，我们的主要观点是：软件应该拥有一位架构师和技术主管，长期负责保护该软件。这位架构师应该在选择技术与处理技术变更时，做出谨慎而明智的决策。这位架构师应该确保软件的模块化，还要确保每个模块只包含结构和编程语言必要的依赖性和复杂程度。从事这些模块开发的工作人员应该了解模块的范围并遵循范围要求。而这位技术主管可以主要通过代码审查以及静态分析来强制执行这些要求。
原文：https://www.progsbase.com/blog/top-10-reasons-your-software-became-legacy/
本文为 CSDN 翻译，转载请注明来源出处。
热 文 推 荐
☞2019年技术盘点容器篇（二）：听腾讯云讲讲踏入成熟期的容器技术 | 程序员硬核评测