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

2021-12-28 郭东白

《郭东白的架构课》

课程介绍



讲述：郭东白

时长22:59大小21.06M



你好，我是郭东白。今天我们来讲架构师的第四条生存法则，那就是尊重技术的生命周期。
人类的各种活动都要遵循事物的客观生命周期。不论是农业社会种田打渔，还是资本社会投资创业，行动太早或太晚，都会颗粒无收。技术也一样，也有自己的生命周期。而我们作为架构师，如果看不清技术的生命周期，那么所设计的架构就没法儿向更有生命力的新技术借力，自己的职业生涯也会受限。
那么我先来完整描述一下这条法则：在架构设计的过程中，架构师会有一个相对确定的商业和技术选择空间。在这个选择的空间内，架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期。这个时候，我们就需要看准技术趋势，选择已经有规模优势或者是即将有规模优势的技术，而不是选择接近衰老期的技术。
我们先来讲讲，为什么有的人能够看准一个技术的生命周期， 而有些人却做不到。找到了根因，也就知道自己该怎么改变了。
把握时机你有没有见过有的人年复一年辛苦劳作，却一无所成。而有些人似乎没怎么使劲儿，却能飞黄腾达。似乎大风总是吹向这个猪。你嫉妒地牙痒痒，心想，难道风就不能停下来，摔死这头猪？
你有没有想过，人家可能是会玩滑翔伞御风而行的猪啊！一个新的商业周期开始，就像是大风骤起，可以把一个看似不怎么努力的御风之人推向成功。事实上，如果从商业维度看，把握好周期远远要比努力工作更重要。
就像很多人职业不幸，是在五年前甚至是十年前犯下了致命错误。他们每天都在忙碌，来去匆匆，甚至都没有机会仰望星空。但就在恍惚之间，斗转星移，错过了一个大的商业和技术生命周期。结果是不论怎么努力，永远都慢这个时代半拍。
我也一样。我和身边许多做技术的同学，多数时间都在看小尺度的问题，日常工作和注意力都放在需求实现、领域建模、平台重构、中间件升级之上，因此我的思考也被这些工作所主导，很少去思考五年、十年，甚至二十年的技术趋势。我们不关注，当然也谈不上如何利用技术周期了。
技术的生命周期就像是潮水。潮来，汹涌澎湃，绵绵不绝。潮去，风平浪静，滩涂尽显。人一生的黄金岁月中也就是几个浪头而已。就过去 40 年而言，真正大的技术浪头有个人电脑、互联网、移动互联网、AI，差不多是每十年一个。你要在这种技术大浪潮之上玩好冲浪，就必须看清楚浪头，准确把握好技术方向和入场时机。如果错过，再等新的一个技术周期，几年的黄金岁月就浪费了。
所以在接下来两节课，我会给你讲讲怎么看清楚并利用好技术的生命周期。另外，我需要特别说明一下，我不认为自己真正看准过这些趋势。事实上，我也没能借到浪头的最大势。
我分析原因，是因为存在着三个人性上的弱点：
自我麻痹，以繁忙的重复工作来代替深度思考；
畏惧变化，以最小化改变来维持自己的心理安全感；
路径依赖，以过去的成功经历来应对未来案例。
我可能比大多数人幸运一点的地方在于，我很早意识到了自己有这些弱点，所以无时无刻都在提醒自己，去抗拒这些弱点。
那么接下来，我们先认真分析一下这三个弱点。只有克服了这些弱点，才有机会看清楚技术的生命周期，把握住新技术。
让我们放弃思考的三大弱点弱点一：自我麻痹自我麻痹是指我们用各种方法让自己放弃思考和探索的欲望。
其实大多数互联网从业者都是精英，从小到大都是学霸，内心不太能接受自己不思进取。但是人类进化出了一个自我保护机制，让我们不去天天担心风险。以至于我们常常会忽视自己现处环境的风险，导致我们不能全力探寻新的出路。于是我们会让自己每天都忙起来，用勤奋来弥补内心的不安。
团队和公司也是一样。尤其是一个营收压力特别大的公司，整个公司都忙着加班改代码，生怕老板看不到我们的勤奋。这个时候，没有人敢去挑战长期技术战略，也没有人关注新的颠覆性技术。
出现这种现象的根源，就在于高层管理者和软件架构师。有的管理者有意无意地把工作繁忙等同于有产出，于是让团队持续做毫无目标的布朗运动。其实麻痹自己越久，就越是难以突破。越没有突破，就越是没有去突破的勇气。这种恶性循环，让团队乃至整个部门，一年到头都没有实质性的进步。
我们只有承认和面对现在的风险，才有勇气放弃麻痹自己的行为，把部分注意力从当前技术放到更新、更有颠覆性的技术上去。而不是被动地等着他人告知自己下一步需求。
弱点二：畏惧改变在讲马斯洛模型的时候就提到了，心理安全感的需求导致我们会畏惧改变，这是我们与生俱来的本性。
举个实际工作中的例子。前段时间有位技术人员给我分享他稳定性治理的经验，他描述了如何通过一个独立的运维团队，把一组很烂的微服务运维到接近五个九。我很诧异，他们直到现在竟然还在使用独立于研发的运维团队，来保障公司核心系统的稳定性。
后来追问细节才知道，这家公司连续几任 CTO 都没做过互联网高可用架构。因为这个核心服务是公司营收路径上最重要的一环，所以连续几个 CTO 都不敢大兴土木，从根本上解决这个服务的稳定性问题，而是通过运维的方式先顶着。这一顶，就是 4 年多！
畏惧改变，让这个团队从 CTO 到架构师，再到一线主管，都丧失了稳定性治理的勇气。直到现在，这家公司还在沿用几年前自研的微服务框架，而没有引入当下常见的 Spring Framework，也没采用 Service Mesh。从头到尾都是一套年久失修的老系统， 离开的人越多，懂的人越少，就越没有人敢改动。现在，公司只能靠大量的全职运维团队来续命，以至于风险稍大的发布，还是要运维团队来做。
其实我们都一样，一旦赌注足够大，就会产生畏惧。我们率先放弃了改变的勇气，跟着就会放弃改变的欲望。得过且过，离新的技术趋势越来越远。
弱点三：路径依赖所谓路径依赖，就是你被过去的成功所蒙蔽了，以为过去的成功可以复刻。当过去的成功路径成了你唯一的选择，那么你也不会关注，更不会去探索新的路径了。
这就是我们儿时学习的守株待兔的故事。其实细想一下，守株待兔这件事再自然不过了。我们的大脑本来就是被不同事件训练出来的。哪天一个史诗级的训练样本发过来，正常人的神经元哪能扛得住？
还是举一个技术的案例。几年前有个同学转岗到我团队。他之前在一个大部门里做基础架构，曾经做过合并部署，就是把几个相关的微服务部署在同一台虚拟机，甚至是把几个微服务合并成一个巨石服务，然后部署在同一个 JVM 上。
这么做其实是个反模式，虽然会减少网络开销，提升性能，降低计算成本。但实质上，这个过程是用长期的运维和人力成本来替换机器成本。要知道，机器成本和网络带宽，在今天还基本符合摩尔定律。所以通过不断增加人力、维护和迁移成本，去替换每两年就减半的计算成本，这么做是不理智的。事实上，更大的成本是机会成本，这种巨石服务会增加升级改造的难度。也就是说，会让一个企业，很难快速响应新机会和新的竞争。
不过在他之前遇到的场景下，这样做的确可以带来实实在在的短期回报，所以他在之前的团队得到了很大的认可，也因此得到了晋升。同时，他也为自己的成就感到自豪。毕竟合并部署的技术难度非常大，因为越是调用量大的核心服务，代码往往越是年久失修、依赖复杂，jar 包冲突解决起来就越棘手。所以就像多少有点儿特长的技术人一样，他也是拿着锤子到处找钉子。只不过，他更像是拿着雷神之锤。
但我所在部门的 BU 的计算量，远远低于他之前的大部门，峰值流量还不到他们的百分之一。这么一来，虽然开发成本一点儿没少，但做合并部署的回报却远远小于他之前的工作场景。
而这个时候，Kubernetes 已经开始暂露头角。Kubernetes Pod 加 Docker Image 就已经可以非常完美地解决合并部署能解决的大多数问题了。但这位同学，因为有了之前的成功经验，根本没有去探索合并部署之外的解决路径。结果他的项目进行到一半，大家意识到 K8s 才是更合理的解决方案，所以他的项目也就草草收场了。
这就是路径依赖。如果我们被某个史诗级的训练样本冲击过，都会过度相信自己过去成功或失败的经验。这会让我们看不到其他的技术可能，更别说新的技术趋势了。
如何克服弱点去把握技术趋势？关于影响我们思考的三个人性弱点，到这里就讲完了。那么该怎么克服弱点，去把握技术趋势呢？
如何克服人性的弱点？先分享一下我的办法。仍然有必要重申的是，我并不觉得这些办法好在哪里，但有必要分享我在克服这些弱点上所做的努力，就算是抛砖引玉了。
首先，日常工作中我也经常会麻痹自己。不过我跳出这个状态的办法就是，每年会留出两次深度忏悔的时间。一次是在春节后，一次是在我生日之后，正好间隔半年左右。在这两个时间点，我会放下当前所有事情，回想过去半年是不是做错了什么，有没有获得什么本质上的能力提升。没有提升的话，我会很沮丧。不过我心比较大，过两天就又恢复正常了。
但是半年后，如果发现自己还是同样沮丧，那么我就会琢磨，是不是要逼迫自己找个更有压力、更能成长的事情和环境了。
这就到了第二点，克服内心的恐惧，迎接变化。这一点我天生要比很多人好。虽然在变化来临的那一刻还是会有很大的恐惧，但与此同时，我又无时无刻不在期待着变化。不止在工作中，生活中也是一样。随性的探索和意外的惊喜，总会带给我更大的乐趣。如果说我不恐惧变化，那完全是胡扯。但我会用对获取惊喜的期待，来压制内心的恐惧，这个办法对我一直很有效。
路径依赖最难破。我记性还不错，表达能力也比较强，而且我也经历过很多波折。但到了后来带团队时，就发现这些特性看起来是优点，其实会放大我的路径依赖。
比如面对一个相对来说经验没那么丰富，表达能力没那么强的同事。我能够及时召回重点案例或个人经历，然后把逻辑准确表述出来。这个时候，我会更容易说服周围同事，导致我的建议更占上风。
这个问题在我刚开始做 CTO 时变得非常严重。因为大多数参会者是我的下属或同事。他们可能不愿意反驳我，甚至哪怕是我错了，也不一定会纠正我。
我意识到这种情况之后，就开始刻意让自己更关注那些想法独特，或者是经常挑战我观点的人。比如下属反对我的话，如果我们各自的逻辑都很严谨，仅仅是假设有所不同。那么我表达观点之后，就会强迫我放弃自己的立场。
这么做，一来可以防止我有路径依赖，二来也是为了培养下属，让他们有足够的决策空间和犯错空间。这样一来，他们不犯错，我就有成长。他们犯了错，他们自己就有了成长。两全其美，何乐而不为？事实上，在这个过程中，我发现了非常多优秀的人才。我相信他们中间有很多人的思考和成就必然会超越我。
假设没有这些弱点阻碍你探索技术趋势，那么我们就可以试图通过热度曲线来比较客观地分析技术趋势了。
如何通过热度曲线看技术生命周期？如下图所示，是热度曲线（Gartner Hype Curve）。它是对新技术流行趋势的一个比较不错的建模。我们身边大多数技术的发展，其实都基本符合这个曲线。
如图所示，横轴是时间，竖轴是流行热度。发明者 Gartner 把一个技术的周期大致分为五个阶段，分别是：
萌芽期 （Technology Trigger) ：指的是技术被公开，媒体热度陡然上升，还没有成型的产品和商业应用场景。
至捧期 （Peak of Inflated Expectations) ：指的是有了一些成功案例，当然也有失败案例，技术被吹捧到了极致。
低谷期（Trough of Disillusionment）：这个时候，热度回归到理性，失败案例被放大。如果产品不能让早期受众满意，那么技术就会在这个阶段消亡。
灵感期（Slope of Enlightment）：产品逐渐找准在行业的价值定位，二代三代产品出现，产品逐渐出现理智的商业用户和成功案例。
产出期（Plateau of Productivity）：在这个阶段产品被主流市场认可和采用。
其实我们身边大多数的技术，都活不到产出期。其实能活到至捧期的技术，也寥寥无几。Docker 是一个非常符合 Gartner 曲线的经典案例。你要是有兴趣，可以读一下 Docker 从发家到膨胀，再到被群起打压，最后到一个相对稳定的定位的过程。这对你理解热度曲线会有极大的裨益。
其实 Gartner 的热度曲线不完全是原创。法国著名社会学家 Gabriel Tarde 最先描述了创新传播的渗透过程，也就是S-Curve。它的竖轴是“prevalence”，指一个创新的渗透程度。就像马斯洛的理论一样，Gabriel Tarde 的 S-Curve 理论同样也是一个基本的理论，可以用来解释很多与创新相关的现象的传播，包括现代企业的生命周期。未来课程里，我们还会再次深入讨论这条曲线。
不过不论是 S-Curve 还是 Hype Curve，它们都有一些缺陷，那就是没有对竞争技术的干扰做建模，所以这两条曲线都没有描述创新的衰老期。可以说，在产出期之后，技术还有两个状态：
衰老期（Progressive Aging）：以该技术为基础的产品，已经逐渐开始被下一代的新技术所替代，产品的市场范围和利润逐渐被蚕食。
退出期（Fade Out）：产品已经完全退出主流市场，仅仅在一些场景契合度与替换成本都非常高的情况下，还在被维护和使用。
那么我们从这两条曲线的描述中能得到什么结论呢？
结论就是：所有的技术都像人类的生命一样，也有终结的一天。这是个自然规律。
怎么从架构师的角度理解这句话呢？一个老去的技术就让他老去，快死的架构不值得投入人力和时间去维护，更不用说去翻修或者是复用了。
我们在前面在讲马斯洛模型的时候就提到过，围绕一个旧架构体系的人的利益，已经和这个架构深度绑定，这就导致这个架构就像一个生命体一样，已经有自己非常强大的力量去延续它的生命。
举个例子。某个大厂，几年间连续三次搭建国际化底层架构。每一次都彻彻底底地失败了。而且每次失败，都跟旧的架构体系有关。
搭建国际化体系的方法有两种。一种是改造国内的系统，也就是我们常说的国内技术出海；另一种是重新构建一套系统。
大厂的架构本来已经非常老化了，处于技术生命周期的衰老期。甚至第一次出海的时候还是巨石架构，核心服务一周只能发布两次。最多的时候有同学发布几十遍都不成功。而发布不成功再等一周的情况也非常常见。
但这还不是核心问题，全球像中国这么大的单一市场就只有美国，而大多数国内企业也出海的第一站又不是美国。那么把全球第一大单一市场的技术架构，搬到一个百万或者千万人口的国家来运营，就一下子水土不服了。
如果从交易体量来算，哪怕是最大的国家，也不到中国的百分之一。百分之一是什么概念呢？你可以换算一下，这个基本上等于在你们家里修了一个有 20 个蹲位的公共卫生间。哪怕你家有那个面积，但你能维护得过来吗？
虽然大厂里也有反对的声音，但每次反对的声音都被压制了。因为大家不是不知道自己的系统不合适出海，而是谁都想从这个饕餮大餐里分一杯羹。哪怕自己的技术再老，那也要老当益壮，为公司捐躯。
我曾经反复思考过，怎样才能避免让一个老的技术和架构侵入到新的体系里来？硅谷达人 Guy Kawasaki 曾总结苹果公司 Macintosh 的成功，他认为关键就在于“低调加物理隔离”。我觉得这也应该是这个问题的答案。那就是把这种新的项目和公司其他部门分割开来。参与的人少一些，时间给宽裕一些，尽量远离公司的核心业务和人群。
我们也可以运用之前在尊重人性这个法则里提到的用户思维，来引导团队放弃一个衰老的技术。因为曾经再伟大的技术，在用户的面前都是渺小的。为了更好的用户体验，一切都值得推倒重来。
你可能会说，我们今天讲顺应技术的自然周期，老去的就让它老去。这个观点似乎太悲观了，难道我们就不能抓住一个技术萌芽和发展的机会吗？下节课，我们就来讨论一下这个问题。
小结这节课我分享了自己如何克服弱点，来提升追逐新技术周期的能力和勇气。其中我特别想强调的是，当你把自己的思考尺度从三五个月扩大到五年或十年，那么这件事情的价值必然会很大。这个放大思考尺度的动作，会让你用不一样的视角来看待技术。
看一次看不懂，看两次看不懂，但是看多了，自然会看出门道来。从本质上讲，这是个算法训练的过程。当你老用一个小尺度的样本来训练自己的大脑，那么你的大脑就是一个非常优秀的小尺度决策机。但当你坚持用大尺度的样本来训练自己的大脑，那么你在大尺度问题上的决策质量，也必然会得到提升。
在这节课，我还介绍了 Gartner 的热度曲线所表达的新技术生命周期，以及热度曲线中缺少的衰老期和退出期。了解一个技术生命周期的最核心目的，就在于利用这个周期为我们的架构活动创造出最大的价值。
作为一个架构师，知天道不够，还是要顺天道，也就是说我们的架构要符合技术的自然周期。反之，为一个落后的架构注入新生就是不符合天道了。而想要抗拒这种行为，我们就要从用户思维出发。为了更好的用户体验，要舍得放弃任何曾经伟大过的技术。
思考题三个作业，任选一个：
除了我分享的三个弱点外，你觉得还有其他弱点会影响我们看更大尺度上的规律吗？你是怎么克服这个弱点的呢？
你是如何看待当下比较流行热词呢，比如云原生、低代码、响应式编程、元宇宙，你怎么看这些技术的趋势？
你或者你周围人，有没有还在维护那些已经在业界垂死的技术？你认为其中的根因是什么呢？
如果今天这节课对你有帮助，欢迎你点击课程右上角的分享并赚钱按钮，把课程转发给你的同事或朋友，大家一起交流、进步。我们下节课再见！

