架构师进阶之路 - 架构优化为什么难

       

目录

业务迭代和技术优化难以兼顾

缺少“上帝”视角思维

系统架构腐化

缺少架构师视角

系统迭代机制

设计规范把控

---

最近在组织团队内的系统架构优化，总而言之就是难，至于为什么难我这边总结了以下六个方面，记录一下自己的架构师进阶之路吧。

业务迭代和技术优化难以兼顾

重要的事：架构设计优化，让系统具有足够的“弹”性

紧急的事：业务迭代支持，让系统支撑业务持续发展

我们将日常中的事情分为重要、紧急四个象限，然后对系统架构优化和业务迭代填空在四个象限内。

1）重要且紧急

2）重要不紧急

3）不重要但紧急

4）不重要且不紧急

系统架构设计优化：重要（占据第 1、2 位）

业务迭代支持：紧急（占据第 1、3 位）

但是我们日常工作中，业务、产品与研发部门经常犯的错误就是将第三优先级的事情提到了第二优先级去做。显而易见重要的系统技术优化事项被业务迭代所排挤。为此我们研发人员经常会抱怨，没有时间来做技术优化，自我调侃为：“又在搬砖...”、“又在加班写 BUG ...”

似乎我们忘记了：业务部门就是只盯着业务的，对于系统架构的评估和优化，本来就是研发人员的工作职责！如何平衡好这两者的工作，是研发人员的晋级修养之路。

不要忽略系统架构的价值，假如有一天系统难以维护到只能推翻重来的地步，可以说是系统技术优化跟不上业务的快速迭代，同时侧面说明了研发同学的本职工作做得不够格！

缺少“上帝”视角思维

我们在以往的需求迭代中更多的是掉入到“需求陷阱”里，只关注自己负责的业务部分，而忽视“全局”。紧密的需求迭代节奏也是我们忙于堆砌代码，从而忘记停下脚步来回头看看是否走在了岔路上。我们都知道最终都会达到罗马，但是有的人走的是“直道”，有的人走得是“弯道”。我们要时不时跳脱出来，回过头来重新审视一下全局的业务、产品、系统设计是否合理。

系统架构腐化

多人协作问题：如果系统的开发人员没有严格遵循一致的开发规范，或者没有建立好有效的代码管理机制，可能会导致代码结构上的混乱，从而增加系统的开发复杂度和维护成本。

无规划性的技术栈升级：开发人员过于频繁地尝试新技术，不仅会使技术栈变得复杂，也可能会影响系统的稳定性和安全性。

缺乏良好的测试机制：系统的测试机制如果缺乏，可能会严重影响代码质量，就像没有人为项目提供反馈似的，从而使代码中的错误不被及时发现，令错误在系统中逐渐积累。

研发人员变动：如果组织的团队成员经常性更换，新旧人员之间没能形成有效的衔接和匹配，可能会导致系统的连续性和稳定性受到影响，乃至出现系统架构腐化的问题。

系统逐渐复杂化：在系统的长周期的演化过程中，难免会增加新需求、新功能模块和服务组合, 由此引进新框架、新模型。然而在此过程中，如果没有及时做好架构积累和提前预估架构变动的影响，可能会导致系统逐渐变得复杂，就像人体长期积累毒素一样，最终带来严重的后果。

总之，系统的架构腐化可能源自于开发人员、组织和系统本身等多方面原因，需要我们在系统的开发、测试、运维和补救中，有针对性地逐一落实。「预防胜于治疗」，预防性战略是减少系统架构腐化的关键环节。

缺少架构师视角

产品需求把控：我们平时的研发工作中缺少架构师思维，缺少结合产品、技术层面的全局把控，没有在产品需求阶段指出合理的需求方案，导致在开发阶段出现需求不通临时需求变更。

缺少系统分解思维：系统分解一般分为纵向分解和横向分解，纵向分解是将整个系统拆分，从而将整体系统分解成下一级的子系统与组件。横向分解是在系统分解成不同的逻辑层或服务后，对逻辑层进行分块，确定层与层之间的关系。由于在系统设计的时候缺少分解思维，导致实现的系统“大而边界不清晰”。

