key_3_feng的博客

说句题外话，这种交流场景常见于大学和研究所，往往是两个教授有共同的背景，或者对某个问题有着长期的研究兴趣。你们会在一个问题上做深度的思想碰撞，问题本身可能并不具有实用性，所以交流是在逻辑层面上的。如果你能判断一个人的思考力，也能在单个问题上判断思考质量，也善于发现并愿意和有高质量思考的人相处。第二种态度则是一种基于现实问题的互助的关系，现实的目的性很强。这种合作方式还有个好处，就是最终会形成一个从思考到实现的反馈闭环，可以让思考者从实践中发现思考的漏洞，从而进一步提升认知。《郭东白的架构课》，推荐该课程。

目标的唯一性与正确性很关键

一个有实证思维的人，会认为自己的模型及从模型总结而来的规律是普适的、可以表达和复制的。

每个商家都有自己的定位、供给优劣势和特定的服务能力，如果一味听从平台的建议，不断尝试新的模式、服务新的人群，最后只会经不起折腾，蒙受重大损失。

第三，关注链接，也就是关注领域之间的关系，而不是每个领域内部的细节。你可以检查他们内部的工作，但更重要的是关注跨领域的划分、领域之间的接口和跨领域的数据标准。也就是说，如果把整个架构域画成一张图，图里的节点是独立的子领域，边是连接两个子领域的协议。架构师处在一个能够了解全局的角色上，所以需要把更多的注意力放在整体的目标上，以及把整个架构活动作为一体来创造的最终价值上。至此我们就会发现，架构师的全方位思考不是一个人在独自战斗，而是通过协调和引导团队的关注点，让架构活动参与者共同完成全方位的思考。

不过大大小小的怀疑都有一定的实用性，所以要在这些可怀疑的对象中间，首先选择那个价值最大的去怀疑。简单来说，批判思维不是为了证明你比别人更高明，而是要给架构活动带来更高的成功概率，不要没事和别人抬杠。反过来，如果你以信仰驱动的“因为相信所以看见”的态度去批判别人的理性思维，那么你跟中世纪的宗教审判者也就没什么两样。在这种背景下，架构师会担心自己是不是因为没相信，或者是缺乏内幕知识才看不到逻辑的正确性，从而放弃了怀疑。原因就是批判思维会否定那些低质量的决策，帮助企业提升思想实验的质量，从而找到更好的决策。

在考核指标上，前台考核业务增长，中台则考核前台对新需求响应的延迟、前台定制的成本和接口的高稳定性。对中台定期做设计 Review 和日常的变革约束，避免技术频繁重构的同时，保障大版本的迭代能跟上竞争的需求。而被前台选择的技术也会获得相应的激励，进一步提升中台和该前台的适配性。未来的中台建设，必须要有公平的、合理的、能够保障长期价值创造的组织机制，主要包括如下四个机制：由市场来选择最好的中台的提供者和最合理的设计。总结下来，中台的建设要有与之匹配的市场化的、尊重原创的、鼓励经营的组织和激励机制。

第三，思考者的贡献度。一个极端稀缺的洞察，往往有一个非常极端的前提条件，就是他能拿到别人拿不到的数据和知识。也就是说，如果一个高质量的洞察背后缺乏配套的周边，那么这个人可能只是听说并复述了别人的洞察。我手里拿着这些数据，并解释了这些数据的分析方法，那么我的洞察就是可以溯源的，这样才能证明我的洞察的真实性。如果一个人的高质量思考来自对数据的执着、思考深度的探索、见识的广博，那么这种可重复性就非常有价值。总的来说，洞察的价值可以用有效时间和资本回报来度量：所谓有效时间，就是这个洞察的有效的时间范围。

反思是批判思维的一个具体应用。反思是一个理性的思考过程，是基于逻辑思维的、理性的、怀疑的、公正的思维方式

架构师无法在一个舒适的环境下最大化个人成长

