软件架构必须随着业务发展而演进，否则就会成为业务的阻碍。但架构本身在发展过程中很容易逐渐腐化，堆积大量技术债务，因此在软件发展过程中始终保持架构愿景非常重要。原文: Software architecture — Paying the Price for Neglecting it
在商业世界中，我们通常通过构建软件来解决业务需求。随着时间的推移，软件逐渐发展，在市场上取得了成功，拥有了强大的用户需求、积极并充满活力的开发氛围，取得了优秀的投资回报。事实告诉我们，软件系统是关键业务资产，为了维护资产价值，必须进行更改、更新和管理。
由于业务环境(市场)的动态性，软件系统需要不断发展以匹配系统及其用户不断变化的需求，以保持其竞争力和活力。
没有什么比保持不变的成功更失败的了。
随着软件的发展，规模和复杂性也在增加。最理想的情况是，体系架构会随之扩展以支持需求的变化。如果对变更缺乏适当的管理，体系架构就会恶化、难以维护，并产生架构债务。随着时间推移，堆积了大量技术债的软件系统会越来越难以维护和修改，从而导致系统过时、不可靠，无法跟上不断变化的业务需求或技术进步。
如果在不考虑变更影响的情况下改变体系架构，则软件架构将偏离其原始设计，导致架构漂移。因为所做的变更没有考虑对架构的影响，最终会导致对架构的侵蚀。架构侵蚀通常被定义为一种现象，在这种现象中，应用的初始体系架构被任意修改，以至于无法保持其关键属性。
打个比方，这就像建筑的原始地基是为了容纳一座两层楼而建的，但因为看起来还不错，所以继续在同一个地基上不断搭建更多楼层。
在一系列(n)个版本中，下一个版本(n+1)的体系架构是基于先前被侵蚀的体系架构设计的，从而对下一版本架构的有效性产生质疑。如果无法被纠正，情况只会越来越糟。
软件老化的症状包括性能下降、错误或崩溃增加以及用户体验下降。由于增加了复杂性，可能需要更长时间引入新需求，从而造成发布速度越来越慢、上市时间不断被推迟。
重要的是，这通常不是由于业务或软件的自然复杂性，而是由于其构建和增长的方式与不断增长的业务需求不兼容。
架构设计 vs 架构发现
大多数情况下，项目开始时会开发某种类型的架构文档，但在开发生命周期中没有得到适当维护。我们需要面对这样的事实: 大多数情况下，源代码是唯一可用的最新文档。据此可以推断，软件体系架构不是在架构文档或图表或白板上设计的，而是依赖真正的实现。
这也意味着只有真正完成了构建，才会"发现"架构。架构发现是对系统进行逆向工程，以便了解它是如何工作的，或者确定优化或改进机会。此外，要完全理解系统最初设计者的动机和决策过程并不总是可行的，通常很难准确解释设计并确定优化或改进的机会。
改进架构设计，从而限制或摆脱架构发现
由于发现后很难改变，因此不得不提供不同类型的支持来保持其运行，换句话说，不断对系统缝缝补补。我们也能看到一些在发现架构时记录架构的努力，比如记录一些架构图，但讽刺的是，只要记录完成，就已经过时了。
敏捷对架构的影响
如今大多数软件都基于强调灵活性、协作和快速迭代的敏捷方法构建，这让团队能够快速交付可工作的软件，有助于确保正在开发的软件满足用户需求，并尽可能快速交付。
某些情况下，敏捷方法加速了架构侵蚀过程。
敏捷有时会对软件架构产生负面影响。一个常见问题是，关注于频繁交付小的功能增量可能会导致缺乏对长期体系架构问题的考虑，导致软件系统难以维护和扩展，并且容易产生技术债务。
另一个潜在问题是，强调快速交付可能导致缺乏文档和设计，使开发人员难以理解系统整体架构以及组合在一起的各种组件。
在这种情况下，通常更多关注业务，团队长期面临高交付压力，并且团队由非技术成员领导。在这种环境中，架构通常不是一个重要的、受欢迎的、容易讨论的话题。
遵循好主意并不能保证成功，根据具体情况和环境进行调整的能力往往会带来很好的结果。
经济价值
商业中的一切都归结为金钱、经济价值、短期利润和长期投资。对架构受损的系统进行更改的成本比设计良好的系统要高得多。
如果软件系统很难维护，通常会根据经济价值来计算，常见问题:"是否值得重写系统？即使需要额外时间来维护和合并新需求，是否还可以维护现有的系统？"
但是，当企业发现软件应用程序中的这些挑战时，就已经晚了，通常需要花费很多的时间、金钱和精力来升级软件。
企业有权知道，为什么会出现这种情况，如何才能在未来避免这种情况，能够吸取什么教训。
在某些情况下，我们还可以看到这个故事的第二部分。在这里，企业同意投资重新构建软件系统，从而基于长期目标和投资精神解决软件老化问题。开发团队从以前的经验中吸取教训，考虑当前和未来的业务需求，选择当时可用的最佳技术，开始构建系统。
大多数情况下，架构的破坏是由于缺乏流程，而不是缺乏技能。
这时，软件应用程序和体系架构得到了很多关注，大多数事情都很顺利，软件和体系架构得到了很好的构建。但随着时间推移、业务和软件不断发展，不断加入新的变更，团队成员在部门或公司之间转移，一段时间后，软件(及其架构)又开始从其原始设计和思想退化。
根据我的经验，当人们谈论架构时，会采取非常高层次或抽象的架构视图，从而可以通过很好、很简单的方式来理解系统是如何构建的，但在大多数情况下，魔鬼隐藏在细节中，通常很难从业务负责人那里获得资金来更新没有提供任何功能输出的体系架构。
作为企业主，很难拿出这么多钱来做没有明确商业价值的事情，尤其是可能只是解决症状，而不是根本问题。
架构工作应该是功能发布的一部分，而不是维护的一部分。团队应该将持续的重构作为开发过程的一部分。我知道这很难，因为敏捷过程主要关注交付，没有任何特定流程让整个组织可以看到和关注架构工作。
解决方案
对于软件老化和架构侵蚀的情况，有许多不同的理论，这里我只是表达自己的想法。
克服软件老化负面影响的最好方法之一是将软件变更和发展置于软件开发过程的中心。对软件系统的任何更改都应该遵循相同的路径。然而，在大多数情况下，无论是软件开发还是演进和维护过程都没有遵循这样的路径。由于业务或技术限制，更改大多直接被引入到实现中。
在我看来，架构愿景是保持软件及其架构处于健康状态的伟大技术之一。甚至更进一步，如果设计一个基于架构愿景的方法或流程，可以帮助团队将愿景作为软件构建和日常工作的一部分，想象一下团队成功交付维护良好的软件时是多么富有成效。
下一篇文章将讨论架构愿景和基于愿景的开发方法。请继续关注。
你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind
