11 法则五：架构师为什么要关注技术体系的外部适应性？
你好， 我是郭东白。
前四条法则分别讲了目标、资源、人性和技术周期，这些都与架构活动的外部环境有关。那么今天我们来讲讲在架构活动内部，也就是在架构师可控的范围内，应该遵守哪些法则。今天这节课，我们就先从技术体系的外部适应性讲起。
达尔文说过：“既不是最强壮的也不是最聪明的物种，而是最适应变化的物种最终生存了下来。”从这个角度来看，企业也是一个物种。一个企业在行业内与其他企业形成了竞争关系。那么最终在竞争中胜出的，不一定是体量最大的，也不一定是技术最先进的，而会是最适应竞争环境变化的企业。
计算机行业有很多这样的例子。比如大企业Lucent、Kodak、Compaq都在竞争中没落了，曾经技术非常先进的SGI、Sun Microsystems、Digital Corp到后来也都挂了。一个正面的例子是，微软在云计算领域原本慢了大半拍，但他转身非常彻底，后来很快就追上了，成了异军突起的赢家。
那么你作为架构师，能在企业的竞争中做些什么，同时也为自己创造增量价值呢？答案是：通过技术手段为企业注入更多的外部适应性。
这就是第五条生存原则要覆盖的内容：架构师要通过优化架构方案、干预架构活动，以保证最终交付的项目不仅能满足既定目标，还能适应不断变化的外部环境。这个过程有一个总的指导原则，那就是为最终产生的架构设计不断注入外部适应性。
架构师能注入外部适应性？
外部适应性是指一个企业对外部环境变化的适应能力，以及对新机会的捕捉能力。
我特别要强调“外部”这个词。它表示适应性不是面向企业内部的，而是企业在外部环境发生变化时、在与其他企业竞争时所具备的适应能力。这是一个攘外而非安内的能力。
怎么理解呢？像苏宁和塔吉特（Target）这样的线下卖场，打磨了很多年之后，他们的效率很高。但当用户的购买行为都转到线上后，他们适应新的竞争环境的能力就不够了。也就是说，他们在互联网时代的外部适应性不足。
在企业中，不同职能所处的视角不同。那么你作为架构师，需要从自己的视角为企业注入外部适应性。同时在这个过程中，提升自己独立创造价值的能力。
不同职能之间视角的差异性
在企业中，很多职能都可以为企业注入外部适应性，举几个例子：
- 业务同学通过商业和投资手段，来迅速捕捉外部的商业机会，从而为客户创造价值，为企业获取竞争优势。比如大公司通过兼并小公司进入一个新兴市场。
- 运营同学通过新场景迭代效率，来提升企业的市场竞争力和市场占有率。比如阿里的大促运营，就是通过一系列营销手段来提升获客效率和销售额的，从而扩大了市场渗透率。
- 产品经理通过不断打磨产品来提升用户体验，从而达到提升企业竞争力和市场占有率的目标。比如抖音创作者和用户端的产品优化。
- 技术同学通过打磨技术体系来支持产品和运营，从而达到提升企业外部竞争力的目标。比如各个互联网公司都在打磨个性化算法、运营后台、数字化运营体系。
架构师是技术职能的一种，所以也是通过打磨技术体系来为企业注入外部适应性的。当然，架构师这个职能有自己的特殊性。首先，架构师与研发经理不同。后者具有人员管理的职责，因而可以通过人才招聘、培养和组织架构的调整来创造价值。
然后，架构师也不同于研发人员。研发人员可以通过优化数据模型、算法迭代、代码重构和模块升级来为企业直接注入外部适应性。而架构师仅仅可以通过组织架构活动与优化架构方案设计，来为企业注入外部适应性。
可以看到，我特别区分了几种职能所处视角的差异。为什么这么做呢？我发现，很多架构师把帮助他人创造价值与自身创造价值这两件事混为一谈，这样做，你就很难提升自己独立创造价值的能力。
举个例子。在大公司某个程序员晋升时经常会套用这样一个逻辑：“我们的大促业绩同比增长了50%，所以我应该晋升。”
仔细想想，这个增长到底是业务方在大促期间多拓展了一倍商家带来的？还是产品同学重新设计了大促的商品圈选和反向招商逻辑，导致平台商品增长了30%带来的？还是你通过技术创新，用知识图谱把商品之间的语义标签做得更多更准，导致交叉售卖的量增长带来的？
所以说，你负责大促的商品模块，不代表大促中所有商品售卖赚来的钱都是你挣来的。这个时候，你就需要展示自己从技术视角上创造的价值，这才是你独立创造的增量价值。如下图所示，展示了业务、产品和技术视角的差异性。
业务、产品和架构师所处的技术视角，分别代表研发活动的三个不同层次。
第一个层次，研发活动由业务驱动，直接在业务人员的指挥下响应外部机会。我们把这一组研发人员称为业务线研发。在一些公司里，这些人一般直接向业务部门汇报。比较常见的是增长的产品和技术人员同时汇报给增长业务部门，以迅速响应新的业务机会。
第二个层次，研发活动由产品规划驱动。产品把业务活动抽象为一组产品，沉淀出产品矩阵，并通过产品运营不断打磨用户心智。在这个过程中，相应的技术人员会不断提升自己对产品的理解，并通过技术手段放大产品提供给用户的增值。
比较常见的产品有营销产品、供应链产品、物流产品等。除了产品特性本身外，一些纯技术手段，比如营销的资金池优化、反作弊、供应链优化、物流调拨等等，也会为产品带来新的增值手段。
第三个层次，研发活动就是由架构师主导的架构活动。架构师和研发同学对业务、产品做了一系列的抽象，最终形成由技术驱动的技术产品。比如工作流引擎、风控引擎、策略引擎、算法的特性引擎和标签引擎，都属于这一类产品。
案例指引
我拿一个物流领域的场景来举例。如图所示：
假设你所在的企业有比较复杂的物流场景，那么业务团队经常会找新的物流供应商， 为平台提供物流的外包服务，或者是覆盖一个新场景，也或者是覆盖一个新路线。那么相应的业务线物流团队，就需要与供应商对接，迅速完成接入。
但是随着时间的推进，团队在物流上的经验变得更丰富了，物流线路也越来越多，单个供应商对接的方式只会越来越低效。这个时候，就需要有一个产品团队，把企业内部与物流相关的服务抽象成一组产品，让产品替代人力完成供应商的接入需求。
这时候，产品和技术同学可能抽象了一组物流的自动接入API，定义了要交换的数据和相应的交换标准，甚至提供了沙箱环境，为第三方软件服务提供商提供便利。他们甚至可以介入，帮助物流供应商迅速接入。
随着产品和技术能力的进一步提升，技术同学可能会看到更多机会。比如对不同物流提供商的履约能力、履约时效、服务质量、用户满意度等做评分，形成一个供应商的信用系统。这个信用分可以用来控制履约成本，保障履约质量，以及提升供应商的合作意愿。
事实上，这个系统的很多设计都可以抽象出来，提供给物流之外的供应商使用。比如品控的供应商、仓储的供应商、安装维修的供应商等等，这就形成了一套供应商信用管控、供应商管理，以及根据供应商服务能力与成本做成的动态路由的体系。
之后，这个技术体系还可以在多个领域重复使用。那么自顶向下，一个公司的外部适应性就逐渐得到了提升。从最顶层对单个业务场景的直接响应，到下一层多个业务场景对单个产品的抽象，使得该产品和相关技术能够直接服务到多个业务场景。最后，多个产品被架构活动抽象成了一组底层技术产品。而这些技术产品，就可以在多个领域的产品中得到复用，使得多个产品领域和这些产品支持的多个业务领域，都能提升自己的外部适应性。
通过以上分析我们就比较清楚了，架构师需要在技术层面为整个企业的技术体系注入外部适应性，这才是你独立于其他职能所创造的长期价值，是你有底气的自尊的源泉。
那么架构师怎么做才能为企业的技术体系注入最大的外部适应性呢？想逼近这个问题的答案，就必须理解削弱一个技术体系外部适应性的因素都有哪些。
影响技术体系外部适应性的因素有哪些？
我们可以从三个角度来分析。
企业内部压力的影响
先从职能角度来分析。技术之外的同学，比如业务和产品同学，几乎不关注技术体系的外部适应性。一来他们不擅长，二来这也不是他们工作的优先级。遗憾的是，业务线的技术同学，以及与产品密切配合的技术同学，往往也很少关注技术体系的外部适应性。这里面的原因比较复杂，主要有三个。
第一，业务交付时间的压力。技术同学经常受到来自业务和产品同学交付时间的压力，这样一来，技术质量都很难保障，更不用说技术的外部适应性了。
第二，技术岗的供给压力。最近几年技术岗的供给比较缺乏，很多技术同学频繁跳槽，在一家企业的工作时间较短，因而他们在客观上就不太关注自己的技术口碑。
第三，考核的压力。不少企业把技术岗的考核内容、考核周期都与业务线牢牢绑定。而需要长期打磨的技术能力，既不能被关注和度量，也没有资源被孵化。结果就是短期效应非常明显，自然，技术同学就很少关注技术的长期适应性了。
除了团队内部的压力外，企业也面临着不少压力。首先，时间对于所有的职能而言都是稀缺资源，大多数互联网企业都采用了小步快跑的迭代方式，很少有企业是先把问题研究清楚才入场的。大家都是边打边学。不论是业务岗、产品岗，还是技术岗，都是摸着石头过河，这就不可避免地导致所有职能都被自己的认知局限所羁绊。
比如你经常听到技术同学说“产品同学不靠谱，一天到晚改需求”。产品呢，则每天抱怨业务同学从早到晚变方向，朝令夕改。
事实上，这种行为在越是高速增长、竞争激烈的行业越是常见。等你完全看清楚一个行业，新的商业机会早就不在了。
你可以观察下社区团购，在短短半年多的时间里，就有数百亿的投资注入到这个模式之中。等你花半年时间准备好大举进入的时候，不但战局大变，就连监管环境也发生变化了。这个时候，由社区团购这个新模式带来的市场渗透机会就完全不存在了。
这有点儿像打猎，你不可能说：“你别动，让我打死你！”你距离猎物越近，与此同时你失去这个猎物的概率也就越大。
可以说，在时间的压力下，大家都不会在完全看清楚一个市场才行动。因此处在最底层的技术体系，在外部适应性上不太可能有充足的时间和精力去做到完美。
企业外部环境的影响
最常见的削弱一个技术体系外部适应性的外在因素就是竞争。竞争会打乱企业的部署和节奏，迫使企业不得不响应市场环境的变化，而不是有规划有节奏地做自己的业务和产品。
在这种情况下，不但技术体系不能提升外部适应性，甚至连产品和业务也没办法通过自己的方式提升企业的外部适应性。因为竞争会打乱企业的节奏，给企业各个层面带来影响：
- 有的影响是业务层面的。比如多个企业对流量渠道的竞争，大促和营销力度和时长，履约和服务的人群和地区性优势，等等。
- 有的影响是产品层面的。比如不同的用户体验和用户心智，不同的产品定位和功能，等等。
- 也有的影响是技术层面的。比如对长尾设备的覆盖，对创新技术的支持，商业生态、产品技术和API的开放性和兼容性，等等。
竞争对手在业务、产品和技术层面的动作，都会迫使企业做出相应的应对动作，很少有企业能我行我素的。
还是用打猎的比方来解释。哪怕你起得再早，准备得再好，总会有其他猎人在那里捣乱。这些猎人哪怕打不到猎物，也会放一枪把猎物吓跑。否则你打到了，他就再也没机会了。
除了竞争外，还有其他环境因素也会影响技术体系的外部适应性。比如用户需求的流行趋势、宏观经济周期、监管环境、资源供给、技术趋势等等，无时无刻不在发生变化，这些也可能导致企业原有的外部适应性的计划失效。
举个宏观经济环境的例子。在大多数风险投资充足的地区，尤其是中国和美国，大多数企业其实并不具备对外部适应性做长期规划的条件。因为一旦某个外部环境的变化被市场感知到，这种变化如果不能被已有玩家高速响应的话，那么资本市场，尤其是风险投资，必然会迅速入场。
就像在国内，很少有明显的机会能够在半年内都没被资本深入挖掘的。往往是机会一旦出现，资本会在一两个月内迅速集结力量做出响应。
企业组织结构的影响
最后一类削弱技术体系的外部适应性的因素，与企业的组织结构有关。不论是业务线研发、产品研发，还是基层技术的研发，这些同学的本能反应，都是先维持自己的生存空间。
另外，因为各个领域的内部目标、具体挑战和资源环境都不相同，所以每个领域的研发人员设计出来的软件架构自然也存在差异。
也就是说，研发人员由于自身认知局限、沟通的局限，或者是为了保护自己团队的利益，导致他们的设计都是局部最优，而不是全局最优。这种局部和全局的冲突，在一个跨团队的大型架构活动中很容易外化出来，导致整体的外部适应性随着组织复杂度的提升而被削弱。
那么你作为一个架构师，就要通过技术抽象为一个企业创造出经得起时间考验的整体设计，从而为企业的整个技术体系注入外部适应性。那么如何做到这一点呢？我们下节课就来讨论这个问题。
小结
这节课我们聊到了一个很重要的话题：你作为独立于其他职能的架构师，可以创造什么价值？有些leader认为自己创造的价值就是被自己管理和影响的人的创造的增量价值之和。也就是说，这些leader是间接创造价值的。架构师当然可以通过参与架构活动的每个人间接创造价值。 但是在此之外，你要通过为软件系统注入外部适应性而为企业直接创造价值。
我认为架构活动是企业软件进化的一个特殊节点。在这个节点上，所有参与者都在重新审视现有架构体系的不足，然后引入新的设计和技术。在这个过程中，你其实在为企业注入新的技术基因。
从这个视角来说，上帝经由你的手来改变企业这个物种。那么你就要抓住这个机会，运用我们前几个法则中传递的知识：逼近正确的目标、尊重人性、最大化商业价值，以及利用好技术生命周期，然后通过你的架构设计和对架构活动的决策来最大化企业的外部适应性。
思考题
- 请列举一个通过某种技术为企业注入外部适应性的例子，并着重描述：外部环境发生了什么样不连续的变化？这个技术为什么可以帮助到企业？你是如何识别这个技术的价值？还有其他选项吗？
- PC互联网到移动互联网过渡的时候，很多技术由于没能适应这个变化而逐渐被淘汰。你有类似的经历吗？比如在外部环境发生变化后，你开发的原本很受市场欢迎的技术，一下子就被大幅削弱了？为什么很难适应这种外部变化呢？你认为什么样的技术可以适应这种变化呢？
- 外部适应性是面向未来的。你有没有见到过某个技术选型看似万无一失，似乎绝对能保证企业的外部适应性，但后来却在竞争中落败了？而你发现竞争对手的选型非常成功。你认为是什么原因导致你们做出错误的选型，但是竞争者却能作出正确的技术选型呢？ 当然，你也可以分析开源的技术。
如果今天这节课对你有帮助，欢迎你点击课程右上角的分享并赚钱按钮，把课程转发给你的同事或朋友，大家一起交流、进步。我们下节课再见！
- neohope 👍（17） 💬（4）
1、之前有一个不到十人的小移动团队【含后端】，用纯原生方案开发表单类APP，客户要求不断变化，迭代速度总是赶不上前线要求。后面建议用React Native进行了替换，IOS也买了企业证书，安卓和IOS人员单点压力一下没了，整体交付响应速度快了两倍以上。 对于这个产品的PC版本，也建议过用Electron替换Winform，但被义正言辞的拒绝了。因为他们Winform的壳子已经很稳定了，很多功能就是套用了Chrome浏览器插件，没有跨操作系统的需求，而且没人愿意转Electron，反思是有些不尊重人性了，哈哈哈。 2、PC到移动互联网过渡，记忆深刻的有Flash，SilverLight，Applet从流行到被彻底淘汰，主要是根本无法满足移动端需求，甚至在刚对上H5的时候就败下阵来。其实还有JSP，JSF，Struts，jQuery等很多技术也是从流行到逐步没落。 3、外部适应性这个挺多的。比如Skype。被收购时技术领先，但做着做着就被新崛起的小公司们干掉了。感觉微软收购了Skype，总是要让Skype先融入自己的PC生态，而不是用互联网思维去快速响应市场变化，于是就没落了。当然这是事后诸葛亮咯。
2022-01-04 - Helios 👍（13） 💬（2）
让团队内部有清晰的大方向和目标应该也是注入外部适应性的一种。 2018年的时候公司发展很快，也引进来很多技术管理人才，然后就是频繁的组织架构调整，干前端的去干后端了，干后端的去干运维的，有个研发小伙子因为干的特别好，竟然让他去做支持，小伙子觉得和自己发展方向不一致直接辞职，还有好多老员工离职的时候说“看不到方向”…… 其中最令我深刻的是新来的总监大刀阔斧搞两个披萨理论，产品、测试、前后端控制在十个人，结果没看清楚历史包袱导致自己团队人总是给其他人干活。 我个人感觉组织架构调整是公司向上的标志，但是如果一次架构调整之后底下的人怨声载道，离职率徒增，那么最好的办法不是马上进行下一次调整而是思考。
2022-01-08 - Miss Independent 👍（8） 💬（1）
我觉得不仅是各个岗位，企业需要外部适应性，人也一样，感触比较深的是很多人在一种商业模式刚兴起时总是怀着质疑的态度，总是在去看别人怎么样，但是当目睹了那么多人在这种模式下收益，又开始想要跃跃欲试，但是这个时候往往已经是一个模式已经到了饱和的阶段。所以人也需要不断去注入外部适应性。要去在一种模式兴起时，认真分析优劣势，找准定位，勇于尝试。这个前提当然是我们对于兴起模式已经洞察接触的情况下，然而很多时候我们总是会满足于现实工作中的繁琐，不愿在空闲时间再过多关注其他兴起的事物与观念，所以导致我们错过了很多机会，对于事物的感知也是很重要的一个特质，而这种感知一定是源自于自我更高的追求、持之以恒的接收信息以及持续的思考总结。
2022-03-31 - 罗均 👍（6） 💬（1）
思考题作业： 1. 学生感觉，CTO或架构师引入什么技术不重要，更重要的企业是否具备持续适应环境变化的基因。例如福特汽车在2021年股价涨了140%，其从2011年入股pivotal开始，面对硅谷各大互联网巨头的嘲讽，硬着头皮坚持数字化转型，虽然和特斯拉差距还很大，但至少在传统车厂赛道上已经远远甩开了竞争对手。这也是我们中国企业最缺乏的企业文化。对于老师的四个问题，汽车行业内经久不衰的丰田生产方式，有一个核心原则——就是杜绝浪费。例如引入ReactJS实现车载娱乐的在线服务，基于树莓派或Arduino模拟整车环境做自动化测试，价值无非就是要大幅度减少人力和时间上的浪费。除了“什么都不做”外，其他选项就多了，至于选哪项，往往还是根据业务以最少浪费的选择——自动化测试台架的控制服务器，可以是拿retired laptop重新安装Linux后，安装开发好的docker镜像来跑的。 2. 学生去年曾想过开发一个车内online plugin app，通过控制空调压缩机开关的API来实现节省油耗。后来想想电动车时代了，燃油车会越来越少，而且费很大劲油耗降个10%，也不见得可以提升销量，所以很快就放弃了。 3. 失败的原因，学生觉得就是缺乏《易经·系辞》中提到的“自强不息”与“厚德载物”，或者这两者不如竞争对手。例如马云先生早年的发心，是为了“将千千万万商贩从商业地产商的残酷剥削中拯救出来”，今日的阿里好像缺失了点什么。技术选型不重要，谁去做更重要，例如特斯拉的车载娱乐系统，是基于x86开发的，其效果也没比其他用高通最牛的SoC开发的产品弱。
2022-01-06 - bigbigboy 👍（4） 💬（1）
感谢老师分享，有种醍醐灌顶的感觉。 是否可以分享一张全景图或者思维导图，信息量有点大，要不断地温习才能get到内容。
2022-01-04 - 咏晨桃 👍（3） 💬（1）
短期的外部适应性给我的感觉是扩展性，能否给其他领域未知领域快速接入，降低其他领域的从零到一的成本，因而带来的价值
2022-02-10 - 术子米德 👍（3） 💬（1）
🤔☕️🤔☕️🤔 * 📖：架构师，通过技术手段，为企业注入更多外部适应性 * 🤔：所谓企业的外部适应性，是否指当企业遇到不可掌控的外部力量时，具有更大的弹性来缓冲这种力量性打击，甚至因变化而带来更大的机会和优势。也就是说，适应性就是被动挨打的抗打击能力。 * 🤔：未雨绸缪这个词，是否比较合适用来概述这种行为。那对于预期的效果，如果是在事先判断，是否就是在做演绎。那对于实际的效果，如果在事后总结，是否就是在做归纳。不，归纳都算不上，更应该叫溯因。事情做成，总得找个成功的理由，然后就溯出各种曾经的技术手段，如何让企业更具有外部适应性。所以说，感觉这里逻辑上和认知上是否存在个矛盾。如果架构师的能力和视野，能够预判出未来可能的变化，那本该就做好，这实际上就是架构本该做好的工作。可是如果超出架构师的能力和视野，是否做什么都不见的会有实际效果，或者说做了其实也更可能是浪费。 * 🤔：这么说下来，要么有能力和视野，本来就能具有所谓的适应性，否则就是运气而已。如此思路，有问题嘛。 * 📖：帮助他人创造价值 vs 自身创造价值，如果混为一谈，难以提升自己创造价值的能力 * 🤔：创造价值，帮他人创造，自己创造，这得有区分，为何我从来没有思考过这个点，我缺少怎样的思考维度，才导致我根本就想不到这方面，这个方面对我是个更大的惊醒。 * 📖：业务驱动、产品驱动、技术驱动，架构师理解业务和产品，跟研发同学一起努力做出技术驱动的产品，并在业务里取得成果 * 🤔：一直等业务驱动，那就是每个项目都会做到现场通宵，一直等产品驱动，那就是经常肯德基奶茶半夜回家。只有自己理解业务和产品，用技术来驱动产品和业务，才能进入自身创造价值的过程，而等业务、等产品都只是在帮助他人创造价值，自己拿个辛苦钱而已。不过，即使技术驱动到产品和业务，这跟用技术体系使得企业更有外部适应性之间，有什么必然因果关系嘛。
2022-01-16 - 徐李 👍（2） 💬（1）
2.PC端向手机端过渡的时候，之前比较火的一个“校内网”很火爆，但是没有做好移动端的扩展，属于社交吧，之后慢慢没落了。包括类似很多这种“酷狗”“酷我”PC端很常见的 视频，音频播放器，很多热门的软件突然就消失了。 我自己的一个经历，就是2017年选型微服务架构的时候，那时候是大火，现在虽然也很火，但是这个能力就像一个基础能力，不那么出众了，再出去谈这种架构，就不感觉有什么优越性了。就是外部软件技术变化太快，也不是说当时哪个节点这个技术不行，只是随着市场需求发展，各种因数的制约，导致了一个最后结果就是普遍化了，通用化了，然后自然就没有先进性了。我觉得没有一个技术能一直适应外部环境的变化，应该是一个不断发展的技术在不断适应外部环境的变化。
2022-01-13 - 武斌 👍（2） 💬（1）
最近在做支付相关的领域，就在和团队一起探索数字人民币。当数字人民币更普遍的使用的时候，我们的系统如果能够简单的兼容，就说明对于外部适应性上做了设计。
2022-01-06 - 罗均 👍（2） 💬（2）
还有个问题想请教老师，就是此课提到的“随着产品和技术能力的进一步提升，技术同学可能会看到更多机会。……以及提升供应商的合作意愿。” 这里面“技术同学”是指架构师还是研发人员呢？这类活动属于架构活动吗？ 谢谢老师！
2022-01-06 - 小兵 👍（2） 💬（1）
需求老是改，这个太有画面感了 不过研发人员也需要有一定能力挡住部分不合理需求。曾经见过一个产品在需求评审会前半个小时提了6个需求，问到为何突然这么提，回答说是他boss觉得很多事情他没落地，所以他得赶紧把需求提出来… 话说回来，在一个快速变化的市场，方向的快速变化确实是不可避免的。个人理解：架构师（有些公司是技术负责人）这时候需要做的上和业务&产品保持紧密沟通，确保技术、业务、产品的方向是一致的，另外架构师自身也需要紧密关注行业内的知识和变化，能够在技术架构上有一定预判。这个时候可能没法像一个成熟行业做按年的预判，那能够做到按月的预判并且持续修正，最终应该不会偏差太多
2022-01-05 - Geek_fb8216 👍（1） 💬（1）
“逼近正确的目标、尊重人性、最大化商业价值，以及利用好技术生命周期，然后通过你的架构设计和对架构活动的决策来最大化企业的外部适应性。” 郭老师，你好，想问下，前四个法则和第五个法则的关系是手段和目的关系吗？还是说他们是平行独立的
2022-01-13 - 郭桑 👍（1） 💬（1）
想想我前公司（制造业龙头）的“架构师”们，天天除了卡流程舔领导啥也不干。CIO说要搞云原生，虽然他们也不懂什么是云原生，但是马上要求所有项目文档必须体现云原生方案，不然不给批，诶……
2022-01-11 - 罗均 👍（1） 💬（1）
能否请教老师，由老师总结的精辟的三个企业内部压力，对于架构师或研发经理来说，有什么好的化解方法的建议吗？ 对于一线的研发人员，是否应该由自己思考如何在压力与长期技术规划中寻求平衡呢——其实老师的这么课，非常有利于一线研发人员的规划设计。至心感恩老师🙏
2022-01-06 - Geek_sa2mt4 👍（0） 💬（3）
回答下思考题1: 之前在一家公司做创新项目，自己做了个app。由于处于探索阶段，需求变化快，数量多，原生app开发需要同时开发安卓和ios两个版本，测试工作量也是double的，迭代速度慢，这对于一个创新项目来说并不利。所以后来经过讨论，采用h5嵌入到安卓和ios的方案，这样原生安卓和ios的架子基本不用动，每次修改只需要h5同学修改即可。并且测试时h5页面可以独立测试，测试成本降低，迭代速度大大提升。 当时有想过一套代码同时生成安卓和ios代码的方案，但还是不如上面h5嵌入的方案快，就被否了。 后来我们发现这样的方案还需要用户下载一个单独的app，不利于推广，所以迭代出了微信小程序的方案，用户扫码授权即可使用，而微信小程序本质上就是个h5页面，很方便迭代，这时的试错速度更快了，也算提高了企业的外部适应性吧。 但后来这个方案带来了和之前原生方案一样的问题。由于一些原因，我们需要支持支付宝小程序，而支付宝小程序和微信小程序是不兼容的，并且小程序对嵌入的h5的支持都不理想，这就导致我们每次都需要开发两套，测试两套，跟之前一样了。你可能要问为什么要开发支付宝小程序？从外部的角度决策，微信小程序才是主要入口，但我们这个创新项目需要内部的支持，而支付宝小程序则是为了证明我们的政治正确，如果不做，这个项目可能从内部就被掐死了，没机会讨论怎样提高外部适应性了。
2022-09-12