共计 2759 个字符，预计需要花费 7 分钟才能阅读完成。
软件架构必须随着业务倒退而演进，否则就会成为业务的妨碍。但架构自身在倒退过程中很容易逐步腐化，沉积大量技术债权，因而在软件倒退过程中始终保持架构愿景十分重要。原文: Software architecture — Paying the Price for Neglecting it
在商业世界中，咱们通常通过构建软件来解决业务需要。随着工夫的推移，软件逐步倒退，在市场上获得了胜利，领有了弱小的用户需要、踊跃并充满活力的开发气氛，获得了优良的投资回报。事实通知咱们，软件系统是要害业务资产，为了保护资产价值，必须进行更改、更新和治理。
因为业务环境 (市场) 的动态性，软件系统须要一直倒退以匹配零碎及其用户一直变动的需要，以放弃其竞争力和生机。
没有什么比放弃不变的胜利更失败的了。
随着软件的倒退，规模和复杂性也在减少。最现实的状况是，体系架构会随之扩大以反对需要的变动。如果对变更不足适当的治理，体系架构就会好转、难以保护，并产生架构债权。随着时间推移，沉积了大量技术债的软件系统会越来越难以保护和批改，从而导致系统过期、不牢靠，无奈跟上一直变动的业务需要或技术提高。
如果在不思考变更影响的状况下扭转体系架构，则软件架构将偏离其原始设计，导致架构漂移。因为所做的变更没有思考对架构的影响，最终会导致对架构的侵蚀。架构侵蚀通常被定义为一种景象，在这种景象中，利用的初始体系架构被任意批改，以至于无奈放弃其要害属性。
打个比方，这就像修建的原始地基是为了包容一座两层楼而建的，但因为看起来还不错，所以持续在同一个地基上一直搭建更多楼层。
在一系列 (n) 个版本中，下一个版本 (n+1) 的体系架构是基于先前被侵蚀的体系架构设计的，从而对下一版本架构的有效性产生质疑。如果无奈被纠正，状况只会越来越糟。
软件老化的症状包含性能降落、谬误或解体减少以及用户体验降落。因为减少了复杂性，可能须要更长时间引入新需要，从而造成公布速度越来越慢、上市工夫一直被推延。
重要的是，这通常不是因为业务或软件的天然复杂性，而是因为其构建和增长的形式与一直增长的业务需要不兼容。
架构设计 vs 架构发现
大多数状况下，我的项目开始时会开发某种类型的架构文档，但在开发生命周期中没有失去适当保护。咱们须要面对这样的事实: 大多数状况下，源代码是惟一可用的最新文档。据此能够推断，软件体系架构不是在架构文档或图表或白板上设计的，而是依赖真正的实现。
这也意味着只有真正实现了构建，才会 ” 发现 ” 架构。架构发现是对系统进行逆向工程，以便理解它是如何工作的，或者确定优化或改良机会。此外，要齐全了解零碎最后设计者的动机和决策过程并不总是可行的，通常很难精确解释设计并确定优化或改良的机会。
改良架构设计，从而限度或解脱架构发现
因为发现后很难扭转，因而不得不提供不同类型的反对来放弃其运行，换句话说，一直对系统缝缝补补。咱们也能看到一些在发现架构时记录架构的致力，比方记录一些架构图，但讥刺的是，只有记录实现，就曾经过期了。
麻利对架构的影响
现在大多数软件都基于强调灵活性、合作和疾速迭代的麻利办法构建，这让团队可能疾速交付可工作的软件，有助于确保正在开发的软件满足用户需要，并尽可能疾速交付。
某些状况下，麻利办法减速了架构侵蚀过程。
麻利有时会对软件架构产生负面影响。一个常见问题是，关注于频繁交付小的性能增量可能会导致不足对长期体系架构问题的思考，导致软件系统难以保护和扩大，并且容易产生技术债权。
另一个潜在问题是，强调疾速交付可能导致不足文档和设计，使开发人员难以了解零碎整体架构以及组合在一起的各种组件。
在这种状况下，通常更多关注业务，团队长期面临高交付压力，并且团队由非技术成员领导。在这种环境中，架构通常不是一个重要的、受欢迎的、容易探讨的话题。
遵循好主见并不能保障胜利，依据具体情况和环境进行调整的能力往往会带来很好的后果。
经济价值
商业中的所有都归结为金钱、经济价值、短期利润和长期投资。对架构受损的零碎进行更改的老本比设计良好的零碎要高得多。
如果软件系统很难保护，通常会依据经济价值来计算，常见问题:” 是否值得重写零碎？即便须要额定工夫来保护和合并新需要，是否还能够保护现有的零碎？”
然而，当企业发现软件应用程序中的这些挑战时，就曾经晚了，通常须要破费很多的工夫、金钱和精力来降级软件。
企业有权晓得，为什么会呈现这种状况，如何能力在将来防止这种状况，可能汲取什么教训。
在某些状况下，咱们还能够看到这个故事的第二局部。在这里，企业批准投资从新构建软件系统，从而基于长期指标和投资精力解决软件老化问题。开发团队从以前的教训中吸取教训，思考以后和将来的业务需要，抉择过后可用的最佳技术，开始构建零碎。
大多数状况下，架构的毁坏是因为不足流程，而不是不足技能。
这时，软件应用程序和体系架构失去了很多关注，大多数事件都很顺利，软件和体系架构失去了很好的构建。但随着时间推移、业务和软件一直倒退，一直退出新的变更，团队成员在部门或公司之间转移，一段时间后，软件 (及其架构) 又开始从其原始设计和思维进化。
依据我的教训，当人们议论架构时，会采取十分高层次或形象的架构视图，从而能够通过很好、很简略的形式来了解零碎是如何构建的，但在大多数状况下，魔鬼暗藏在细节中，通常很难从业务负责人那里取得资金来更新没有提供任何性能输入的体系架构。
作为企业主，很难拿出这么多钱来做没有明确商业价值的事件，尤其是可能只是解决症状，而不是基本问题。
架构工作应该是性能公布的一部分，而不是保护的一部分。团队应该将继续的重构作为开发过程的一部分。我晓得这很难，因为麻利过程次要关注交付，没有任何特定流程让整个组织能够看到和关注架构工作。
解决方案
对于软件老化和架构侵蚀的状况，有许多不同的实践，这里我只是表白本人的想法。
克服软件老化负面影响的最好办法之一是将软件变更和倒退置于软件开发过程的核心。对软件系统的任何更改都应该遵循雷同的门路。然而，在大多数状况下，无论是软件开发还是演进和保护过程都没有遵循这样的门路。因为业务或技术限度，更改大多间接被引入到实现中。
在我看来，架构愿景是放弃软件及其架构处于衰弱状态的平凡技术之一。甚至更进一步，如果设计一个基于架构愿景的办法或流程，能够帮忙团队将愿景作为软件构建和日常工作的一部分，设想一下团队胜利交付保护良好的软件时是如许富有成效。
下一篇文章将探讨架构愿景和基于愿景的开发方法。请持续关注。
你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。微信公众号：DeepNoMind
本文由 mdnice 多平台公布