分享给需要的人，Ta订阅后你可得20元现金奖励

生成海报并分享

赞 7

提建议

08｜法则三：架构师如何在一定时间内最大化自己的增量价值？

10｜法则四：架构设计中怎么判断和利用技术趋势？

 写留言

精选留言(21)

大土豆
2021-12-28
做了7年的Android原生开发，到现在为止整个行业基本雪崩。雪崩的开始就是不论出海国外还是国内，老板们意识到无论砸多少钱，再也出不来一个微信和抖音了，现在都不玩了，App就大厂在做，中小厂不做了，血淋淋地见证了一个技术兴起到衰落期。。。
作者回复: “血淋淋地”。。。
共 4 条评论
7
Helios
2021-12-29
自我麻痹、畏惧改变、路径依赖。看到老师分享这三个弱点，让我想起我自己，上学的时候吃到学习好就能收到尊重的甜头，到了大学还是这样就知道学习，但是这个学习是自我麻痹的，不想做出改变去挑战其他的，比如参加团体活动、社团什么的。

现在毕业三年多了，还是坚持“学习”就算工作中遇不到也学……这还是用战术上的勤奋代替战略上的懒惰，因为在我的思维中没有其他可选项了。

老师能不能分享怎么做的半年总结，有啥思路框架能分析不
展开
作者回复: 没有特别的框架，主要是总结自己半年的得与失。失除了当前的位置上做得不好的地方，也会思考自己错过的机会。
2
GAC·DU
2021-12-28
这两年一直在从事云原生工作并相爱相杀，以k8s为代表的云原生及其周边项目团灭了docker，目前k8s+istio很强大，几乎解决了传统项目无法解决的问题。
2
乐天
2021-12-31
老师在前一讲提到，架构师要找到商业价值、创建增量价值、最小化成本，这也是公司雇佣架构师的目的。但是，技术升级，从短期来说，是与这些相背离的，因为技术升级需要投入人力，要不暂停部分需求来分配些人力，要不新增人手，这些都是成本。而且技术升级出现问题再所难免，出现问题一旦影响到公司营收，甚至会影响到饭碗，特别是商业模式驱动且容错比较低的公司。从成本和稳定性上考虑，即使架构师想进行技术升级，也得有充足的影响力说服老板才行。
在互联网行业，员工在一家公司的就职时间也越来越短。架构师加入一家公司，除非目前的问题非常严重，不然首先要做的肯定不是技术升级，而是尽快做出业绩，或者说实现更多业务需求。所以这样也导致了，老的项目不在迫不得已的情况下，一般也不会大规模技术升级。
说到新的技术趋势，说实话，像Garter、throughworks这样的机构，给出的也只是一些参考。很多技术趋势，更多是昙花一现，像docker这样的技术，也是起起伏伏。真正的一个好的技术，能够解决疼点、提升效率、被广泛接受而不轻易被取代，都是多方面因素综合后的结果。像十多年前马云提出云计算，还被同台的李彦宏和马化腾说成新瓶装旧酒。这些可都是大佬，也会经常走眼。现在的技术层出不穷，迭代也快，作为一个技术人，只能不断关注本领域已经在大公司采用的技术，那些热门的概念，当当谈资简单了解就可以了。
展开
作者回复: 谢谢分享
1
Helios
2021-12-29
人总会高估一年的变化，低估五年的价值。
作者回复: 是的
1
SMTCode
2021-12-29
看老师的课就是在训练我的大脑的过程～
作者回复: 哈哈，越练越聪明
1
刘大明
2021-12-29
感谢老师的分享。
回答一下第三题。目前在一个财务软件公司维护一个老旧的巨石项目。
我分析原因有下面几点
1.由于该项目属于公司发家系统，产品也是在当时的技术水平和环境下诞生的，所以技术相对落后，而且对于财务来说系统稳定远比技术先进更有用。
2.推翻老产品，用新的技术架构重写一套的成本可以说是非常巨大的，而且还包括客户的培训成本。所以只能按照老师说的，开发新的产品做业务隔离，当新的产品卖，但是新的产品投入产出比远远小于老系统带来的收益，这样对于公司层面肯定是不愿意的。
最后想问下老师，对于我这种维护老系统的开发人员来说，应该怎么做才能走出这种困境呢？
展开
作者回复: 做周边的应用会好一点吗？尤其是数据分析应用？
共 2 条评论
1
Helios
2021-12-29
“除了我分享的三个弱点外，你觉得还有其他弱点会影响我们看更大尺度上的规律吗？你是怎么克服这个弱点的呢？”

