架构设计，如何抵抗内部因素来提高技术体系的外部适应性-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_44485280/article/details/144217929

文章目录

前言
一、影响技术体系外部适应性的内部因素有哪些？
二、如何抵抗内部因素来提高技术体系的外部适应性？
总结

前言

架构师要通过优化架构方案、干预架构活动，以保证最终交付的项目不仅能满足既定目标，还能适应不断变化的外部环境。这个过程有一个总的指导原则，那就是为最终产生的架构设计不断注入外部适应性。架构师是技术职能的一种，所以也是通过打磨技术体系，即通过组织架构活动与优化架构方案，来为企业注入外部适应性。

在这里插入图片描述

一、影响技术体系外部适应性的内部因素有哪些？

1、业务交付时间的压力

1.1、技术债务积累

为了满足交付时间要求，技术人员可能会采取一些短期有效的快捷方式，如硬编码、不合理的架构设计等，这会导致技术债务的积累。这些技术债务会在后续的系统维护和升级中带来巨大的成本和挑战，降低技术体系对外部变化的适应能力。例如，为了赶在竞争对手之前发布产品，开发人员可能会采用简单但不易扩展的架构，当后续需要添加新功能以适应市场需求时，就会发现技术架构难以支持。

1.2、忽视需求的深度分析

交付时间压力可能导致技术团队没有足够的时间去深入分析客户或市场的需求。他们可能只是满足了表面的功能要求，而忽略了对未来需求变化的前瞻性考虑。例如，一个企业管理软件项目在交付压力下，只实现了当前客户提出的基本功能，但没有考虑到行业发展趋势对软件功能的潜在需求，导致软件在后续市场竞争中难以适应。

1.3、降低技术质量

紧迫的交付时间往往会压缩测试和质量保证环节。这可能导致技术产品存在较多的漏洞和缺陷，影响其在外部市场的可靠性和稳定性。例如，在产品开发过程中，为了按时交付，减少了压力测试和安全测试，结果产品在上线后频繁出现故障。

2、技术岗的供给压力

年轻的程序员跳槽是非常频繁的，一方面追求技术成长和发展空间，另一方能直接带来非常可观的涨薪幅度。这就导致一个什么问题呢？在一家企业的工作时间较短，所以他们在客观上就不太关注自己的技术口碑。我也碰到过不少这样的同学，他们底子很好，有着狂热的技术追求和明确的职业规划，所以只是把这家公司当做丰富经验的一个跳板。他们大胆尝试新技术不顾后果，对于技术含量一般的任务却敷衍了事，结果就是产出很一般甚至会留下很多技术债务。一两年后他会跳到一家不错的公司，然后你又招了一个有着狂热技术追求和明确职业规划的年轻同学……

3、考核的压力

不少企业把技术岗的考核内容、考核周期都与业务线牢牢绑定。而需要长期打磨的技术能力，既不能被关注和度量，也没有资源被孵化。结果就是短期效应非常明显，而技术同学却很少关注技术的长期适应性了。

大多数互联网企业都采用了小步快跑的迭代方式，很少有企业是先把问题研究清楚才入场的。大家都是边打边学，不论是业务岗、产品岗，还是技术岗，都是摸着石头过河，这就不可避免地导致所有职能都被自己的认知局限所羁绊。在越是高速增长、竞争激烈的行业越是常见。等你完全看清楚一个行业，新的商业机会早就不在了。

二、如何抵抗内部因素来提高技术体系的外部适应性？

1、高速响应业务与技术的需求

1.1、对于尝试性需求的正确取舍

技术人员如何在高速响应业务和技术需求的同时，还能够保障技术体系的外部适应性？那就是必须依据目标做出正确的取舍。为什么要做取舍呢？因为绝大多数的业务和产品需求只是一个小尝试，而并非战略性投入。对于这类业务尝试，响应的速度是第一优先级，只要不破坏外部适应性即可。

业务、产品和技术人员之间都在互相博弈。也就是没有任何一个业务、产品和技术人员愿意主动承认自己的需求是个小尝试。大多数人都试图找出充足的理由去说服其他人把自己的需求作为最重要的工作。对于业务尝试，我们需要以最低成本完成这么一任务，在保障尝试结论有效性的前提下，最小化这个尝试对系统的冲击，因为大多数尝试是不成功的。

1.2、对于尝试性需求的架构原则

从架构设计的角度来说，我们要把大多数的尝试尽量封装到一个小的领域内。这个时候，多次的业务尝试不会随着时间而导致混乱，削减技术体系的外部适应性。做到这点，下面的这些架构原则非常重要：

单一职责：每个业务尝试尽量封装到一个单一模块中，一旦尝试失败，就可以迅速把业务逻辑下线，避免影响整体的复杂性。
最小依赖：整体架构设计要保障大多数业务尝试可以在业务层完成，如果每个业务方的需求都会侵入到底层的逻辑，那么每次尝试都会变成跨团队合作，这种架构会大幅降低业务尝试的速度。
最小数据共享：正在尝试中的业务应该尽量减少与其他业务模块的数据交换，尤其是输出，这样才能最小化它的爆炸半径。否则该业务尝试的数据模型会污染到其他业务，在尝试失败之后对其他业务的影响也会很难剥离。
最小暴露：在业务尝试期接口不对部门或企业外部暴露，包括 API、数据共享、事件、消息流等一切对外界造成影响的通讯机制。

1.3、技术人员稳定性差和设计短视的问题

技术岗供给压力导致技术人员的稳定性差和设计短视的问题。想减少这种问题，你作为架构师可以：

提升对封装能力重要性的认知。你要帮每个做技术的同学认识到：我们都要有有效地封装业务尝试的能力，这个能力最终会转化为你提升技术的外部适应性的能力。这是一个技术人员的基本功，从你写代码的第一天就需要。只不过随着你的职业发展，你从封装代码逻辑，到了封装业务逻辑，最后到了封装业务尝试。
建设复杂度控制机制。在这里，设计评审很关键。业务尝试也要有设计评审，而评审的一个固定环节就是逻辑、数据和接口的最小爆炸半径的设计。
推行最小必要架构原则。任何增加功能、引入复杂性的设计，都要做一个正式的评审，而简化的行为则不需要。

2、完善技术体系的考核

短期效应这种挑战，它的根因在于公司的激励机制不够合理，这是制度上的问题，要靠改变公司的制度来修复。团队中不乏这样的同学，技术能力一般但是很拼，总能加班加点的把任务交付掉。但是代码风格晦涩难懂，技术设计更是毫无拓展性可言。从短期目标，尤其是从没有 review 过他代码的人员视角来看，他确实是个不错的员工，但是从长远的技术建设来看，他越努力埋的坑就越多。所以，把绩效考核仅仅与业务结果绑定，而把技术线晋升与长期的技术体系建设绑定。