2022 year-end review
说来惭愧，博客一年没怎么更新了，说什么理由都是借口，哈哈哈，其实在Java领域玩了这么多年，对于技术细节探索和新技术兴趣，没有刚开始进入这个领域热情高涨了，转而对技术架构设计产生了极大的热情，
但是技术架构探索和积累是完全通过理论加实践实际操作搅拌出来了，第二个是在做嵌入式相关的学习，目前还没有输出像样子的东西，不好意思写博客，今年的复盘如下：
我的2022：
一月：做核酸
二月：做核酸
三月：做核酸
四月：做核酸
五月：做核酸
六月：做核酸
七月：做核酸
八月：做核酸
九月：做核酸
十月：做核酸
十一月：做核酸
十二月：阳了
各位看官是不是深有感触。好在我的免疫系统过于变态，至今未阳，以至于我感觉和在坐的各位感觉格格不入，真是给村里的“羊”队生产总值拖后腿了。
谈下一个话题。
数一下今年认真提高的几个点
政治
今天斗胆谈一下政治
福报厂的公司文化价值观，除了第一条客户第一，其他的价值观都是政治，都是为了控制人的；
它甚至玷污了第一条，让很多人错误的认为客户第一也是bullshit。
这个世界上有些规则都是相通的，在混沌之中建立秩序，分为对事物的治理和对人的治理，对事物的治理方法论有很多，
但是对人的治理只有一种——–政治。
在中国很多人都受到过教育，教育的目的除了让人有更多的选择，另外一点是学会辨别，分别什么是对的，什么是错的，
有一部分人会分辨，但是迫于政治和群体惯性意志，现实的引力太强，根本无法支棱和去改变，因为代价是被踢出这个大家公认、合理的、
被约束的、每个人利益都可以最大化的怪圈。
于是，社会上出现了一种理论—–适者生存，鄙人将这种理论成为“社会达尔文理论”，如果在人类社会(注意是人类社会，不是人类生物圈)，
如果有人认同这个理论，那么鄙人认为他就是个没有思考的主流病毒价值观传递网络的一环而已，以前的教育白上了，没有分辨能力。
你有读过《物种起源》去认同，我不会骂你，但是没有读过，认同这样的理论属实草帅和愚昧。
达尔文的适者生存只适合于生物圈的生物特性演化，是带着自然的残酷和时间维度上物理上的适用，充满了野蛮淘汰，竞争上位，
而人类社会如果加载了这些血淋淋的东西，文明将不会是文明，文明的组成是意志、精神、秩序上的有机统一和一致，存在着善良、
人道、约束、合作。使用社达，就是给达尔文戴无辜的帽子，不分析原因就去社达，过于草率。
但是这些和福报厂价值观有吊毛关系呢？
其中一个关系就是在公司文化价值观体系下，衍生的政治本质约束下，存在着底层韭菜的竞争，但是如果用“社达”去解释和合理化这个体系，
这就略显愚昧，在这个政治体系下，也不是没有选择，选择无非就是朝着事情的2个极端发展，要么躺平、沉默，这是一种反抗，要么适应、内化，
这是一种成长，这2种选择都没有对错之分，底层都有一套无法用主流价值观解释的原因，另外在不同的环境，就会衍生不同环境的人和秩序，
在一套环境的成长和对抗，不代表在另一种环境的成长和对抗，我们还是要相信相对主义，这并非自我合理化，而是一种世界上无限的无法确定的可能性，要去客观针对。
政治这个东西，一家公司如果想要建立一套公司文化和价值观，让生意长久兴隆下去，教科书式的教材就是国家的政党体系，你只需要用正确的价值观和大众公认的正确的方向，
以此作为作用范围内所有人潜在承认的价值体系即可，比如社会主义核心价值观24字，形而上学复制一下作为企业的价值观就可以建立资本体系政治基座。
政治是为了秩序、统一、约束、控制，但是会一定程度的失去创造力和自由，这就像有创造力和崇尚自由的人都润出去了，润出去的人都是知识分子、资本家，
他们分别带走了知识和财富，一个组织失去了知识和财富，剩下就只能是愚昧和贫穷，一个愚昧和贫穷的组织需要什么，它需要一个皇上。
然后底层干活的逐渐失声，因为组织关闭了声音的接收。这是一种副作用，只要企业使用了政治，企业也会有副作用，人才流失，组织臃肿，次之声誉扫地，股市熊熊烈火。
另外，谈一下PUA，首先是PUA的鉴别不是通过推理和百度搜索一下得出来的，这属于很肤浅的PUA，高级的食材都是经过时间的淬炼，你的教育积累决定了你能不能分辨，或者它有没有掺水，大部分PUA都是拿着锤子找钉子，预先设定，惯性操作，政治和集权约束的副作用而已。
有人很喜欢用认知解释事情，那认知是不是也存在选择呢，我相信人都有自由意志，《西部世界》这种反自由意志的case只是妄自菲薄，
每个人都有认知选择的自由意志。
另外一个维度，认知的高低，高认知的获取通过成长，内化获取，低认知的保持，躺平就行，这也是一个选择，所有选择都没有对错，他的底层都有一套更加抽象、宏观，
脱离环境之外的原因他是相对的。错的是定义它的对错这个行为。
现实社畜很多人都常常思考人生和生命的意义所在，诺贝尔文学奖获得者加缪的存在主义给出了很不错的答案，给出了三个解决无意义人生内耗的三个方向:对抗、激情、自由。
在这里要指出的是，很多时候我们对抗或者内化的都不是具体的人，而是人性的网络构建的群体意识，你只需要做的仅仅是做出选择，而不要去定义它的是否存在性和对错。
说服之术
你在和后端同事在某个设计上产生了分歧，你和前端妹子在甩锅这个逻辑是前端吃还是后端包掉，你和你的领导在某个设计上那个方案更优秀焦灼不下，你总是想让对方按照你的思路去落地，你认为你的设计方案是天衣无缝、高效、优雅的，你觉得你是C位，甚至在无法说服对方的时候，情绪失控，大喊：这个就这样搞！按照我说的做，你那个不行，太XXXX了。
基于以上case，有时候让我们很是不爽，你的强迫症促使你必须打败和说服对方，让对方说：大佬英明。。。。
那么怎么说服同事，说服领导，说服前端妹 子/后端大佬，说服产品呢？
我们先分析一下分歧的本质，对于解决同一个问题，你和对方持有各自的意见，各自坚持的原因有如下几个：性能、工作量、合理性。
举例说明下，现在有一个系统，每次有新的需求过来都需要开发、测试、前端介入开发，但是每次开发都是同质性很强的代码，于是为了提效，架构师进行了一次架构重建，想减少开发的工作量，同时也减少系统交付时间，快速满足业务诉求，一举两得的事情，业务和开发都从中受益，能够从以前15天交付通过架构重构以后能达到5天交付，经过架构师设计以后，将系统里边的同质化的东西全部抽象后，进行了可视化配置，包括数据接口和依赖于数据接口的页面都是可以配置的，配置的工作由开发同学执行，这一步在整个需求交付里边属于配置阶段，开发同学配置完毕以后，配置了很多组件，这些组件是组成业务推进页面的积木，然后就是产品同学接入，产品同学拿到这些积木以后，往一个空白页面拖拉积木，构建一个有实际业务语义的页面或者业务流程动线，然后发布上线给到用户使用，这些积木的构建都是在本次架构调整当中需要前后端实现，这是一套配置系统，只要实现这一次，后续就不用在写代码了，只需要开发同学配置积木就行，但是在开发阶段，这套配置系统在前端表现的很复杂，前端同学觉得复杂度太高了，而且需要开发很长的时间，而且开发同学说他们的开发人力资源不够，另外还说道，这个配置系统投入和产出比太小了，意思是我投入了这么大的力气，开发了一套复杂庞大的前端页面，得到的收益是很小的，因为页面是给开发同学使用的，可以做的简陋一点，开发同学能看懂就行，就不是给产品或者用户使用的，没必要把页面做的如此复杂，在这这套系统仅仅一个业务在使用，业务上没有大规模推广的计划和相同性，既然使用场景很少又是开发人员使用，更不应该投入进入，这件事情不应该去做，这是前端给到第一个核心的反驳支撑点，而且前端给出了一个折中的方案，就是在原来的前端页面设计做下修改，一部分简单的页面数据交互由前端实现，剩下的大部分复杂的交互，做成json配置的形式，因为这些复杂的页面交互部分也是对json数据进行搬运，为了减少复杂度，直接在页面让开发同学输入json数据完成积木的配置阶段。
前端带着这个折中的方案来找后端的开发和开发leader开撕，那么我们首先要知道前端的诉求，他们的诉求第一是页面复杂度太高，第二是他们的资源有限，第三是投入产出比太低。
分别对应我说的工作量、合理性2个本质。
这个前端的诉求过来以后，大部分人都会觉得前端想逃避问题，想出了这个说法来规避进入复杂页面的编写，他们觉得，这个复杂的页面第一期上了以后，后边还会进行迭代，前端会频繁进入这个复杂系统的开发，是一个泥潭，无法挣脱，不仅做了没有好的绩效提升，而且这么复杂很容易出问题，还会把其他重要的事情挤占了资源，得不偿失，这个是前端拒绝做这个事情背后真实的原因。
接下来是后端架构思考回路：
针对前段给到的折中方案，简单的页面前段可以开发，但是复杂的部分前段不会开发页面支撑数据操作，由开发人员配置json的形式达到最终的配置目标，首先思考前段的方案是否和我们架构重构的目标冲突，我们的架构重构是为了提高需求交付效率，解放开发人员的生产力，如果使用前段方案一般是页面交互一般是json配置，其实对我们架构重构的目标没有很大的影响，只不过增加了开发人员
去理解json配置结构的成本，其实使用页面去组织这个json也是由理解成本的，只不过小一点，那么后端是坚持呢，还是同意前端的建议，其实是应该同意前端的建议的，因为他说的既没有和架构设计目标冲突，也没有影响产品最终目标，它是合理，这里有一个重点就是合理性是不是和目的冲突，你虽然说的很合理，但是和初始目标冲突那么合理性本身就不具有合理性的约束。
其次，如果工作量和合理性冲突怎么办，首先最先想到的是不能降低合理性达到减少工作量的目的，这是掩耳盗铃，一个事情不合理，后期工作量肯定是指数增长的。如果我们把开发的诉求告诉业务方，这个需求我们资源不足，为了满足能让你们跑通业务，我们砍掉一块能力，或者你们决定砍掉那一块，这些迂回战术都是可以，但是就是不能答应既要也要的情况，当你无法说服别人以及你自己的时候，就不应该坚持了，除非你能找到强有力站得住脚的理由，而且是合理的，当你开始接受别人的建议的时候，其实也是一种吸收，让自己的思路更加包容，包容的越多，你对各种各样问题域的解题思路就会越多，越准确，这就是从实践中积累经验的一个方法。
因为我们得出一个结论：
- 不要闭门造车，和别人讨论，要么你打败了别人对你思路的怀疑，要么别人把你的设计思路干死，前者说明你确实是对的，后者我们要懂得包容，在合理，不冲突的前提下尝试吸收别人的思路，从另一个维度看自己是赢家。
- 说服别人，不是用强制的语言和手段达成的，而是用做成这个事情更加合理，更加高效为意愿，论证了对方是和意愿冲突的。
对抗软件复杂度的战争
上边说的这个场景，出现了复杂的问题域，我们每天都在面对这个复杂度的战争。
一、何为研发效能？
当我们谈研发效能的时候，我们在谈些什么？这个议题被抛出来，有人讨论，是因为存在问题，问题就在于实际的研发效率，已经远低于预期了。企业初创的时候，一个想法从形成到上线，一个人花两个小时就完成了，而当企业发展到数千人的时候，类似事情的执行，往往需要多个团队，花费好几周才能完成。这便造成了鲜明的对比，而这一对比产生的印象，对于没有深入理解软件工程的人来说，显得难以理解，可又往往无计可施。
前文我既用了“效能”一词，也用了“效率”一词。这是为了做严谨的区分，效能往往是用来衡量产品的经济绩效，而效率仅仅是指提升业务响应能力，提高吞吐，降低成本。
本世纪 10 年代，早期的互联网从业者开发简易网站的时候，只需要学会使用 Linux、Apache、MySql、PHP（Perl）即可，这套技术有一个好记的名字：LAMP。可今天，在一个大型互联网公司工作的开发者，需要理解的技术栈上升了一个数量级，例如分布式系统、微服务、Web 开发框架、DevOps 流水线、容器等云原生技术等等。如果仅仅是这些复杂度还好说，毕竟都是行业标准的技术，以开发者的学习能力，很快就能掌握。令人生畏的复杂度在于，大型互联网公司都有一套或者多套软件系统，这些软件系统的规模往往都在百万行以上，质量有好有坏（坏者居多），而开发者必须基于这些系统开展工作。这个时候必须承担非常高的认知负荷，而修改软件的时候也会面临破坏原有功能的巨大风险，而风险的增高就必然导致速度的降低。
因此研发效率的大幅降低，其中一个核心因素就是软件复杂度的指数上升。
二、本质复杂度和偶然复杂度
Fred Brooks 在经典著作《人月神话》的「没有银弹」一文中对于软件复杂度有着精彩的论述，他将软件复杂度分为本质复杂度（Essential Complexity）和偶然复杂度（Accidental Complexity）。这里的本质和偶然两个词来源于亚里士多德的《形而上学》，在亚里士多德看来，本质属性是一个物体必然拥有的属性，偶然属性是一个物体可以拥有的属性（也可以不拥有）。例如，一个电商软件必然会包含交易、商品等业务复杂度，因此我们称它们为本质复杂度；而同一个电商软件，可以是基于容器技术实现（也可以不是），可以是基于 Java 编写的（也可以不是），因此我们称由于容器技术或者Java 技术而引入的复杂度，为偶然复杂度。
Fred Brooks 所描述的软件本质复杂度，指的就是来自问题域本身的复杂度，除非缩小问题域的范围，否则是无法消除本质复杂度的。而偶然复杂度是由于解决方案带来的，例如选择了 Java，选择了容器，选择了中台等等。
此外，我们可以从所谓问题空间（Problem Space）和方案空间（Solution Space）来理解这两个复杂度，问题空间就是现实的初始状态和期望状态，以及一系列约束规则（我们常常称之为业务），方案空间就是工程师设计实现的，一系列从初始状态达到期望状态的步骤。缺乏经验的工程师往往在还没理解清楚问题的情况下就急于写代码，这便是缺乏对于问题空间和方案空间的理解，而近年来领域驱动设计为那么多工程师所推崇，其核心原因就是它指导了大家去重视问题空间，去直面本质复杂度。Eric Evans 在 2003 年的著作《Domain Driven Design》，其副标题是 “Tackling Complexity in the Heart of Software”，我想这也不是偶然。
《人月神话》写于 1975 年，距今已经有 47 年了，Brooks 认为软件的本质复杂度是无法得到本质上的降低的，同时认为随着高级编程语言的演进，开发环境的发展演进，偶然复杂度会得到本质的降低。他的论断前半部分对了，然而后半部分是错了，我们今天的确有更高级的编程语言，功能更丰富的框架，能力更强大的 IDE，但是大家逐渐发现学习这些工具已经成为了一个不小的负担。
三、复杂度的爆炸
今天的软件已经从深入到人类生活的方方面面。稍有规模的互联网软件，都服务着数百万、千万级的用户。阿里巴巴的双11在2020年的峰值实现了每秒58.3万笔的交易；Netflix 在2021年Q4拥有了2.2亿的订阅用户；而 TikTok 在2021年9月宣布月活数量超过10亿。这些惊人的商业成功背后，都少不了复杂的软件系统。而所有这些复杂软件系统，都不得不面对巨大的 Scalability 的挑战，服务一个人的系统，和服务一亿人的系统，其复杂度有着天壤之别。
本质复杂度是一个方面，毕竟更多用户意味着更多的功能特性，但我们无法忽略这里的偶然复杂度，其中最典型的就是分布式系统引入的偶然复杂度。为了能够支撑如此大规模的用户量，系统需要能够管理数万机器（调度系统），需要能否管理好用户的流量（负载均衡系统），需要能够管理好不同计算单元之间的通讯（服务发现，RPC，消息系统），需要能够保持服务的稳定性（高可用体系）。这里的每一个主题都能延展开用几本书来描述，而开发者只有在初步掌握了这些知识后，才能够设计实现足够 Scalable 的系统，服务好大规模的用户。
相比于分布式系统引入的复杂度，团队的扩张更易带来偶然复杂度的急剧增长。成功产品的软件研发团队动辄数百人，有些已经达到了一两千人的规模。如果企业没有严格清晰的人才招聘标准，人员入职后没有严格的技术规范培训，当所有人以不同的风格，不同的长短期目标往代码仓库中提交代码的时候，软件的复杂度就会急剧上升。
团队的扩张还会带来另外一个问题，在大规模的团队中，关键干系人的目标事实上是影响软件复杂度的关键因素。我亲眼见过许多案例，其方案空间中明明放着简单的方案，但因为这个原因，当事人不得不选择复杂的方案，例如：
- 原本方案只需要直接改动系统 A，但由于负责系统 A 的团队并没有解决该问题的动力，其他人不得不绕道去修改系统 B，C，D 来解决该问题。
- 原本方案只需要直接改动系统 A，但迫于系统 B 负责人或者上司的压力，方案不得不演进成同时改 A，B，甚至引入 C。
更有甚者，为了各种各样的原因，提出一些完全假设出来的问题（即，事实上并不存在的本质复杂度），然后拿着软件系统一阵无谓折腾。最后个人或者某个团队的目标实现了，但软件没有提供任何增量的价值，而复杂度却不会因此而停止增长。
四、错误的应对方式
面对效率地不断下降，研发团队的管理者必须做点什么。不幸的是，很多管理者并不明白效率的降低是由软件复杂度的上升造成的，更没有冷静地去思考复杂度蔓延直至爆炸的根因是什么，于是我们看到许多管理者其肤浅的应对方式收效甚微，甚至起到了反作用。
最常见的错误方式是设置一个不可更改的 Deadline，用来倒逼研发团队交付功能。但无数经验告诉我们，软件研发就是在质量、范围和时间这个三角中求取权衡。研发团队短期可以通过加班，牺牲假期等手段来争取一些时间（长期加班实际有百害无一利），但如果这个时间限制过于苛刻，那必然就要牺牲需求范围和软件质量。当需求范围不可缩减的时候，唯一可以被牺牲的就只有质量了，这实际就意味着在很短的时间内往系统中倾泻大量的偶然复杂度。
另一种做法是用“更先进”的技术去替换现有系统的技术，例如用 Java 的微服务体系技术去替换 PHP + Golang 体系的技术；或者用支撑过成功商业产品的中台类技术去替换原来的微服务体系技术；或者简单到用云产品去替换自建的开源服务。这些做法背后的基本逻辑是，“更先进”的技术在成功的商业场景中被验证过，因此可以被直接拿来解决现有的问题。
但在现实情况下，决策者往往忽略了当前的问题是否是“更先进”的技术可以解决的问题。如果现有的系统服务的用户在迅速增长，Scalablity 面临了严重的困境，那么这个答案是肯定的；如果现有的系统的稳定性堪忧，经常不可用且严重影响了用户体验，那么这个答案是肯定的。但是，如果现有的软件系统面临着研发效率下降问题，那么“更先进”的技术不仅帮不了什么忙，还会因为新老技术的切换给系统增加偶然复杂度。
宏观解决之道
我先简单介绍一下 Wardley Map。
Wardley Map 是一个帮助分析技术战略的工具，它以地图的方式展现，地图中的每个组件可以被理解成一个软件模块，纵坐标是价值方向，越往上越靠近用户价值，横坐标是进化方向，越往右越靠近成熟商业产品。
例如上图中，Compute 是计算资源，在今天有许多成熟的云计算公司提供，但它离图中上下文业务的用户价值非常远。Virtual Fitting（虚拟试衣）则离用户价值非常靠近，因为它可以让用户更有信心自己是否购买了合适的衣服，但是这个技术显然还谈不上是成熟产品，只是自己研发的模块，远没有达到开放商业化的阶段。
设计研发一套用来支撑百万、千万级用户的分布式系统，是非常有挑战的事情，而且会给系统引入大量的复杂度，管理好这些复杂度本身则又是一项巨大的挑战。幸运的是，今天的云厂商，包括阿里巴巴，亚马逊，谷歌和微软等，在这方面都具有丰富的经验，并且已经通过多年的积累，把这些经验通过商业产品提供给市场。
从 Wardley Map 的方式去分析，我们就会发现，几乎所有的业务，其左上角（贴近直接用户价值，不成熟）都必须是要自己研发和承担复杂度的，而只要做好正确的软件架构，那么就能把右下角的部分（远离直接用户价值，有现成商业产品）提取出来，直接购买。所以在今天，一个合格的架构师，除非自己是云厂商，否则绝对不应该自己去投入研发数据库、调度系统、消息队列、分布式缓存等软件。通过购买的方式，研发团队完全不用承担这些复杂度，也能轻松地支撑好用户规模的增长。
微观层面的复杂度控制
这一块属于编程细节范围，简答就3句话概括：
- It works
- It is easy to understand
- It is safe to change
系统架构对复杂度的影响
在面对需求的时候，缺乏经验的工程师会直接想着在自己熟悉的模块中直接解决，而经验丰富的工程师会先思考一下系统上下文。在《Design Docs at Google》这篇优秀的技术文档写作指导中，就重点提到了，设计文档应当写清楚系统上下文图（sysmte-context-diagram），这背后的原因是什么呢？
我近期对一个遗留系统做了一个依赖链路的梳理分析，这个系统是负责生产环境中各类资源的管理的，包括资源的规格，版本，依赖关系等等，梳理完成后，整体的结构吓了我一跳，这个图大致是这样的：
图中蓝色的部分是控制和执行的子系统（System X，Y，Z），例如控制容器的调度，控制镜像变更的执行等等，是比较清晰的。但是其余部分就不是这样了（A1, A2, A3, C1, C2, S, E），它们都是在管理一个资源的运行态版本，包括镜像的版本，容器的规格，是否有 GPU，容器的数量，关联的网络资源等等，但却演进出了七个子系统，这实际上是非常高的偶然复杂度。当一个领域的概念被分散到这么多子系统之后，就会产生一系列问题：
- 不同子系统对于同一个概念有不同的名称，交互的时候会涉及各种翻译。
- 不同子系统承担了同一个实体的部分概念，导致修改的时候需要大范围一起修改，且容易出错。
- 更高的运维成本。
仔细去分析这一复杂度形成的因素，我发现这既不是技术战略的问题，也不是微观层面工程师生产低质量代码导致，而是有其他更深层次的问题。其中的最核心的因素是，这些子系统在不同时期是归属于不同的团队的，有的甚至是不同部门的，具体来说，当各个部门各个团队目标不一致的时候，而这个系统又不幸地被拆到各个团队，那么就不会有人会对系统整体的复杂度控制负责。当有的团队在负责把这套系统商业化对外输出，有的团队在负责把这套系统从虚拟机模式演进到容器模式，有的团队在负责资源的成本控制，有的团队在思考全局高可用架构，而没有一个全局的架构师从整体控制概念，控制边界的时候，系统就自然而然地腐化成这样的一个状态了。
当一个问题域没有系统架构，或者其系统架构是错误的时候，你就会发现不同的人在发明不同的语言，这就好比相隔几十公里的两个村子，常常对同一个概念有不同的用词或者发音。日常生活中语言的不精确不是问题，因为日常的沟通是充满上下文的（表情，气氛，环境等），但在计算机的世界，语言的不精确就意味着需要写代码翻译，一旦翻译错误软件就会执行出错。这也就是为什么领域驱动设计那么强调统一语言，强调限定上下文。但领域驱动设计是方法论，而知道方法并不能取代系统架构角色的缺位。
这个复杂系统是康威定律的绝佳例证，康威定律说：“任何系统设计的系统，其系统结构会复制组织的沟通结构。”这句话其实还是有些抽象的，更具体的一些阐述是：
1 | “康威定律 … 是一个合理的社会学观察。… 除非模块 A 和模块 B 的设计及实现者能有效沟通，否则这两个软件模块是无法正确对接的。因此软件系统的接口结构，就必然会和生产软件系统的社会结构及组织相对应。” |
康威定律所揭示的事实，就是软件架构在很大程度上是由组织的结构和协作模式决定的，这实际上已经不再是一个软件技术问题了，而是一个组织管理问题。因此，解决系统架构层面的软件复杂度问题，就必须面对组织管理的挑战。关键问题域是否有唯一的负责人？当不同的团队在同一个问题域重复建设系统的时候，如何整合团队？当已有团队为了自己的生存，不断夸大其负责系统的重要性和特殊性，如何识别这种问题？组织如何给予大家充分的安全感，让工程师愿意为了架构的合理性，放弃自己辛苦耕作的系统模块？
讨论管理工作似乎已经超出了这篇论述软件复杂度的文章的范畴，但很多工程师或者隐隐感觉，或者思来想去最终领悟，这是我们的软件系统或优雅健壮或千疮百孔的根本因素。
架构设计的原则
上面介绍了软件复杂度，介于宏观的技术战略和微观的工程师文化之间，存在着一块重要的决策区域，也对软件复杂度有着关键的影响，我称之为系统架构。
介绍几个软件架构设计时可以遵循的原则：
软件设计原则是设计模式的基石。目的只有一个，降低对象之间的耦合，增加程序的可复用性、可扩展性、可维护性。
开闭原则 OCP
定义：软件实体对扩展开放，对修改关闭。
- 对扩展开发，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。
- 对修改关闭，意味着类一旦设计完成，就可以独立的工作，而不要对其进行任何的修改。
在面向对象设计中，我们通常通过继承和多态来实现OCP，即封装不变部分。
比如需求要实现2种状态的业务。
- 如果用if else来判断，那么后面加第三种状态，就还需要在此接口上增加else逻辑，不符合开闭原则。
- 用策略类实现，则定义策略接口，策略A和策略B为具体实现类，分别对应两种状态。假如下一次需求要实现第三种状态，那么直接定义一个StrategyC实现类就可满足。原有代码不变，符合开闭原则。
里氏替换原则 LSP
定义：程序中的父类型都可以正确的被子类型替换。
程序中的对象可以在不改变程序正确性的前提下被它的子类所替换，即子类可以替换任何基类能够出现的地方，并且经过替换后，代码还能正确工作。
根据LSP的定义，如果在程序中出现使用instanceof、强制类型转换或者函数覆盖，很可能意味着是对LSP的破坏。
假设定义一个抽象禽类，有一个飞翔方法fly(), 我们就可以自由的继承禽类衍生出各种鸟儿，并调用其飞翔方法。如果鸵鸟加入禽类行列，继承禽类，但不会飞，那么飞翔方法fly()就显得多余。而且在所有禽类出现的地方，无法用鸵鸟替换（此时不满足正确业务逻辑）。违反了里氏替换原则。
经过反思，是设计问题，禽类和飞翔无必然联系，所以禽类不应该定义飞翔方法fly()，把禽类飞翔方法fly()抽离出去单独定义飞翔接口Flyable。
对于有飞翔能力的鸟儿继承禽类并实现飞翔接口。鸵鸟继承禽类，但不实现飞翔接口，是否是鸟儿取决于是否继承自禽类，能不能飞取决于是否实现飞翔接口。所有禽类出现的地方都可以用子类进行替换，所有飞翔接口出现的地方都可以被其替换为实现。
依赖倒置原则 DIP
定义：模块之间交互应该依赖抽象，而非实现。
DIP要求高层模块不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖细节，细节应该依赖抽象。
比如某个人喂养小动物，如果依赖了具体的实现，则每新增一个动物，需要在Person内加一个对应的方法。违背了开闭原则，也不符合依赖倒置原则。
重新修改后，如下。新增一个Birds抽象类，具体的动物继承自父类Birds,Person中的方法参数依赖于抽象，而不是具体的实现。符合依赖倒置原则。
单一职责原则 SRP
定义：对任何类的修改只能有一个原因。换句话说，一个类只应该负责一项职责。
SRP要求每个软件模块职责要单一，衡量标准是模块是否只有一个被修改的原因。职责越单一，被修改的原因就越少，模块的内聚性就越高，被复用的可能性就越大，也更容易被理解。
举例员工类 Employee，开发工作变了，需要修改Employee类，测试工作变了需要修改Employee类，不符合单一职责原则，类的复杂性也高。
- 职责多，引起此类变化的原因也多。后续变更的风险就大。
- 后续需求变更，会造成职责的混乱，类结构的不稳定。
改造后，类的职责单一。开发者的职责就是“写代码”，那么对其进行的修改只有与“写代码”相关的一个原因(画类图也是为了指导代码落地)，这样才能确保类职责的单一性原则。
同时，类与类之间虽有着明确的职责划分，但又一起合作完成任务，它们保持着一种“对立且统一”的辩证关系。
- 以责任链模式为例，每个处理者类职责清晰，只处理与自己职责相关的业务。
- 以员工类为例，拆分后，各个员工完成相应的职责，共同保障项目上线。
这种清晰的职责范围划分就是单一职责原则的最佳实践。符合单一职责原则的设计能使类具备高内聚性，让单个模块变得简单易懂，如此才能增强代码的可读性和可复用性。并提高系统的易维护性和易测试性。
上面的例子是类职责单一，那么微服务划分也同理，采用单一职责原则，每个服务负责一块业务。同一类业务的变更落在单个服务内变更。
接口隔离原则 ISP
定义：客户端对类的依赖基于最小接口，而不依赖不需要的接口。
接口隔离原则认为不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口要好。做接口拆分时，也要尽量满足单一职责原则。将外部依赖减到最少，降低模块间的耦合。
比如类A只需要使用方法1、方法3，类B只需要使用方法2、方法4，但在源代码层次上与所有方法形成依赖关系。这种依赖意味着我们对接口I的方法2修改，即使不会影响A所依赖的方法1、方法3的功能，也会导致它需要重新部署和编译。
改造后，类A不需要用到方法2、方法4，就可以选择不依赖它们。代码更加清晰，接口职责更加明确。
迪米特法则 LOD
定义：一个类对于其它类知道的越少越好。
迪米特法则也被称为最少知识原则，它提出一个模块对其他模块应该知之甚少，或者说模块之间应该彼此保持陌生，甚至意识不到对方的存在，以此最小化、简单化模块间的通信，并达到松耦合的目的。
反之，模块之间若存在过多的关联，那么一个很小的变动则可能会引发蝴蝶效应般的连锁反应，最终会波及大范围的系统变动。我们说，缺乏良好封装性的系统模块是违反迪米特法则的，牵一发动全身的设计使系统的扩展与维护变的举步维艰。
门面模式和中介者模式是迪米特法则极好的范例。 Tomcat中 RequestFacade类就使用了外观模式。RequestFacade是对Request类封装，屏蔽内部属性和方法，避免暴露。
合成复用原则 CRP
定义：优先使用合成/聚合，而不是类继承。
比如对象的继承关系是在编译时就定义好了，所以无法在运行时改变从父类继承的实现。子类的实现与它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或被其它更适合的类替换。这种依赖关系限制了灵活性并最终限制了复用性。
合成（组合）和聚合都是关联的特殊种类。
- 聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；
- 合成则是一种强大的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
合成/聚合复用原则好处：优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模。
举例：手机软件划分可分为QQ、微信等，按品牌划分可分为华为、小米等。如果同时考虑这两种分类，其组合就很多。往下继续扩展软件、手机品牌，都会新增许多子类。违背了开闭原则，也限制了复用性。
用聚合关系实现的类图：后面新增软件，手机品牌类不用变更代码。继承的层次也少了。
常用的几种架构设计
分层架构
分层架构是指基于具体的业务模型按照功能模块将代码进行分层组织。每一层代表了一组相关功能的集合。具体分为几层没有明确的规则，通常可以分为3-4层或者更多。在分层架构中，依赖关系是由上往下，上层依赖于下层，不能反向依赖。越往下的层次越通用，偏向于基础能力。越往上层次越动态，偏向于业务。
分层架构设计按照依赖规则的严格程度分为严格型分层架构和松散型分层架构。严格型分层架构要求每一层只能访问其直接依赖的层，不能访问其间接依赖的层。松散型分层架构允许每一层访问位于其下方的任意一层。严格型分层架构使得各个层之间的耦合度降到最低，但是灵活性不足，当上层需要访问下面间接层的能力时必须从上往下层层穿透。松散型分层架构在保证依赖规则的前提下提供了足够的灵活性，所以大部分分层架构都是松散型的。
分层架构设计简洁易懂。对抽象事物按照基础特征进行分类，符合我们的思维习惯，易于理解。分层架构设计保证每一层内部有较好的内聚性，减少了层与层之间的耦合度，易于基础能力的沉淀和复用，也易于控制变更带来的风险。
另外一方面，分层架构设计虽然定义了多个层，但是层与层之间的边界并不是特别清晰。对于新增的模块有可能难以确定应该放在哪一层。或者随着业务逻辑的变化，未来可能需要调整模块所属的层次。分层架构中，上层模块对下层模块有直接的依赖，下层模块的实现直接向上层模块暴露。在修改或者替换下层模块时需要修改上层模块，对上层业务的影响较大。业务实现与基础能力没有完全解耦合。
六边形架构
又称为端口-适配器架构。为了解决具体实现依赖于基础能力的问题，采用依赖倒置设计方法将工程分为内部和外部。内部是具体的业务逻辑，外部是依赖的基础能力。内部业务逻辑不再直接依赖于外部基础能力，而是都依赖于其抽象定义。使用依赖注入的方式将外部实现传入内部业务逻辑中。内部和外部使用接口进行交互，内部业务逻辑访问基础能力时直接调用其抽象接口即可。
六边形架构解决了业务逻辑直接依赖外部模块的问题，它们都依赖于抽象，不依赖于直接的实现和细节。它们直接通过定义好的接口进行交互。因为业务逻辑和外部模块没有直接的依赖关系，在修改和替换外部模块时只需要按照接口定义实现功能，不需要改动业务逻辑。
洋葱圈架构（整洁架构）
洋葱圈架构又称为整洁架构，结合了分层架构、六边形架构和领域驱动设计特点的架构设计方法。洋葱圈架构是对六边形架构的进一步扩展，依赖关系依然是外部依赖内部。参考领域驱动设计，将依赖层次划分为3-4层甚至更多。从内向外依次为：领域模型、业务逻辑、领域服务、基础能力、外部模块等。
洋葱圈架构具有六边形架构的优点，采用依赖倒置的原则使内部业务模型不再直接依赖于外部基础能力。外部模块的变动和替换不影响内部业务逻辑。采用领域驱动设计的方法划分实体和模型，利于业务规则的抽象和业务模型的建立，对未来业务迭代的支持较好。洋葱圈架构使业务实体、业务模型和业务实现处在里层，保证了业务模型和实现的稳定，避免受到外部模块变动的影响。
例如，使三方SDK或者数据库系统属于最外层，使用依赖注入的方法将它们的实现传入内部逻辑。当替换三方SDK或者数据库系统时，按照接口定义实现具体细节即可。不需要对内部逻辑进行改动。
DDD
领域驱动设计简称为DDD（Domain-Driven Design）。准确来说它不是一个架构设计方法，而是一种以业务分析和划分来驱动系统架构设计的软件开发方法。它强调识别业务的核心问题域来确定问题边界，同时将问题域进行分解降低分析的复杂度。DDD强调通过关注业务核心提升业务价值。
下图是我总结的DDD的架构的全貌介绍：
下面是DDD的一些核心概念，我们做一些简单的介绍。
领域：有确定的范围和边界的业务问题域。实际上是我们要解决什么业务问题的抽象描述。比如提供给用户当前位置、目的地位置且提供到达信息是高德地图的问题域。
子域：将大的问题域根据业务规则的不同拆分成的小问题域。比如高德地图的问题域太大了，难以解决。我们可以将问题域拆分成定位、POI搜索、路线规划等子问题域。
界限上下文：领域之间的抽象边界。封装了领域内的概念、规则和模型。
实体：具有唯一标识的、存在生命周期的对象。比如展示给用户可见的POI气泡是一个实体，它有状态和确定的生命周期。
值对象：没有唯一标识和生命周期的对象，依附于实体而存在。比如POI信息是值对象，本身没有状态，只能依附于POI气泡这个实体而存在。
聚合：领域内一组实体、值对象的集合。封装了集合与外界的交互
使用DDD对业务问题进行分析和拆解后，可以采用任何一种架构设计方法，无论是分层架构、六边形架构或者整洁架构等。但是DDD要求架构设计从实际的业务场景出发，理解业务的核心问题。架构需要明确概念、规则的设计，并且保证业务模型的稳定性。使用分层架构展现DDD的领域设计方法，将工程分为4层：基础设施层、领域层、应用层和用户接口层。
工业4.0
我们用大量的篇幅说了软件开发的复杂度，架构设计规范，几种常见的架构方式，我认为这些是在架构领域一些本质和核心的知识，虽然比较抽象，但是一个架构师毕生可能都在这些理念当中游走，
这是我们首先要认知的东西，思想上认同这些核心，然后在实践当中努力思考做的系统是否对齐了这些理念，还可以对别人的系统进行思考，然后总结，只有在不断的思考、好奇、总结当中才能打破自己的边界，知识边界、认知边界。
前几天看到吾辈楷模野生钢铁侠从菊场离职了，我就知道他待不长，他只有离职了才是原来的钢铁侠，这类人的抱负和理想我是最了解不过的了，因为我看到了自己的影子。
在企业级系统领域开发了这么多年，从毕业到现在，一直没有停过，确切的说从大二就开始java开发这条不归路，别人开黑，我在学习java，别人上自习，我他妈也在学习，别人放寒假暑假了，我还是在学习java，不断的coding，去厂子打塑料件，和老刘我们他娘的还在coding java，工作了以后，在济南华为，在杭州连连，在蚂蚁集团，还在这片江湖上燃烧着火之意志，从之前的各种眼花缭乱的技术框架学习，到现在专研架构，回想这一路，真是刺激，一个技术人员能为此疯狂七八年，那真的是渗透到了骨子里，大学里边的老刘、草莓、君才他们也是这样从高校阶段自学开始的，不知道他们现在是否还有这个技术热情，老刘应该还有，这货打了火之意志的思想钢印，草莓、君才难说了，生活和现实让很多东西很难坚持，梦想成了饭后唠嗑的笑话，剩下的都是随风飞舞的无奈。
我觉得32岁开始，男人的人生道路会出现一个分水岭，要么曲线开始爬升，要么曲线开始缓缓下降，埃隆马斯克30岁拥有了PayPal，32岁合并了ebay。
这个时间点一直在暗示我，是时候转移赛道了，为了第二次火之意志的燃烧，flight for freedom!
在吾辈楷模稚晖君的引领下，我开始计划长久的攻城策略，开始打持久战，嵌入式Linux开发是我的技术生涯里边一直想要补充的一个版块，没有这个版块是不完美，是残疾的技术栈，它不符合火之意志的指导方针，不认同三个代表，没有落实科学发展观，也不符合中国梦的蓝图。
我做了一个思维导图，我在做这个导图的时候，回想起来当初在暑假学习各类java框架的时候的感觉很相似，同样充满了未知、东西太多、看不懂，这种感觉就像你有一桶汽油，但是一直没有遇到明火，但是在不经意的写作当中擦出了静电。
我目前还在电路设计能力-数字电路设计-接口设计里边攻城拔寨，接口设计这部分已经快学完了，剩下的就是不断的coding强化。
配套的军火如下：
另外配套如下教学：
运动挑战
总体来说
- 一次开年开局跑，2022图形
- 参加了一次半程马拉松
- 越野-野玫瑰路线
- 越野-圣诞树路线
- 越野-爱情鸟路线
- 骑行-千岛湖27km
- 夜爬-怡情
- 越野-标毅路线
没有达到我心中的的要求，按照计划是每个月一次越野，由于各种乱七八糟的事情，没有实现目标。
思考
不要尝试去改变别人，这是失败的开始，一个人在你面前能说这样的话，做这样的事情，并不是偶然的，他的经历、他见过人、听见的事、走过路，童年晚上放学一次仰望星空都会作为构建一个人认知的组成部分，你去改变他/她，就是等同于改变ta的历史，我的一个发小今年来杭州找我玩，喝了一顿酒，借着酒劲，他说出了她婚后很多不堪，说到他和他老婆之间很多争吵，家里一片狼藉，后来了解到，他老婆不满意他的很多行为，一直在逼我的这个发小去改变，我的这个发小在逼迫之下一个月没有回家，我听到这里，就知道，他老婆的原因最大，因为她无法改变一个活了将近30多年的人的习惯和认知，出现裂缝是必然的，后来去劝他回家，最近他确实回家了，惊奇的是他老婆反应过来这个事情了，承认逼迫一个人按照自己喜欢的风格去生活是自私的，古人云：君子和而不同，小人同而不和。他老婆也是做了一次君子。
认识自己，向内求，强势文化的人和弱势文化的人本质区别是强势文化的人向内求，同时遵循了第一条，不去改变别人，这个在生活、工作、感情当中都可以流通，尤其是在感情里边，把自己的事情做好，就是维持稳定的第一要素，对方不管做什么事情，好事坏事，统统和你没关系，是对方的认知促使ta做了这件事，火影忍者里边的宇智波鼬说过：【每个人都依靠自己的知识和认识，却又被之所束缚，还将这些称之为现实。但知识和认识是非常暧昧的东西，那个现实也许只不过是镜中花水中月】。 只有现实才能改变一个人的认知，认识自己就是把蛋糕做大，对于工作上来说，也是如此，你是一个leader，你给下级说了很多道理，做事情的方法论，但是实际上整个团队交付的产品还是有各类失误造成的瑕疵，为什么？道理是非常抽象的东西，你作为leader你经历过，你说的每一句话都是有实际的case作为背书的，而你的下级认为这就是一句普通的大道理，甚至他们会认为这是PUA，内心还会骂娘：去你骂了隔壁的吧！你算老几，和我谈人生。。。正确的做法是让下级去经历，让他们去犯错，从实际当中总结经验教训，建立自己的认知和知识体系，这才是正确的提拔栽培之道。
养成思考问题的习惯，我们工作和生活每天都在进行，每天来来回回就是那么点儿事，坏事常见，好事少有，你和我差不多，我和他也挺像，为了眼前和手上的烂事糟心着，没什么意思你知道吧，也没有多难过，就是觉得没意思，一点意思都没有。 很多人都会有这样的感受，行尸走肉一般，时间久了终会成为一座山，把你压垮，比如平时上班写完增删改查的代码就开始摸鱼，突然有一天裁员了，技术积累和架构设计积累都没沉淀，草草走人，因此日常工作需要思考，也就是卷，互联网的江湖如逆水行舟，不进则退，这是客观规律，不以人的意志为转移，你选择上进就要去思考，你选择摆烂就会被时代的洪流冲走，而冲走的到了下游都是枯枝烂叶，一步退，步步退，消极的溪水汇聚到了一起，终会影响到你的人生的各个方面：婚姻生活稳定性、工作可被替代性、个人健康，悲剧的人生都是从小的负向沉淀汇聚为江河湖泊成了悲剧。所以这条在很多择偶市场上也会出现，要求上进心，有自己喜欢的爱好或者事业等等，男女通用，这种正向积极的生活态度，标记着配偶将来会有好的资源，利于繁殖和基因传递。天下事，一切都在理性系统的支配之下。
谈一下哲学
最近看了一下西方的哲学历史，对个人主义，自由主义有了一些个人的认识，仅仅作为娱乐，胡说八道，哈哈哈。
个人主义与现代文明
为什么东方人习惯于将自身置身于一个集体中思考问题呢？
为什么一代一代的人为了家庭和孩子牺牲了自己的全部， 但却每一代都过不好自己的一生？
当年，进几十年有了明显的改变，我们东方的宗族观念逐渐崩塌。丁克，独身，离婚越来越多。
人们逐渐抛弃了集体的观念，我们不会再为了集体放弃自己的生活，这一些改变都是因为我们思考世界的方式改变了。
东方的集体主义逐渐被西方的个人主义取代，可以毫不夸张的说因为西方个人主义的产生，我们才出现了现代文明。
不管是个体自由，市场自由，还是现代的民主政治自由，都依托与个人主义的观念之上，但是，个人主义在东方又面临着诸多的误解，
很多人对个人主义的理解就是自私，自利，一切以个人为中心，这些乱七八糟莫名其妙的解读让个人主义在东方长期成为一个贬义。
这造成了一种大撕裂，虽然人民早已经用个人主义的方式在思考问题，但是对个人主义却充满了偏见和误解。
首先需要明确的是个人主义是文明发展过程中的一个bug，因为不仅仅是东方，全世界都活在集体主义或者集体主义的变种里。
唯独欧洲诞生了个人主义，在个人主义诞生之前，人类社会从来都是少数人统治绝大数人，绝大多数人都是任人摆布的工具人，在集体主义中人没有自我，
也没有自我意识，他们心中只有家庭、集体宗族、民族、国家等概念，个体从来不重要，这导致了人们思想和创造力的匮乏，因为人不是主主体，而是集体视角下的
一个客体。
因为个人主义的发展非常复杂，他贯穿了整个西方思想史我们今天试着做一个极简的推到。
第一个阶段，古希腊的个人主义的萌芽，古希腊的普罗泰格拉提出：人是万物的尺度，整个观念奠定了个人主义的萌芽。
普罗泰格拉强调以人的个体感受去获得知识，以欲望和私利作为道德的目标，这是我们现在已知的，最早的个人主义。
第二个阶段，希腊化时代个人主义崛起， 亚历山大征服欧洲后希腊消亡，欧洲进入到希腊化时代，希腊化时代欧洲烽烟四起，战火蔓延，
人们关注城邦的公共精神逐渐退出舞台，因为外部世界不受控，人的精神世界被迫向内挤压，退缩到内心世界，个人主义在这个阶段积累了强劲的势能。
第三个阶段，亚多斯学派提出自然平等的观念，斯多亚学派是西方第一个阐述了人人生儿平等，权利是天赋的一个学派，这个观念到现代一直都是西方的核心观念，因为这种理论
斯多亚学派的信仰者囊括了从罗马皇帝到奴隶的各种阶层，斯多亚学派是西方人人平等的启蒙思潮之一，比如斯多亚学派的塞内加说：对人类而言，人是神圣的。
这种把个体推崇到神圣的地步，无疑是个人主义崛起的重要源头。
第四个阶段，文艺复兴和宗教改革的直接作用，我们知道文艺复兴的核心是人权向神权发起挑战，在中世纪的神权时代，人是神的客体，人怎么想不重要，神怎么想才重要。
而在文艺复兴人从客体成为主体，世界、万物、甚至神都成为客体，文艺复兴催生了人的觉醒，普通人开始思索和挖掘自我的内心世界，人类的内在力量得以慢慢释放。
其实在这四个阶段之外，还有一个最重要的推动作用， 那就是基督教，基督教对个人主义的推动来源于两次改革：
第一次，是以赛亚对犹太教的改革，犹太教先知以赛亚完成了对犹太教对祭司阶层的变革，让人与神点对点沟通，他删除了祭司阶层。
作为西伯来的先知，以赛亚认为如果一个宗教有祭司的产生，那么祭司阶层必然会成为特权阶层，它会垄断人与神之间的交流，同时，如果有祭司阶层就会有腐败产生，
于是以赛亚打破了犹太教的祭司阶层，对早期的犹太教的发展起到了至关重要的作用，他把人们对神的信仰带入到人们的内心，对个人主义的发展起到了决定性的作用。
第二次是马丁路德的宗教改革，宗教改革对个人主义推动至关重要，因为宗教改革为人们重塑了一种观念，在宗教改革之前，祭司阶层，即罗马教廷掌握了信仰的评估体系。
人们和神的沟通由这祭司这个中介完成，而宗教改革从理论层面，自一次删除了祭司阶层，同时基督教认为神创造了人，并且赋予了每个人灵魂，这种观念给了西方人存在的意义。
以及它作为人的基本权利，在浩渺的人生荒原上，每个人都是孤独的行者，他们只能沟通唯一的存在那就是神，在这种渺小的个体和全能的神之间的对立中，个体对自我的思索慢慢浮出水面。
所以我们可以知道，欧洲的哲学思想传承和基督教精神共同塑造了个人主义，个人主义的产生从根源上改变了人的主体性，让人对自我和世界都有了一次全新的思考，正是因为这些改变欧洲开始
焕发了巨大的活力和创造力。他成为人类现代文明的一种基石。
自由主义为何让世界分裂成一万个平行宇宙
自由主义作为西方哲学的重要概念，自由主义到底是如何产生的，古典自由主义和新自由主义的区别又是什么？
我们先看2个命题：
命题一,世界是由水组成的—泰勒斯
命题二，幸福就是在城邦和人坐地起扛—-苏格拉底
你不用判断这2个命题的对错，你需要判断的是这两个命题有什么本质的不同，有网友立刻会想到，这2个命题的本质区别是命题一是实时判断，命题二是价值判断。
西方文化之所以衍生出事实判断和价值判断2种命题范畴并且形成了学生必须掌握的一种逻辑思维训练工具，和自由主义的诞生有着莫大的关联。
在自由主义诞生之前的古典时代，就是古希腊时代，人们认为追问幸福是什么，和追问世界是由什么构成的一样他们都有着明确的答案，希腊人认为什么是幸福，什么是自由，什么是勇气，什么是爱，这些问题和宇宙中有多少颗星星，太阳的表面温度有多高一样，他是一种客观存在的实体，有标准答案。
这就是说在古典时代，人们认为价值观和自然客体一样，存在着唯一答案，只是因为我们的智慧不够，暂时还没有找到这种答案的本质，因为古典时代把价值观当成实体，所以在中世纪及中世纪后期的宗教改革中，因为价值观的分裂人们开始岗捍卫自己的价值观，而展开了漫长的斗争，宗教战争彼此起伏，人们生活在动荡，困苦和信仰危机中，人们的价值观经历了巨大的碰撞，对抗和融合。于是欧洲人开始反思，我们内心追寻的价值真的是一种实体吗？他有标准答案吗？天主教和新教的分歧真的不能调和吗？基督教世界和伊斯兰世界有达成共识的可能吗？在这种反思下，自由主义在欧洲诞生了。
所谓自由主义就是提倡文化的多元，价值的多元，尊重不同思想，不同信仰人的内心秩序，把所有的美好、幸福、审美价值偏好等等全部交给个人去选择，自由主义实现了一个伟大的转向，他把公共权利赶出了人们的内心，从此公共权利只关心秩序和安全，他不在涉足人们的内心自由主义的起源还有另外一个观点，他们认为自由主义的诞生和西方个人主义的诞生同时发生，他们都起源于亚里斯多德逝世到斯多亚学派崛起这段时间，这段时间是希腊化时代。
随着亚历山大的征服，欧洲战火蔓延，人们从关心城邦政治退缩到关心自己的内心世界，于是个人主义诞生，自由主义也在个人主义的基础上开始诞生。
自由主义的诞生无疑是人类文明的一个伟大时刻，从此人类文明产生了一个划时代的转向，人们知道人们内心的认知不是一种实体，不同的人不需要遵守一套共同的价值观，人们把内心的价值从科学和政治哲学抽离出来，科学和政治哲学负责外向探索自然的本质和秩序，而另一条是通往人们内心的探索，关于幸福，关于爱情，关于美，关于自由等等，这条路催生了自由主义和个人主义。
无论是源于宗教改革，还是起源于希腊化时代自由主义的诞生都是人类文明慢慢长夜的第二个火炬，而且可能是最亮的那只火炬，在自由主义诞生之前没有一种文明一种宗教，会把价值层的认知和对自然客体的认知区分开来，大多数文明不能容忍不同的意见，不同的价值观，他们认为价值观就是一种实体，有标准答案，不符合标准答案就是一种异端邪说，还是烧了比较安全，因为这种认知大多数文明不允许不同的价值观存在，世界出现了诡异的沉默的大一统。
这种向内和向外的分离，心灵和物质的分离，和笛卡尔的身心二元论、康德物自体现象二元论都有着密切的思想的关联，在笛卡尔后的400年中，人类的外向探索可以说是硕果累累，它产生了辉煌的现代科技，并且征服了星辰大海，现在美帝的马斯克要殖民火星，这是一种伟大的外拓的胜利，然后人类向内的探索不但毫无建树，甚至可以说越来越举步维艰，因为自由主义对不同的价值观的的尊重世界产生了越来越多的对抗，纷争，矛盾，猜忌和战争，时至今日，宗教战争的阴霾依然笼罩着全人类，不同的意识形态的斗争依然如火如荼，人们越来越陷入自我的价值观，而不想再去听他人的解释，所谓的信息茧房正在形成，价值观成为一道永恒的高墙，让无数人身体近在咫尺，而心灵却万里千年，自由主义提倡个人自由个性解放，他主张个体的意志和精神，这种自我意志的张扬和西方的后现代文明融为一体，西方那些颓废的嬉皮士堕落的朋克青年，似乎都成为了自由主义的反面典型。
在自由主义之下，因为价值观的相近形成了社群主义，但不同的社群主义又因为价值观的分裂而产生了更加尖锐的对抗，于是无数的粉丝团，后援团饭圈女孩开始了远征，她们以键盘为武器，以文字为炮火，开始了互联网的世界大战，世界不是在分裂成2个，而是被分裂成无数个平行宇宙，人们渴望的统一的价值观再也没有出现过。
是自由主义错了吗？自由主义的多元价值观导致现代人们逐渐被原子化，而原子化又是现代性中人们普遍孤独的深层原因，自由主义导致了人与人之间形成了永恒的心灵孤岛，这到底是文明的进度还是倒退？
个人主义是否导致婚姻制度的消亡？
让人十分恼火的是明星的离婚事件总是霸占着自媒体的头条，看别人的离婚吃瓜群众自己能兴奋半个月，好像这里边有自己什么事，但确定的是不管是大数据统计还是我们的现实观感，不管是东方的还是西方的，全世界的离婚率都在逐年上升，如果一个现象跨越了中西方文化 的差异，它一定有自己内在的逻辑，那么离婚率全世界逐年走高的原因到底是什么呢？
我们需要向回顾人类的婚姻制度是如何产生的，首先是生育困境，因为直立行走导致了女性骨盆变窄，骨盆变窄导致了生育困难，生育困难导致了女性需要找一个人来做分工协作，于是女性必须拉个男人组建家庭，以帮助自己度过漫长的生育和哺乳期，所以女性的生育困难是婚姻制度产生的第一个源头。
其次是私有制，在私有制之前，婚姻是没有的，大家是出于一棒子敲晕扛回去山洞的群婚状态，当私有制出现后，男性首先要考虑是财产的传承问题，自己的财产到底传给谁呢？传给隔壁老王，有点亏，传给伴侣，伴侣带着你的财产可能还是找了隔壁的老王，怎么算老王都是永远最大的赢家，最佳的方案当然是创给自己的孩子，毕竟这娃还有你的基因，但是传给孩子最大的问题是如何确定孩子的身份，和女性娃永远是自己的娃不同，男性的永恒焦虑是那个从小养到大的娃，不一定是自己的娃，所以男性看到隔壁老王总是血压飙升，这不是你的问题，这是基因带来的永恒焦虑。
于是子嗣的血缘就显得非常重要，男性必须垄断性伴侣与实现血缘的确定性，于是婚姻产生了，可以看出女性的生育困境和男性血缘伦理的要求，共同导致了婚姻的出现，不管是东方还是西方，婚姻都是一种自发秩序，它的本质是血缘传承，是分工协作，是资源整合，是宗族联姻，是政治博弈，
唯独无关爱情。
世俗的婚姻千篇一律，崇高的爱情万里挑一，婚姻乏善可陈，爱情却十足珍贵，比如一篇孔雀东南飞之所以被传颂至今，正是因为婚姻中爱情的稀缺性，婚姻只会涉及资源的整合，比如在欧洲国王的子嗣婚配对象不可能是平民百姓，如果贵族奔着爱情寻找婚姻，会付出惨痛的代价，比如权游中罗伯去了平民女子，最终导致了血色婚礼的发生，这在欧洲历史上都有原型，而现代社会使用爱情取代了前文明社会中以资源整合为基础的婚姻，为什么会出现这种变化呢？这一切都是因为个人主义的产生。
罗素认为人主义可以追溯到古希腊的犬儒学派和斯多亚学派，在希腊消亡以后的希腊化时代，希腊人被迫从公共生活退缩到内心，他们不再关注城邦，而是在自己的心灵中独善其身，个人主义从此诞生，后来文艺复兴和宗教改革也促进了个人主义的发展，人们从神权中走出，开始认识到自我的意义和价值，认识到个体才是万物的尺度。
个人主义和其他思想最大的不同是人们到底是用什么标准评价和思考这个世界，在这个人主义之前，个体的价值由社会和他人赋予，比如社会评价你是一个怎样的儿子、丈夫和父亲，你有没有做到忠孝两全，你有没有做到义薄云天，个体的所有价值都掌握在他人手中，但是当个人主义出现，个体的价值不再仅仅由社会赋予，而是由他个体内心的感受决定，这种价值的内心化，评判的个体化，导致了欧洲文明的大转向，集体主义、宗族主义被抛弃，人们把所有的判断交给个体交给内心，我的内心即为整个世界。
这里插一句题外话，个人主义的诞生非常重要，他是西方出现文明大升级的关键因素。
因为除了欧洲之外，全世界绝大多数文明，都是集体主义的变种，只有在西方诞生了个人主义，因为个人主义一切从自己出发，它导致了婚姻制度的根本性改变，那些传统婚姻基于分工协作、传宗接代、宗族联姻都不在重要，“我喜欢”才是最重要的。
那么以爱情为基石的婚姻，为什么有可能瓦解婚姻制度呢？
首先，，恩格斯在《家庭、私有制和国家的起源》中指出，如果以爱情为基础的婚姻是合乎道德的，那么只有继续保持爱情的婚姻才会继续合乎道德，恩格式的这句话无疑洞悉了现代婚姻的本质，
当爱情不在的时候，以爱情为基础的婚姻也就不可能存在了，其次，爱情的流变性导致失望情绪的蔓延，因为爱情是一种玄学，不但科学解决不了，哲学也无能为力，爱情不但玄之又玄，而且极易流变，当昨天的梦中女神，成为今天的枕边悍妇，当曾经的大长腿欧巴成为渣男，爱情就消失了，而这种爱情的消失，导致人们普遍流露出失望的情绪，如果一个人能凭借着爱情组建婚姻，那么ta很大程度也会走向失望，那些能够白头到老的更多是处于一种相对封闭的环境中，他们的价值观改变不大，如果是2个人的价值观不断流变，那么大概率的结果就是分道扬镳。同时在爱情为基础的婚姻观下，婚姻成为人们实现自我的一种途径，他们认为婚姻应该是玩乐，而不是任务，婚姻应该是让人兴奋的，而不是让人厌倦的，婚姻应该是充满了激情的，而不是充满亲情的，当然们在婚姻生活中感受不到这种情绪后，分道扬镳就会自然产生。所以因为个人主义的崛起，人们对婚姻观念发生了翻天覆地的改变，他最终导致了越来越多的离婚发生。
至于个人主义会不会颠覆传统的婚姻制度，以上是我个人的推论，不代表个人对婚姻爱情的看法，仅仅是逻辑推理过程，实际情况需要实事求是。
如果你觉得我的文章有用，可以打赏我一杯雀巢咖啡