自卑吧，总是觉得人微言轻，不够重要，就是负责执行的那个。
并没有克服，只是认识到了……
展开
作者回复: 谢谢分享啊！很真挚。可以先给信的过的朋友讲讲想法。聊一聊。慢慢的会好一些。也可以匿名发点儿帖子啥的。。。
1
肖春
2021-12-28
做事情爱拖延，时刻提醒自己快点完成
1
Vicente
2021-12-28
我来做一下第三题作业，比如说现在还有不少银行或者保险行业在使用大型机，使用陈旧的 AS400/RPG 做需求开发，一些使用了几十年的系统，已经没有人清楚里面到底有多少东西，想做升级改造，除了畏惧风险害怕改变之外，一方面是成本过高，另一方面也是没有什么好的解决方案，当然利益群体众多难以协调也是一个很大的原因，这些都是客观存在的问题。
展开
作者回复: 谢谢分享
共 2 条评论
1
Geek_fd0943
2022-01-02
这个问题的有两大关键。
第一个就像KK说的，技术自有其生命力，该出现的总会自我拼凑，无可抗拒，所以拉里·佩奇说，谷歌做的业务，如果我们能看得到数学上的极限的，我们往往做得非常好，没有对手。长期看技术不会无限迭代，边际收益总会趋零。从gartner统计看全局，现在不太是这样的时刻。 AI，光子计算，神经芯片，存储池计算，无限状态模型的分发需求等足以支持一段长长的需求和解决方案的爆发式演进。对技术价值潜力、采用成本保持清楚判断，或者说数学层面的第一性的判断，是好品味的前提。