去中心化是个理智的选择

针对企业愿景、团队特性和竞争环境所制定的长期技术规划，是企业战略的一个重要组成部分。

这六条法则的顺序并不是完全正交的。事实上，只有法则一必须要排在第一位，其他法则的优先级排序和使用都需要根据实际情况来调整。

良知，有利于你与架构活动参与者建立信任，最终推动整个架构活动走向成功。

架构师要通过优化架构方案、干预架构活动，以保证最终交付的项目不仅能满足既定目标，还能适应不断变化的外部环境。

架构师需要不断监控自身能力的有效性和增量价值，不断提升自身能力的稀缺性和价值创造的空间。

一个架构师，如果你能尽早看懂看透你公司的用户心智，那么你就可以在技术上提前布局，从用户思维出发，扩大你的技术搜索空间，最终为公司创造更大的价值。

作为一个架构师，知天道不够，还是要顺天道，也就是说我们的架构要符合技术的自然周期。

作为一个架构师，必须要创造足够的商业价值，这样才能保障你在企业长期存在的意义。

做架构和做业务一样，都不能靠饱和攻击取胜，而是靠对阶段性精确目标的最大化投入来取得进步。

划分微服务的粒度不仅需要考虑研发的人性，还要考虑服务本身的原子性、团队大小、团队人员的稳定性、服务的高可靠性要求等等。

软件是由人类所构造的一个虚拟的存在，而这个构造过程，是靠一组研发人员共同协作完成的。既然马斯洛的模型适用于一切人类活动，那么这个模型当然也可适用于与软件构造相关的架构活动。

一个架构师要拥有的业务理解的能力，是基于自己对业务深度认知之后的技术洞察，然后通过这个技术洞察来推动业务发展的能力

能有一位架构师将自己充满瑕疵的方法拿出来，请大家讨论、批判，并提出更好的建议，然后为其他人呈现出高质量的思考。

每个人都有自己的风险承受度，以及内心最喜欢做的事情。有的人内心可能很喜欢当一个 CTO，但却无法承受能提供这种机会的高风险环境。

充分条件保证了成长的有效性，必要条件保障了成长的速度。如果能同时满足充分条件和必要条件，就能获得更多高质量成长的机会，从而在架构师这个岗位上快速且有效的成长。

思考力、信息内化能力和适应力作为架构师成长的三个必要条件

做好总架构师其实有一个必要条件，就是具备和 CTO 建立深度信任的基础，以及能化解日常冲突的能力。

横向能力不是积攒得越多越好。公司发展到比较大的时候，相比覆盖广度，横向能力的深度和稀缺性要更重要一些。

软件上结构化设计最大的好处就是可以不断演进，甚至推到从来。罗马不是一天建成的，需要不断地迭代优化再优化。

架构师在架构活动中持续创造的价值。即：通过持续发掘和评估重大风险，来控制整体的交付风险；通过分析和解决差异点，促进尽可能多的参与者达成共识；通过不断分解问题，保障增量价值的交付；通过持续的文档沉淀，从而驱动科学的决策。

复盘就是从公司层面进行回顾过程、搭建环境、梳理机会点、挖掘根因、寻找新的模式与机制、产出跟进项的完整过程。

架构活动的复盘，是你跟其他参与者深度学习的好时机。这是一个集体思考的过程，不是我们日常的习惯性行为。

通过对失败事件的深度剖析，从中寻找一些机会点，从而提升企业未来的架构活动的成功概率。

从商业价值、用户价值、技术价值来进行拆分

忠于架构目标，尊重市场反馈，以最大化企业 ROI 的原则，选择正确的交付路径。

规划确认环节的王道，就是通过精细规划来控制风险，保障全面启动前交付风险的最小化。

技术问题和团队冲突不可避免，但我们有确定的沟通机制和处理流程来帮助大家解决问题。

项目启动的真正目的，是让所有参与方完成一次有约束效应的目标与任务确认。