09｜法则四：为什么要顺应技术的生命周期？

我尝试回答“弱点”这个，人性就是好逸恶劳，短视的，我认为这就是弱点之树。其实也就是老师说的“大尺度思考”这个方面，用比较流行的话，就是“长期主义”，一切基于长期思考，大尺度的思考，就会解决麻木，恐惧和路径依赖。 架构师很重要的一点就是全局思维，全局就是包括广度和深度。套用老师的那个“合并部署”的例子，如果用短视来思考，提高一时效率的，但是如果用大尺度，长期视角才思考，确是“反模式”。 真正的心理安全感，如果拉大尺度来看，更应该是拥抱变化，而不是畏惧变化。 写到这里，克服自身弱点，我想到还有“两心”： 1. 呵护好自己的好奇心，他会推动你打开更多的视野 2. 战略意图的雄心壮志，它让你不满足现状，不满足那一年半载的安全感。 志存高远，也要脚踏实地，日常我认为： 1. 冥想和反思 2. 多读历史 3. 思辨思考和逻辑训练，也就是老师说的思考力。

做了7年的Android原生开发，到现在为止整个行业基本雪崩。雪崩的开始就是不论出海国外还是国内，老板们意识到无论砸多少钱，再也出不来一个微信和抖音了，现在都不玩了，App就大厂在做，中小厂不做了，血淋淋地见证了一个技术兴起到衰落期。。。

人总会高估一年的变化，低估五年的价值。

问题三最近遇到一个案例。 公司16年服务化的时候选了dubbox，诚然当时做这个技术选型是没啥问题的。不过最近公司有块新业务，需要做私有化部署。这个新业务涉及到多个部门的开发团队。我们部门一开始判断是业务模式🈶️很大变更，而且不需要依赖原来服务（但是部分逻辑可以复用），可以趁此机会把部门技术架构升级。所以一开始推service mesh，但是另一部门坚持改造成本最小化，要求继续在dubbox上面更新。几番讨论下来，各让一步，用dubbox最新的版本dubbo3.0。在一家有一定年数的公司做技术升级真是太不容易，稳定、改造成本永远是横杠在研发人员头上的两座大山。那次讨论的时候，我在会上说，不要只考虑改造成本，你还需要考虑此后的运维成本，人力招聘成本，但是那些东西对很多技术决策者而言太过遥远

问题1：个人感觉在做更大尺度问题的判断和决策时，“不确定性”显著提高了，这也是人类生存天性中极力想规避的。 个人应对方法： 1. 尽量延后作出重大选择决策的时间点，确保信息的获取能够更加充分； 2. 尽可能让决策本身有足够的灵活性，回转余地，而不是“亡命一波流”； 3. 训练自己在一些假设前提下作决策的习惯，而不是像以往一样只能在确定性的需求下展开工作； 4. 记录下自己的决策，后续可以不断更新假设，复盘，持续提升。

“除了我分享的三个弱点外，你觉得还有其他弱点会影响我们看更大尺度上的规律吗？你是怎么克服这个弱点的呢？” 自卑吧，总是觉得人微言轻，不够重要，就是负责执行的那个。 并没有克服，只是认识到了……

老师在前一讲提到，架构师要找到商业价值、创建增量价值、最小化成本，这也是公司雇佣架构师的目的。但是，技术升级，从短期来说，是与这些相背离的，因为技术升级需要投入人力，要不暂停部分需求来分配些人力，要不新增人手，这些都是成本。而且技术升级出现问题再所难免，出现问题一旦影响到公司营收，甚至会影响到饭碗，特别是商业模式驱动且容错比较低的公司。从成本和稳定性上考虑，即使架构师想进行技术升级，也得有充足的影响力说服老板才行。 在互联网行业，员工在一家公司的就职时间也越来越短。架构师加入一家公司，除非目前的问题非常严重，不然首先要做的肯定不是技术升级，而是尽快做出业绩，或者说实现更多业务需求。所以这样也导致了，老的项目不在迫不得已的情况下，一般也不会大规模技术升级。 说到新的技术趋势，说实话，像Garter、throughworks这样的机构，给出的也只是一些参考。很多技术趋势，更多是昙花一现，像docker这样的技术，也是起起伏伏。真正的一个好的技术，能够解决疼点、提升效率、被广泛接受而不轻易被取代，都是多方面因素综合后的结果。像十多年前马云提出云计算，还被同台的李彦宏和马化腾说成新瓶装旧酒。这些可都是大佬，也会经常走眼。现在的技术层出不穷，迭代也快，作为一个技术人，只能不断关注本领域已经在大公司采用的技术，那些热门的概念，当当谈资简单了解就可以了。

我这里有个血淋淋的例子，源于自己太天真+没勇气。 曾经带过一个团队，团队中有一波兄弟在用十几年前的技术维护公司的现金流产品，而这个产品部署在几百家用户那里。 这个技术其实已经不行了，无论是我，还是团队Leader，还是团队成员，大家都意识到不能这样下去。我一直在逼着大家用新的技术栈重写老系统，但大家因为种种原因，技术没准备好，日常工作太忙了，系统太复杂，团队太分散，就是不动手。最后一次，我给团队Leader单独配了办公室，配了团队，寄希望他们能产生奇迹。最后还是失败了，一地鸡毛。 事后思考下来，问题最大的是我自己，太天真，不够果断，不够狠。当团队爬不起来的时候，另起炉灶会是更好的选择，而不是一心让团队成员暂时保住饭碗。彼此放过，早日破除这种技术诅咒，对大家都会是更好的选择。

总结： 三个人性上的弱点： 1. 自我麻痹，以繁忙的重复工作来代替深度思考； 2. 畏惧变化，以最小化改变来维持自己的心理安全感； 3. 路径依赖，以过去的成功经历来应对未来案例。 热度曲线看技术生命周期： 萌芽期 （Technology Trigger) ：指的是技术被公开，媒体热度陡然上升，还没有成型的产品和商业应用场景。 至捧期 （Peak of Inflated Expectations) ：指的是有了一些成功案例，当然也有失败案例，技术被吹捧到了极致。 低谷期（Trough of Disillusionment）：这个时候，热度回归到理性，失败案例被放大。如果产品不能让早期受众满意，那么技术就会在这个阶段消亡。 灵感期（Slope of Enlightment）：产品逐渐找准在行业的价值定位，二代三代产品出现，产品逐渐出现理智的商业用户和成功案例。 产出期（Plateau of Productivity）：在这个阶段产品被主流市场认可和采用。 衰老期（Progressive Aging）：以该技术为基础的产品，已经逐渐开始被下一代的新技术所替代，产品的市场范围和利润逐渐被蚕食。 退出期（Fade Out）：产品已经完全退出主流市场，仅仅在一些场景契合度与替换成本都非常高的情况下，还在被维护和使用。 个人思考： 我个人成长来说，舒适区是一个比较大的影响，我的做法不断折腾自己，把不断折腾变成新常态，写写博客，看看技术周报，做做技术分享。 云原生、低代码、响应式编程，我理解是处于产出期，几个云厂商都发布了自己的云原生白皮书报告。 低代码，在一些稳定、主流程不变、支持定制的场景下，用的比较多。 响应式编程，在性能要求很高的场景用的多，而且spring也有相应的技术栈来支持，spring reactive。 16年，还在用soap报文，现在还有些项目不适用spring boot controller，依赖自研反射来做控制器

看老师的课就是在训练我的大脑的过程～