第二个技术的发挥受限人的因素。人的欲望和能力和性格、物质条件、已有知识结构都有很大的关系。（统计看人的创造力与年龄无关，参考万维钢的调研）。但是产出的个体差异很大而且是变动的。孙子兵势篇指出这个问题的关键是要把最能干的排头兵选出来，选和不选，战斗力差10倍。曼哈顿项目有了奥本海默，这个天下最困难的项目就被最坚定高效地推进了。
展开
coding
2022-01-02
1.技术生命周期
2.团队的发现想法多，有潜力的成员
术子米德
2022-01-01
🤔☕️🤔☕️🤔
* 📖：技术有自己的生命周期，作为架构师，如果设计的新架构，没有借力自新技术，自己的职业生涯会受限
    * 🤔：我先跳出架构师的视角，仅仅从一个人技术人的视角，我看到所谓最新的主流技术消息，普遍来自大家所谓的大厂。所以就会有种错觉，感觉这些大厂的技术文章就是主流技术，甚至会滋生误解，以为那就是要引入的新技术。可是，这里有一个关键点要拎出来单独拷问，那就是大厂们的新技术，它是面临什么困局，解决什么问题，这些技术不是空想出来，更不是无中生有。当我把这些技术判定为主流新技术时，是否忽视了我面了的困局，是否忘记自己要解决的问题，跟这些新冒出的技术所解决的问题之间的交集有多大。为何我有这样的想法？因为我曾经因此而犯过奇怪的错误。我写的代码跑在嵌入式设备里，可是我却曾经死命想把所谓的高并发整进我的设计方案。现在想来如此可笑。一台设备谈什么高并发，反而更要关注，相同功能的软件实现，会运行在不同架构的处理器之上，更大的约束来自内存，那种被约束到无法多缓存半帧数据的境地。也就是说，我的困局是架构体系的多样性，运行时资源的受限性。我得解决在这样的约束下，相同的代码在各处都能跑出一致的行为，在无法转身的运行时环境里，如何能够在问题出现时依然具备可诊断性。所以说，对我而言，既要关注新技术，更要抓住自己面临的困局和问题，把最合适的技术，在最恰当的时候引入，也是让自己的职业生涯更扎实的方式。
