你好，我是郭东白。上节课我们讲了目标在架构规划中的重要性，也明确了目标缺失的两大根因。那么这节课，我们就来聊聊该如何寻找正确的架构目标，以及如果目标制定错误，该如何挽回。
如何寻找正确的架构目标？
主要分为三种情况，我们来分别讨论。
确认一个正确目标，且要试图逼近它
一般来说，我们相信达尔文的进化论是普遍适用的，那么企业的所有活动都应该指向一个终极目标：它们要能够为企业带来长期的生存优势。架构活动作为企业活动的一种，自然也逃不出这个终极目标的五指山。
但这个终极目标太难验证了。怎么知道我们的架构设计会对公司产生什么深远的影响呢？我不就是设计一个50人日的评价体系或流量归因的服务吗？不至于还要在架构设计文档里评估对企业的生存优势吧？再说了，就算我想做，也不知道怎么评估啊！
你肯定会有这么一连串的疑问，而标准答案是什么，其实我也不知道。不过在做架构设计之前，我永远都会问自己这样一个问题：这个架构规划为什么可以给企业带来生存优势？
对这个问题的回答，其实渗透了你对几个价值创造维度的理解，包括：促进企业规模化；加速企业模式探索；提高企业效率；提升用户体验的理解。当然，最理想的情况下，你还应该把一系列可以量化的指标作为架构方案的预期产出。然后你就可以用评分卡的方式，对架构方案有个全局的产出度量。
当然，在现实项目中，这些产出很难量化到业务指标上，尤其是由技术主导的项目中，比如说数据模型标准化、网关统一、框架升级，那就更难了。那么对这个项目必要性的论证，就需要有更直接的量化工具。
就像我作为一个CTO去赞助一个项目，我一般期望项目在半年内的回报要大于投入。也就是说，你投入100人日做一个技术项目，那你半年内就要省出100个人日来。除非有其他的动力因素存在，比如说审计、合规、安全等，否则我就不做该项目的赞助人（Sponsor）。
显然，未来充满不确定性，终极目标很难验证，但通过反复问自己这个问题，我们就可以不断逼近这个唯一且正确的架构目标。正如人生意义这种终极问题一样，很多哲学家也没法给出一个确定的答案，但正是对问题的讨论，让我们一直保持在逼近真理的路上。
如果你稍稍留心就会发现，很少有人会在架构设计中问自己这个问题，而这恰恰就是架构设计的万恶之源。
事实上，在中国的互联网行业，架构师往往不是在两个最大化生存优势的选项中做选择。更多时候，是在一个不能带来太多优势和一个甚至会带来劣势的、画蛇添足的方案中做选择。
为什么我特别强调中国的互联网行业呢？因为在过去十年，中国的互联网公司有着比全球任何国家更多的资金和人才供给，甚至是供大于需的。我们有千团大战、共享经济大战、新零售大战、社区团购大战，几乎每个流行热词背后都是不惜一切代价的资金和人才投入。
在这种背景之下，许多架构设计都是以饱和攻击的方式全方位最大化投入的。或许参战各方都在想，先用尽一切手段活到明天再说。
但当我们去研究各个大战的最后胜出者时会发现，他们都不是靠全程饱和攻击取胜的，而是靠对阶段性精确目标的最大化投入从而在惨烈竞争中胜出的。架构其实也一模一样。
那么你作为一个架构师，怎么判断一个目标是不是正确的呢？我的建议如下：
- 首先，要用企业的战略意图去鉴定架构活动目标的正确性。
- 接着，如果目标与战略意图不匹配，那么你要试图影响甚至是改变这个目标。你可以与架构项目的发起人反复沟通，陈述你的理由，建议他去寻找另一个更接近战略意图的目标。
- 如果目标与战略意图匹配，那你要看看是否存在一个更合理的目标，可以让企业能够更快地逼近战略意图。
如果你能保持这么做，哪怕你不知道终极目标，但是你已经在不断逼近了。而且能做到这一点，你就已经超越大多数架构师了。因为你不断检验目标的过程，也是你判断力不断提升的过程。
不过这里还有两个关键问题。第一，什么才叫匹配呢？我应该用什么样的一个标准来衡量匹配度呢？
我认为所谓的一个架构活动目标和企业战略意图相匹配，指的是架构活动对一组KPI的贡献，需要与对表达企业战略意图的KPI形成增强关系。简单来说，就是你的KPI对战略意图是有正向贡献的。
举个例子，大多数公司的战略里都对“客户第一”有着某种形式的表达。假设你的架构活动有一个作用是提升性能，比如说减少用户交互过程中的延迟和等待。那么你的架构活动在这一点上，对战略意图的贡献就是正向的。反过来，假设你的架构活动需要用户做强制性的安全身份验证，那么用户的正常体验就会被打断，这个时候，你的架构活动对战略意图的贡献就是负向的。
第二，如果发现目标不正确，那该怎么办呢？
一般来说，一个架构活动的发起如果有比较充分的理由和论证，那么架构活动的目标往往就会是正确的。但你肯定会遇到目标不正确的架构活动，这个时候，你作为一个架构师就要有义务指出来。
然而很多架构师在这时是畏缩的，因为在一个架构活动中，架构师的角色往往要低于项目赞助者和技术资源提供方的角色。甚至对你而言，好不容易拿到了这个机会，哪怕方向错了也要硬着头皮冲上去。
在这种情况下，我期望你有良知，同时也要有勇气阻止企业犯错。我自己曾经因为三次阻止一个顶级项目，而在职业发展上受到了不小的伤害。但也正是因为我这样做了，使得我能够从容地面对自己的良心。更为重要的是，之后事实证明我的判断是对的，这让我自己的决策自信心得到了大幅的提升。
这， 也就是决策自信心，才是一个架构师从架构活动中获得的最宝贵的礼物：在多个比你资深，并且比你权力更大的人面前，你坚持了不同于他人的正确判断。
当然，多数时候不是对与错的判断，而是判断架构目标是不是最优。那么在这种情况下，你作为一个架构师该如何影响架构目标呢？我们接下来就从技术和业务两个维度来分析。
关于技术驱动的目标
技术人员往往缺少全局视角。在这种情形下，你可以通过引导的方式，帮他找到一个更好的方案，让他从战略角度去思考一个架构方案对公司的终极价值。 最终，找到能够最大化公司长期价值，并且成本合理可控的方案。
就拿上节课讲的在公司引入新技术方案的情形来说。在公司引入新技术，我们也提到了虽然这么做有个人利益驱动的缘由，不过绝大多数研发人员还是有着非常积极正面的出发点的。所以在处理这些方案时，你首先做的不是全盘否定，而是站在他的视角，看到、并理解他的出发点的正确部分是什么。
接着，在彻底理解新方案的价值之后，你就可以比较客观地思考这么六个问题：
- 新方案的实现成本有多少？
- 新方案上线后带来的短期价值有多大？
- 这个新方案是否可以全面替代现有方案？
- 全面替代的实施成本有多少？
- 全面替代之后，这个新方案带来的长期价值是什么？
- 如果不能全面替代，而是两套方案并存，那么增量的维护成本有多大？
事实上，大多数人在看一个新方案时，只是思考了前两个问题，然后就匆忙做了判断。要知道，这完全不能让建议者看到他的方案对全局的影响。
毕竟许多方案根本不具备全面替代性，或者全面替代的实施成本太大，根本无法完成。一旦新方案被通过，虽然能暂时提升局部的效率，而从长远来看，仍会损失整体架构的合理性。
但如果拿出的方案可以完整回答上述六个问题，那就值得你去做长期规划并认真投入了。就拿我们在上节课提到的引入Pulsar的案例来说，要在公司内全面替代Kafka的成本巨大，短期内的回报完全不合理，所以提出这个方案的同学最后也觉得不合适。
除此之外，在实际工作中，我们更需要考虑的问题是：对于不具备长期价值的项目，我们该怎么拒绝，并且还不伤害建议者的积极性。
后四个问题这时就又要发挥作用了。你可以引导建议者去思考这些替代和实施的成本，也可以帮助他去寻找这些问题的最优答案，让他理解你作出决策的出发点和正确性。
你甚至可以把最困难的事情交给他，比如说让他去负责调研全面替代的成本。这样他才能从你的视角看到问题，从而得出和你相同的判断。这样一来，不仅他的判断力可以得到成长，你也能多一个帮手，而不是对立者。
所以你看，哪怕我们作出了正确的决策，但考虑到人才的成长和团队的稳定性，在执行过程中也要关注研发同学的心理感受。顺便说一句，这个案例也同样适用于调和局部架构和全局架构的冲突。
总结一下，通过这个案例我更想强调的是：关于架构目标的决策，对于一个人或一个团队的影响是巨大的。所以当你有了一个正确的关于架构目标的决策，要知道这只是一个起点。你还要认真思考这个决策的实施路径，让大家团结在正确的架构目标上，而不是你自己一个人举着架构目标，变成孤家寡人。
关于业务项目的目标
现在我们谈另外一种情况，业务目标太多或者是不明确，从而导致架构活动目标缺失的话，你该怎么办？
作为架构师，在业务目标的确定上我们往往没有最终话语权。那么这个时候，我们面临的问题就变成了：在没有权利改变业务目标的情况下，该怎么做才能最大化公司的生存呢？
我们先看一个比较棘手的案例，假设碰到上节课讲的业务方大搞运动的情形，作为架构师你该怎么办呢？
这里我们要引入两个概念：决策者和取舍权。决策权决定要什么，取舍权决定保留什么。一个决策者，必须要行使自己的取舍权，在自己的决策领域内做取舍。
那种天天叫嚷着既要、也要、还要的人，其实就是不知道客户要什么。他们行使了自己的决策权，做了全部都要的决定。但也放弃了自己的取舍权，用全方位搜索来代替自己的思考无能。做技术管理、做产品、做业务，都一样，我们必须要有且仅有一个明确的目标。
这里我要强调一下，我们不是说一个项目不能同时优化多于一个KPI。但如果这么做，你必须要给出权重。比如说做电商可以同时优化GMV和成交客户的满意度，那么决策者就需要在这两个目标之间给出一个权重，做联合的多目标优化。这么做的本质，其实是把两个KPI合成一个，最大化高满意度的GMV。这个时候，其实你还是只有一个明确的目标。
事实上，取舍权是一个决策者最重要的权限，这个权力决定了别人说是既要、也要、还要的目标，到底哪个必须要，哪个可以暂先舍弃。
很不幸的是，这个权限却经常被不明不白地下放了。原因就在于决策者不是在目标上做取舍，而是选择向团队做无度的索求，制定一个又一个目标。然而无度的索求是不可能被完全满足的，这就导致取舍权被分散给了执行者。
举例来说，假设决策者要求在三天之内上线一个新的商业模式。在这种情况下，团队肯定会给你上线一个模式，但究竟是不是你想象中的商业模式，那很难说。至于稳定性就不用提了，因为决策者完全没有给团队留出做稳定变更的可能。
我特别要强调一下，这里所说的决策者不一定是顶层管理者，而是任何一个层级上能做决策的人。这意味着在你的决策范围内，如果你不做取舍，那么就只能让别人来替你做取舍。
很显然，在充分竞争环境下胜出的公司，几乎没有任何一个是通过大范围的搜索商业模式去寻找增长的。战术上的勤劳永远都没办法补救战略上的错误。这里面有非常多的经典商业案例：比如柯达、DEC、Sun Microsystems，都是非常典型的由于战略错误导致公司最终被淘汰的例子。
很遗憾，放弃决策权的事情在一个企业内可以说是每时每刻都在发生。那么我们能做的是什么呢？
至少有四件事情你可以做，注意，这是一个Fail-over的过程。
首先，想办法反馈这个情形，耐心解释给当初的决策者，请他来做取舍。这个本来应该是第一步也应该是唯一的一步。但是就像隔壁老王说的：“你永远也叫不醒装睡的人”。所以这个办法往往不管用。
其次，你自己做个取舍优先级，想办法通知到决策者。你可以用评分卡模型对项目的优先级做个判断。如果你自己不确定，也可以邀请资深的同学给项目打分，但是注意要排除掉与他利益密切相关的项目。通过这种方式，你应该能做出相对正确的取舍了。另外我想强调一下，通知是个非常有挑战的事情，我就见到过坚决不接受取舍的CEO。但哪怕是这样的CEO，他一般也会接受你给出的上线顺序。
接下来是，如果上面的方法还是不管用怎么办？这个时候你可以尝试自己拿下取舍权。你需要清晰表达你取舍背后的思考逻辑，并邀请相关的利益方参与辩论。如果他们的输入合理，那么你可以调整取舍。如果输入不合理，那么你可以选择拒绝他们的要求。
当然这么做有个前提条件，就是你与真正的决策者之间有足够信任，并且你也足够资深。如果不是的话，那你这么做可能会受到惩罚，尤其是在最终业务结果不理想的情况下。
最后，也是最常出现的情况，是你上述这些努力都失败了。这个时候，你可以通过技术手段来做延迟或者是隔离决策。这个办法对业务目标不明确的场景也同样适用。
比如你可以采用类似设计模式中的策略模式，把一个或多个业务尝试隔离在策略实现中。每次业务尝试对主流程不产生影响，每个尝试逻辑都封装在单个策略中。这样一来，业务尝试失败后，你可以迅速下线策略，而主流程的架构则可以保持整洁。这是一个最小化爆炸半径的方案。
如果目标太过超前怎么办？
最后还想举一个比较极端的情形，那就是企业有一个非常明确的目标，并且与公司的战略意图相匹配。但对于企业现下的发展状况而言，目标太过超前，无法实现。
这种情况下，说明公司对一个领域的技术价值的判断是正确的，如果能够实现出来，必然会给企业带来巨大的生存优势。但这也意味着企业将会面临巨大的挑战。那么我们作为架构师该怎么办呢？
举个我自己的例子。2010年我在微软美国参与了一个医疗领域的大数据智能产品的开发工作。技术方案的提出是基于这样一个想法：大量语义化的、实时的、来自不同部门的医疗图像和文本数据，在同一个地方实时聚合之后，将帮助科研人员和管理者发现之前被忽视的创新和提效机会。事实上，这个论断是成立的，而且被证实有成功案例，但当时的产品和技术架构却是失败的，后来被卖给了GE，多年后又卖给了另外一家公司。
你可能想说，你是不是在劝我遇到这种情况应该放弃呢？其实我不是这个意思。如果你喜欢研究初创企业的成功故事，你会发现很多企业就是在这种战略意图和自身能力极不匹配的情形下一点一点成长起来的。
就像这个情形，其实当时公司的战略路径完全正确，那么哪怕烧钱慢一些，最初的团队也完全可以坚持到现在。如果真的坚持到现在，公司使用的关键技术，大数据、人工智能、实时处理等，都已经非常成熟。这十几年的行业积累，肯定也会带来非常大的竞争优势。
所以在这种情况下，你可能改变世界，也有可能一败涂地。我没办法给你一个坚持还是放弃（to be or not to be）的建议。如果你相信这家公司的使命，那就坚持下去。如果不相信，也可以毅然决然地离开。
在最后提到的医疗项目，它对我的架构决策还产生了另一个重要的影响，那就是让我意识到无论在什么时候，都要有勇气去做正确的架构决策。
为啥呢？我想你在做架构设计和技术选型时，肯定想不到“人命关天”这四个字。
但是就是上面这个医疗项目，让我意识到一个架构师必须要有良知，因为一个普通软件的决策可能是关系到一个人的生命。
美国的医疗行业比较喜欢拥抱新技术，但美国医疗行业又是各个科室完全独立，采购任何软件完全由医生说了算，所以一个大医院的CIO根本没什么话语权。
想想看，一个相当于我们国内三甲医院大小的地方，就能有近百套不同的系统。这么多完全封闭的系统其实把病人的档案信息都碎片化了，这样一来，就连发现病人药物反应这么简单的应用，都需要投入大量资金和人日才能保证上线。
从某种角度来说，这些部门到处都是局部最优的医疗软件选型决策。但从整体上来看，起到的却是适得其反的效果。这些部门医疗软件的错误选型其实等同于杀人，让本来技术实现相对容易的实时药物反应报警，成了一个几乎不可逾越的技术障碍。你可以查一下学术报道，2018年美国统计直接因为药物反应的致死率占所有死亡病人的0.34%，而在急救场景下更是高达10%。
我们所在的领域可能没有美国医疗这么极端，但更常见的是情况就是我们作为架构师天天执着于灭火，头疼医头脚疼医脚，忘了去追逐公司战略层面的正确目标。
你肯定听说过这样的例子：一次黑客攻击，领导认为安全不够，要求团队三天内解决问题。团队发现唯一能在三天内实现的方案就是提升登录注册的身份验证安全等级。于是，团队三下五除二上线了复杂的风控和身份验证方案，安全问题虽然在三天内解决了，但是紧跟着新用户的注册成功率下降5%。
假设你这么做了，那么虽然不是在杀人，但其实是在杀公司。你只是机械地执行任务，你的决策不仅没有把公司带到离正确目标更近的地方，反而在间接地浪费着你周边人的心力和生命。
甚至有更极端的，就是故意迎合领导，主动支持错误决策的架构师。我唯一的建议就是远离这种架构师以及任用他的人，因为他们是蘸着研发人员的人血馒头饱腹的人。
小结
我需要再重申一遍今天所讲的架构生存法则：架构师必须尽量保障整个架构活动有且仅有一个正确的目标，且这个目标必须和公司的战略意图相匹配。这是架构活动的起点，也是甄别架构方案的主要输入，所以架构师有义务影响和干预这个目标，以确保目标本身的正确性。
如果这个架构原则能起什么作用的话，我想就是在你最需要勇气的时候帮助你。
这个原则让你能够找到现有方案的弱点，看到这个目标和公司大目标不匹配的地方，然后让你有勇气站出来敢讲真话。讲真话的时候，不是你在反对你的上级，而是你在用一个架构原则来判断另外一个人的决策质量。
思考题
三个题目， 任选你最有共鸣的一个回答：
- 请你思考一下，你参与过的某个现在看起来不太合理的架构方案，你回想一下你当时有没有思考过那个方案是否“为企业创造生存优势”？如果你思考过了，是这个原则不适用于你的案例吗？如果你没有思考过，你可以试图用这个原则检验一下这个架构方案吗，你能得出和过去不一样的结论吗？如果你发现无法使用这个原则或者不影响你的结论，你可以跟大家分享一下为什么。
- 你做过的一个宏伟的为企业带来生存优势的技术项目吗？这个项目为什么会失败或成功了？这中间最核心的因素是什么？
- 你有没有成功劝阻过一个目标错误的架构活动呢？结果是什么呢？
欢迎把你的思考和想法分享到留言区，我会和你交流。同时，我也会把其中不错的回答置顶，供大家学习讨论。
精选留言
2021-12-09 08:14:47
可能有人会提到，定好的架构，为什么要不断优化完善呢？因为外界一切环境都在变，当时当刻制定的架构目标，是以当时背景作为起点，即使有一定的技术前瞻性，但是市场、企业，都在不断地再变化来更好的满足客户的需要，那么就回归到东白老师提到的，架构的目标要和企业战略目标保持一致，且能够创造价值。既然要达成这样一个目的，那么它必然不是一成不变的，而是完善中。
最后，我认为架构目标以及架构方案，是持续完善进化的，它既是一个明确的状态，也同样意味着它代表一个过程。
2021-12-07 09:39:39
2022-04-12 16:32:05
2021-12-08 13:49:23
只有经历过国际顶级巨头的洗礼+国内互联网的锤炼后，依然保持人性最为光明的良知，才能有如此非凡的见识，实在稀有难得。
可惜的是国内大部分企业的领导层和掌握架构决策层都如东白老师提到的反面教材一样，很多人只能穷则独善其身，赞叹东百老师的兼济天下！
2021-12-13 23:56:51
2.感觉东白老师这里有块内容，提到了但没点开。求之于势，不责于人。布置/借用趋势去驱动人，而不是责备人不胜任。文中提到要站在他人的视角去理解他的出发点的正确部分是什么，并加以引导。没点开的是这背后其实是在借助趋势帮助个人成长。让他去负责调研全面替代的成本，这是布局。基于这个局他可以感知到你的视角，这是成长。基于成长利驱动他用心完成战略目标，这是最终结果。
3.评论有看到反对人血馒头的说法，我觉得这个观点也是对的。不是每个领导都会从人出发，将下属个人发展的目标和公司战略目标做出正确的关联。当两个目标不匹配时，下属出于自身利益优先追求自己的目标是人之常情，错不在下属而在制度和领导（为什么？求之于势，是自己没把局布置好）。而故意做出错误的架构决策就能说是人血馒头吗？感觉也不合适，当皇帝讲究正大光明，但夺嫡成功之前为了达成特定目标，难免也得用些阴谋诡计。
2021-12-08 23:10:28
作为非技术出身的同学，出于好奇来旁听这门课。最后这句话，让我想到平时和同事讨论工作的场景：一般来说，在我们并不假定只有唯一解，也不急于争出谁对谁错，而是各抒己见，阐述自己理解和推导过程，这种情况意外的更有启发。
2021-12-08 19:01:29
2021-12-13 07:49:40
1. 就技术项目而言，技术架构的目标和项目目标是一样的吗，有没有区别呢？比如说统一网关作为一个项目。
2. 如果自己在技术决策的时候，目前掌握的信息或者技术细节不确定是否能做出最优的决策。是应该把所有东西都搞清楚再决策，以免返工。还是应该尽量决策，后续再做架构调整或者升级呢？
谢谢。
2021-12-11 21:36:17
* 我参与过的架构，争论技术优势和可行性，就已经把脾气都摩擦出来火花，代入几个案例，就更加是火上浇油，你能举出的例子，别人可以举出更多例子。然后就会在现有架构里，修补一下继续过日子。印象中，从来没有始终围绕过为企业创造生存优势。现在想来，能够知道和能够做到之间，差距不仅在于认知，更在于认知的匹配，以及匹配认知后的坚定执行。
* 这次课程后，给自己播下一个种子，后面参与的架构活动，都不停追问自己：战略在哪里，目标是什么，架构是否在创造生存优势。还有一个困惑，那就是这个种子，如何不会在后面的架构活动时被遗忘，怎么能够真发芽🌱，这也是值得提前思考的问题。
2022-04-13 16:47:52
2.帮领导做取舍；
3.夺领导的取舍；
4.等领导做取舍。
第3种方法太猛了，注意安全。
2021-12-28 14:25:01
提到失败的项目，我这里也有一个反面例子。曾经有一个软件研发项目，由CTO和研发部门负责推动，大家对项目期望很高，投入了很多的人力财力，经过近两年的研发，试点项目成功上线了。
项目上线之后，国家恰巧也出台了相关政策，公司希望快速推广。此时才发现，根本没人准备好，销售同学没有高质量销售资源、市场和售前同学无法出产品方案、项目经理入场后无法和用户在同一频道沟通、产品安装部署复杂实施同学压力山大、研发部门被要求补齐各方短板，最后拖来拖去错过了整个产品的时间窗口，大家相互指责，部门间对立严重。更可悲的是，公司的现金流产品被边缘化了两年多，后果可想而知。
事后诸葛亮，反思一下。虽然当时大方向是对的，但每个人目标从来没有真正统一过，公司在各维度上距离想做的事情太远。在产品研发期间，不仔细考虑产品目标，不提前准备积累，不提前培养人才，不提前考虑后面怎么办，失败是必然的。
2022-01-12 20:42:57
几年前在2B行业，做企业信息管理工具，这个项目最终失败了。原因我觉得最重要的一点是公司短期定的目标过于宏伟，属于“既要”、“又要”、“还要”的类型，远远超出了公司现有资源和能力所能过承载的，有很多的功能都是浅尝辄止，甚至都没来得及上线，严重打击团队信心很多不错的人选择离开。还有一点在于大环境下，企业微信和钉钉等工具的冲击，在当时的资源和能力下无论是产品体验、运营推广、客户维护都相距甚远。如果现在站到当时的场景下决策，应该不会定那么多不切实际的目标，可能会在某个领域深耕来建立竞争优势，毕竟整个2B盘子足够大，拿下一小块也能活的不错吧
2021-12-23 10:22:40
我在14年的时候做过一款硬件产品，产品形态为Android机顶盒，当时高层希望将Android机顶盒做出PC体验，后面在设计整个框架的时候，都是按照这个思路来进行的。那个时候刚毕业，对于系统的理解不深入，最后按照这样的架构设计做出来的产品失败了。这个对我自己的影响很大，我认为技术的出发点一定是产品需求的正确性，所以未来的开发过程中我一定会问清楚这个产品给用户带来的价值。
使用今天的原则，在上面的案例里面是非常适用的。在做任何产品的时候，需要去考虑产品带给用户的价值，带给企业的价值，哪怕老板要求不要管，也需要我们自己独立思考。
独立思考的勇气，这点难得可贵，我们不能因为别人而改变自己的思考，或者是不去思考。或话，在人生的长河中我会遇到挫折，遇到不公，但所有的这些不能改变我独立思考的勇气，不能改变我对理想的追求。
2021-12-17 08:05:19
2021-12-12 10:18:52
2021-12-11 16:15:19
2021-12-08 09:11:59
2021-12-08 06:52:39
2022-09-07 23:57:41
2022-09-04 17:45:48
接手时这个系统是个大泥球，我出于以下目的将其重构成了一个层层解耦的多级任务系统：
1. 为了获得更好的可拓展性，支持多样的业务接入；
2. 为了获得更好的稳定性，让每个修改的爆炸半径可控；
3. 提高研发效率。
在重构到一半时，我就后悔了。因为市场变了，公司市场份额下降，希望刺激商户获取更多的利益，而不是通过各种手段抑制他们。我的系统和这个目标时相背的，虽然后面重构完成，经过一段时间的灰度后替代了老系统，但很显然没有达到我们最希望达到的那个目的。这个事情给我的最大感触是，技术在商业环境下的无力感。如果再来一次，我会及时修改这次重构的目标到稳定性和研发效率上，减少不必要的拓展点，让系统更简单，更快完成重构，后面根据业务需要再继续迭代。