通常架构师也不太会跟每一个需求，这就需要我们团队中的高阶同学，负起必要的责任，尤其要基于技术细节尽量站在全局视角最好技术把关。

系统迭代机制

做项目而非做产品：软件系统的开发和演进有很多驱动因素，导致系统更加复杂的是按照特定需求开发特定功能，也就是做项目的方式。每次都有明确的目标，而且这个目标的方案多数也是设计好的。

做项目的方式对系统最直接的影响就是需求的一致性或几次迭代，多个不同的项目作用在同一个系统上，为了解决不同的问题，单纯的叠加功能，缺少对这个软件系统的整体认知和规划。而不像做产品，每一款产品都有一个愿景和核心要解决的问题，任何不符合愿景或者无法帮助解决核心问题的需求都是伪需求，不应该被添加到这个系统中。

因此，以做项目的方式推进的软件系统，随着项目不断的推进，多个不相关或没有经过深思熟虑的需求叠加到系统中，也会不断加剧软件系统的复杂度。而事实就是我们的现状就是按照项目制去进行软件开发，这种问题在所难免但是我们可以在同一个系统中做好业务分层，不同的业务尽量隔离。

设计规范把控

TechnicalDebtQuadrant上图来自大名鼎鼎的“MartinFowler”，MartinFowler将技术债按照 鲁莽的（Reckless）/谨慎的（Prudent） 以及 故意的（Deliberate）/无心的（Inadvertent） 划分到4个不同的象限中。

谨慎的 且 故意的：这种场景很常见，是已知技术债的一种主要来源。为了让产品快速投入市场，获得更大的收益，通常团队会选择更快速的方案，开发成本低，时长短，但解决方案并不是最优，且可能只是临时方案。然而，团队对技术选择做了详尽的评估，了解技术债产生后给产品和架构会带来什么影响，后果是可估量的，甚至已经安排好了未来的改进计划。

鲁莽的 且 故意的：相比上一个分类而言，团队知道当前的方案不是最优选择，但通常由于时间紧迫，实现当前的业务需求是第一优先级的，未对当前的方案做细致的分析，因此对遗留技术债可能产生的影响是未知的，甚至具体产生了哪些问题也可能是未知的。

鲁莽的 且 无心的：不计后果而又是无心之举，这往往是因为团队成员的认知还不足以判断当前的选择是不是会带来不良影响。这种技术债在技术债总体的占比很高，甚至可能比上面提到的第一种技术债更多。因为不管怎样的团队，人员的更替都是避免不了的，个人的经验不同，认知不同，在实现相同的功能时选择的方案也是不同的，虽然可以通过一些社交活动来减少不同团队成员的认知差异，如代码评审，但想通过这种方式来避免技术债的产生，效果往往并不是很好。

谨慎的 且 无心的：这种技术债看上去让人难以理解，既然每次都是深思熟虑，为什么还会有无心之失。然而，这种技术债确实也是无法避免的，甚至会经常遇到，最简单的莫过于当下基于当下的经验甚至业界最优的一些实践选择的技术方案或者技术框架，而随着技术的进步和发展，它们的弊端和问题也会逐渐显现出来，这些过时的技术方案设计和框架也就成了技术债。

解决

技术债解决日常化：研发团队要有守护架构的意识，在项目日常开发中，除了产品的业务需求外，应该规划一部分工作用于架构的优化，修复那些已知且有解决方案的技术债，这样才能持续保证软件系统的响应能力和产品质量。

明确研发规范，加强管理：对于已知且无解决方案的问题，只是没有深入思考对系统的影响，对于这部分技术债，为了让这些技术债在产生前就避免，或者引导到可以快速解决的方向，首先，需要建立团队的技术规范和标准，让每个决策都有依据。其次，加强流程上的管理，建立架构评审委员会，对架构的修改进行评审，一方面规避问题，另一方面根据问题完善规范和标准。

持续关注技术发展趋势，提前规划：随着技术的不断发展，很多几年前被认为非常先进的技术表现出了一些弊端，也逐渐在被新的技术替代。研发团队需要持续保持对技术发展趋势的关注，探索是否有更优的解决方案