* 📖：架构设计的过程，总是在一个相对确定的商业和技术空间内。架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期
    * 🤔：趋势在变，但是趋势变化本身，有一定的规律，至少从历史经验总结出如此规律。而真正不变的，就是变化本身，包括任何的规律都有意外，这本身也是不变的规律。
    * 🤔：作为在变化潮流里的技术人，想办法认识清楚哪些技术是相对稳定的技术，哪些技术是相对前沿的技术，得有自己的认识框架和判断方法。就像贝佐斯说的以当下为定点，过去10年不变的事物，那么接下去10年不变的概率，它会明显高于一直在变化的事物。我们要找出过去10年相对稳定的技术，掌握这些技术能解决哪些问题，技术的原理是什么。这样可以让自己有信心和底气，会有技术的基本盘。当然这样的技术相对比较成熟，所以只期望有个基准收入，让生存不会是问题。
    * 🤔：哪些技术突破，会带来哪些问题被解决，这是判断技术价值的重要依据。也就是说，技术必须是要拿来解决问题，而且随着技术的突破或演进，某类问题被解决的窗口期也会打开。这类问题本身的价值，就预示着技术能在这个问题域里挖出多少矿。越是满足人类底层问题，越是满足人类本能问题，越是无尽的矿区。典型如人类对通讯便利的本能性需求，只要有技术突破能解决此方面的问题，该技术就是挖矿铲子。
* 📖：放弃思考的三大弱点：自我麻痹、畏惧变化、路径依赖；每年留出时机，让自己深度忏悔
    * 🤔：这三方面不都是因为，人类当下的能耗，低于新变化后的能耗，所以本能就选择当下的低能耗方案嘛。任何变化，要么是逼不得已，不变就面临游戏结束的局面，要么就会出现潜在的高能耗而被本能性躲避。所以主动思考，就是一项逆本能的行为，如何能够说服自己，越过一次高能耗后，跨越到未来潜在的高收益。
    * 🤔：每年的忏悔时间，想必这是极度痛苦的心理过程。我从来没有这么做过。不过我约莫着，如果平时尽量把做决策的思考写下来，到忏悔阶段，就有当时如何想的记录，尤其是当时为何这么决策的思考，过段时间看必定更加值得再思考。
展开
1
王建设
2021-12-31
我尝试回答“弱点”这个，人性就是好逸恶劳，短视的，我认为这就是弱点之树。其实也就是老师说的“大尺度思考”这个方面，用比较流行的话，就是“长期主义”，一切基于长期思考，大尺度的思考，就会解决麻木，恐惧和路径依赖。

架构师很重要的一点就是全局思维，全局就是包括广度和深度。套用老师的那个“合并部署”的例子，如果用短视来思考，提高一时效率的，但是如果用大尺度，长期视角才思考，确是“反模式”。

真正的心理安全感，如果拉大尺度来看，更应该是拥抱变化，而不是畏惧变化。

写到这里，克服自身弱点，我想到还有“两心”：
1. 呵护好自己的好奇心，他会推动你打开更多的视野
2. 战略意图的雄心壮志，它让你不满足现状，不满足那一年半载的安全感。

志存高远，也要脚踏实地，日常我认为：
1. 冥想和反思
2. 多读历史
3. 思辨思考和逻辑训练，也就是老师说的思考力。
展开
作者回复: 赞！
1
无心水
2021-12-31
总结：

三个人性上的弱点：
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，依赖自研反射来做控制器
展开
作者回复: 非常赞！
qinsi
2021-12-30
要创造商业价值的话技术也只是其中一个手段。任天堂的横井军平曾提出“成熟技术的横向思考”（枯れた技術の水平思考），不追求最尖端的技术，而是通过使用成熟甚至是接近淘汰的技术，在该技术原本适用的领域之外创造商业价值。
作者回复: “在该技术原本适用的领域之外” 这个是个非常重要的修饰词。想想看挺难的。
共 2 条评论
neohope
2021-12-30
我这里有个血淋淋的例子，源于自己太天真+没勇气。
曾经带过一个团队，团队中有一波兄弟在用十几年前的技术维护公司的现金流产品，而这个产品部署在几百家用户那里。
这个技术其实已经不行了，无论是我，还是团队Leader，还是团队成员，大家都意识到不能这样下去。我一直在逼着大家用新的技术栈重写老系统，但大家因为种种原因，技术没准备好，日常工作太忙了，系统太复杂，团队太分散，就是不动手。最后一次，我给团队Leader单独配了办公室，配了团队，寄希望他们能产生奇迹。最后还是失败了，一地鸡毛。
事后思考下来，问题最大的是我自己，太天真，不够果断，不够狠。当团队爬不起来的时候，另起炉灶会是更好的选择，而不是一心让团队成员暂时保住饭碗。彼此放过，早日破除这种技术诅咒，对大家都会是更好的选择。
展开
作者回复: 感谢这么真诚的分享！
HackMSF
2021-12-29
阿白老师快更新啊
作者回复: 嗯，我抓紧
Johar
2021-12-29
准备三小时，学习三分钟;学习效率低，容易被打断。
作者回复: 现在的消息APP还是比较伤害思考的，我一般关掉
罗均 - Jun
2021-12-28
非常感谢老师的课程，特别是分享老师每年至少两次的忏悔，真是学生学习的榜样。

关于第二道思考题，达摩祖师禅语“不变随缘，随缘不变”。弟子年轻时是个学渣，基础非常差，天资又愚钝，在千变万化的技术潮流中，想追都追不上。因此只能去寻找那些恒久不变的知识，不断努力补习，例如我们老祖宗的儒释道理论。技术方面，感觉无论是什么新概念，在实现上都无法离开主要基于C开发的OS，以及最基本的数据结构，因此无论是什么新概念，学生觉得都要了解，都要尽可能做demo并尽可能地思考是否可以给公司及客户带来利益，然而这些都相当于枝叶，更应该关注的是生命力更长的基础技术，例如c的各种新玩法，c++20，Linux新组件等，这是根，不能本末倒置一味追求热点技术。

另外，非常赞同老师关于放大思考尺度时间周期的观点。契合老祖宗的思想，例如孔子说“有朋自远方来，不亦说乎。”这个远方，应该是指时间的远方，在遥远的未来，不断有人学习、赞叹和崇拜孔子的学说，这才是圣人喜悦的地方。
展开
作者回复: “恒久不变的知识” 赞！
共 5 条评论

