https://yrunz.com/tags/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/ Recent content in 读书笔记 on 元闰子的邀请 Hugo -- gohugo.io en-us Sun, 09 Mar 2025 00:00:00 +0000 https://yrunz.com/p/%E8%B5%B0%E6%8A%80%E6%9C%AF%E8%B7%AF%E7%BA%BF%E9%9C%80%E8%A6%81%E4%BA%9B%E4%BB%80%E4%B9%88/ Sun, 09 Mar 2025 00:00:00 +0000 https://yrunz.com/p/%E8%B5%B0%E6%8A%80%E6%9C%AF%E8%B7%AF%E7%BA%BF%E9%9C%80%E8%A6%81%E4%BA%9B%E4%BB%80%E4%B9%88/ 荐语 本文要介绍的是O’Reilly在2022年出版的书籍，《The Staff Engineer’s Path》。 书中主要介绍走技术路线的工程师，或者说技术专家（Staff Engineer），需要具备哪些能力他们不仅仅要会写代码、做系统设计这么简单，技术能力只是基础，还要具备大局观、执行力和影响力。 如果你想走技术路线，那么本书值得一读。 前言 程序员的发展，总会遇到一个分叉路口，走技术路线，或者管理路线。 程序员总有股技术情怀，相信很多人最初都有坚定走技术路线的想法，但走着走着，最后都走上管理路线。 一方面，管理路线是清晰的，且有着大量成功的案例。对于沟通能力强、临危不乱、善于帮助周边同事成长的人来说，似乎成为管理者是一个常见，也是默认的职业发展规划。 另一方面，走技术路线，在很多人的理解里，就是不断提升技术能力。但是，这样走了一段路后，很可能就会遇到了向上发展的瓶颈，而转向管理路线。于是就有了所谓“不能一直搞技术”的结论。 然而，走技术路线遇到发展瓶颈的原因，并非是“不能一直搞技术”，而是“不能只搞技术！” 要走好技术路线，成为一名技术专家，拥有扎实的技术功底只是基础。除此之外，还需要具备全面的大局观、强大的执行力、良好的影响力三大能力支柱。 下面，我们将从技术专家的角色定位讲起，随后介绍这三大能力支柱，让你对“技术路线”有更深刻的理解。 技术专家是个什么角色？ 提到技术专家的角色定位，我们可能首先会想到“关键方案设计和开发”、“疑难问题解决”、“技术决策”，但还不止这些。 不是Manager，但也是个Leader 首先，技术专家也是一个Leader。 在技术路线上，深入技术领域只能让你走到高级工程师这一步，要想成为技术专家，主导更大的项目，你需要与更多的人沟通协作、说服他们接受你的方案、成为他们的榜样。 所以，技术专家不可避免地要成为一个Leader。 与Manager不同，技术专家通常没有直接下属，不负责人员管理，但他们同样需要在技术决策、设计和代码review等方面表现出领导力。 是个技术牛人 技术专家是一个高度专业化的角色。 你提出的设计和代码review意见，要有指导意义，能够让产品的代码和架构变得更好；做技术决策时，要理解各类因素的权衡，必要时能够深入代码细节，提出正确的问题。 所以，技术专家必须要有扎实的技术基础。 但这并不意味着技术专家要写大量的代码。为了高效地解决问题，很多时候，他们负责方案设计、指导中高级工程师完成编码，可能更有意义，这也是给其他人更多的成长机会。 牢记一点，技术专家最重要的是解决问题，而不是如何解决，代码、文档，都是一种方式。 了解了技术专家的角色定位，接下来本文将介绍技术专家所需要的，除技术基础之外的，三大能力支柱：大局观、执行力、影响力。 大局观 一个不断发展的组织，总会进行各种各样的决策：选择什么技术、打造什么产品、继续投资或者否决它。一个好的决策需要有详细、准确、全局的上下文知识来支撑。 一名技术专家很可能只是负责组织下某个产品或特性的技术方案，因此，很容易陷入局部最优的困境。 为保证能做出前瞻性的决策，技术专家需要成为一个纵观全局的人。而建立下面的这三张地图，也许能够帮你构筑大局观。 定位图（Locator Map）：广阔的视角 要避免局部最大化，需要建立一张定位图（Locator Map）以获得更广阔的视角： 认清组织目标，找到真正重要的是什么。程序员很容易陷入唯技术论，技术专家要避免这一点。技术只是达成目标的手段，最重要的是搞清楚目标，是组织的目标，不是某个特性或小团队的目标。 理解客户的真正痛点。产品是为用户服务的，就算你的产品能够提升XX百倍性能，没有用户用，一样是没有价值。 了解领域行业动态。你正在解决的问题，很可能业界已经有人解决过。时刻了解你所在行业的动态，才能更高效地解决问题，更好地实现创新。 地形图（Topographical Map）：正确的导航 即使你有很强的技术能力，也可能会遇到好想法得不到重视、风险/困难无法提前识别、项目进展难以推动的情况。这时，你需要建立一张地形图（Topographical Map），帮助你实现技术落地、项目成功： 理清组织结构，建立良好关系。了解你所在组织的结构，理清每个子团队所负责的业务以及关键角色，并于他们建立良好的关系。没错，技术专家也需要懂得“搞政治”，这样才能更好地开展工作。 了解组织文化。你的组织是倡导口头汇报还是书面汇报？鼓励快速试错还是深思熟虑后的变革？了解并融入你所在组织的文化，金子才能更好地发光。 保持地形图更新。为了更好地支撑商业成功，组织结构和人员的变化很正常，时刻更新你的地形图。 藏宝图（Treasure Map）：长远的目标 最后，你需要一张藏宝图（Treasure Map），找到自己的长远目标（通常是组织目标或者能够支撑组织目标的达成），并为之奋斗。 人们很容易过度关注短期目标，比如，当前版本发布的功能、某个用户对产品的差评等。寻求短期成功可能会限制你的发展。 要从更宏观的角度思考： 你想要达到什么目标？ 你为什么要做这些事情？ 这些事情能支撑你的目标达成吗？ 本周的工作是否偏离了你的目标？ 你是否还在不断接近你的目标？ 执行力 技术专家需要很强的自驱力，要学会自己给自己安排任务，主动、提前为组织出谋划策，而不是等待被安排。 所以，技术专家通常会参与多个项目，处理很多事情。但人的精力总是有限的，学会时间和价值管理很重要。 可以尝试按照以下几个维度，为你所参与的项目/事宜进行打分，在有限的时间内完成最有价值的事情： 能量（Energy）：这件事情将会耗费你多大的精力。 生活质量（Quantity of Life）：如果你的工作恰好是你的兴趣，那么你每天的生活质量将会非常的高。但这种机会是可遇不可求的，很多时候工作会降低你的幸福感。 信誉（Credibility）：信誉是领导力的一种体现，主导重要的项目、解决关键的难题，都能帮你提升在组织里的信誉。 社交资本（Social capital）：花时间与他人相处、与他们一起工作，建立良好的社交关系，互为战友。 技能（Skills）：技能是一种需要反复练习才能长久拥有的东西，你的工作内容一定程度上决定了你拥有哪些技能。 如何进行事情的优先级排序，一方面是要契合组织的目标，另一方面，也是你自己的职业规划。 https://yrunz.com/p/%E5%BF%AB%E9%80%9F%E4%BA%86%E8%A7%A3%E7%94%9F%E6%88%90%E5%BC%8Fai/ Sun, 19 Jan 2025 00:00:00 +0000 https://yrunz.com/p/%E5%BF%AB%E9%80%9F%E4%BA%86%E8%A7%A3%E7%94%9F%E6%88%90%E5%BC%8Fai/ 荐语 本文要介绍的是，O’Reilly在2024年出版的书籍，《Generative AI in Action》，作者是来自微软的Amit Bahree。 书中主要介绍了生成式AI的相关知识，涉及LLM、提示工程、模型微调、RAG、向量数据库等内容，作者给出了大量的代码示例，通过实战的方式带读者入门生成式AI。 生成式AI领域发展迅速，虽然本书是在2024年11月出版，但现在看来，书中介绍的技术已经算是“老旧”的了。不过，跟着作者的思路，读者能够快速理清整个生成式AI的技术脉络，有助于后续展开更深入的了解。 生成式AI概述 随着大模型LLM的大热，生成式AI（Generative AI，GenAI）近年来获得了越来越多的关注和普及。如下图所示，生成式AI是AI的一个子领域，演变自深度学习。 传统的机器学习基于统计学对数据进行预测； 深度学习基于神经网络模拟人脑行为，去执行复杂的任务； 而生成式AI则可以从数据中创作，就像我们人类一样。 如下列出了生成式AI与传统AI的一些区别： 传统AI 生成式AI 用途 专注预测和分类任务 从原始数据中创造不存在的内容 硬件 所需算力较少，能够在各种硬件上运行 需要大量算力，通常运行在大规模的计算集群上。 训练数据 较小的标记数据集 大型的原始数据集 模型复杂度 百万级以下的参数数量 亿级以上的参数数量 很多人会错误地把ChatGPT与生成式AI划上等号，实际上，ChatGPT只是生成式AI最简单的应用。生成式AI能做的很多，个人层面，常见的如文字、图像、视频、代码、音乐的生成；企业层面，常见的如个性化营销、消费者服务、风险管控、合同管理等。 总而言之，生成式AI能够弥补传统AI的局限性，帮助用户和企业构建更加智能的应用。 在生成式AI领域中，大语言模型（LLM）作为大脑，能够生成出符合用户需求的内容，下文将简单介绍其原理。 大语言模型 大语言模型（Large Language Models，LLM）是生成式AI的基础，它由基础模型（Foundational model，FM）发展而来，后者在2021年被首次提出。 过去的AI模型通常只能应用于特定的任务，而FM则在此基础上做了泛化性优化，通过大数据量的训练得到了更强的适应性。 早期最具代表性的FM为Google开发的BERT模型，它被广泛应用于自然语言理解（NLU）任务，比如文本分类、命名实体识别等。 LLM是适用于自然语言处理（NLP）和生成（NLG）任务的基础模型，它的模型规模更大，包括参数数量、训练数据集大小、算力资源。 通常，LLM都会在名称上带上参数规模，比如Meta的Llama 2-70B，其中7B表示参数规模为700亿。 一般来说，模型参数越多，性能就越好，最近国产大模型DeepSeek V3甚至已经达到了671B规模。 当然，模型规模越大，就要消耗越多的算力资源，也就意味着更高的经济成本。因此，在一些任务较为简单或明确的场景，用户可能会偏向使用成本效率更优的小语言模型（Small language model，SLM），比如微软最近推出的Phi-4模型，它的参数规模只有14B，但得益于多方面的技术进步，它在数学推理方面超越了同类和更大规模的模型。 LLM的本质是利用当前上下文去猜测下文，但它并不像人类一样能够直接读懂自然语言。因此，必须把输入文本（Prompt）先分块（token），这样才能得到更好的泛化性，接着把它们转换成能理解的格式（Embedding），最后通过特定的算法（Transformer）去猜测出下文。 Token序列 当前，几乎所有的LLM都是基于token的架构，它是LLM处理文本的基本单位。 有多种将文本划分成token序列的方法，常见的如按字划分、按词划分、按句划分等。 划分的粒度越细，模型的泛化性也会更好，但token数量会更多，所需计算资源更大； 划分的粒度越粗，token保留的语义和上下文也就更多，数量也会更少，但遇到陌生词或多义词可能无法处理，依赖构建好的词典。 https://yrunz.com/p/%E4%B9%94%E5%B8%83%E6%96%AF%E4%B8%8E%E9%92%B1%E5%AD%A6%E6%A3%AE/ Sun, 13 Oct 2024 00:00:00 +0000 https://yrunz.com/p/%E4%B9%94%E5%B8%83%E6%96%AF%E4%B8%8E%E9%92%B1%E5%AD%A6%E6%A3%AE/ 乔布斯与钱学森，一位是美国的企业家，带领苹果公司发布一系列革命性电子产品；一位是中国的科学家，帮助国家完成“两弹一星”的伟业。乍看之下，你很难把他们关联起来。 写这篇文章想法的源头是，最近连着把《史蒂夫·乔布斯传》和《走进钱学森》两本传记读完，感受颇深。他们虽然民族各异、身处的领域也大不相同，但都同样伟大。 伟人总有很多相似之处，这也是值得我们学习的地方。 奋斗的天才 他们从小就是天才，却也一生都在奋斗。 乔布斯从小就对电子器件展现出非凡的天赋，年仅 21 岁就与好友沃兹尼亚克创造了第一款苹果电脑 APPLE I，引领的个人电脑时代。论电子信息技术的天赋，乔布斯比不过沃兹尼亚克，他最为天才的地方是对产品的理解，以及强大的”现实扭曲力场“。 乔布斯对电子产品的理解是超前的，从 APPLE I 到 iMAC、从 iPod 到 iPhone，他总能带领苹果发布革命性的产品。他不依赖市场调研，“因为他们并不知道自己想要什么。他们看到我们的产品，才会知道这就是自己想要的。” 乔布斯的“现实扭曲力场”是他的领导力的体现。他能够把自信传递给别人，驱使他们完成自认为不可能完成的事情。这也是苹果公司能够不断创新的主要原因之一。 乔布斯希望打造能够改变世界的产品，并为之奋斗了一生。最让人钦佩的两点是： 在正式二进宫苹果前的两年多时间里，他作为临时 CEO 只拿了 2.5 美元的工资，却要同时管理苹果和皮克斯两家公司，常年奔波于两个公司之间，为后面的癌症埋下了病根； 在患癌之后，尽管身体虚弱，仍领导公司发布了 iPad、iCloud 等革命性产品。 钱学森则更像“别人家的小孩”，从小成绩优异，一路名校，北师大附中->上海交大->麻省理工->加州理工。从“两弹一星”到载人航天、从工程控制论到系统科学、从“山水城市”到沙漠改造，他在众多领域都有大建树；他被美国评价为“无论在哪里，他都值五个师。”；他是真正意义上的天才；他是“大科学家钱学森”。 钱学森能有如此大的成就，除了天赋，也离不开他的努力和保持学习的习惯： 他曾说过，“我不是说大话，我在做空气动力学的时候，关于空气动力学方面的英文的、法文的、德文的、意大利文的文献我全都念过。为了要把它做好，我得这么念，而且还进行了分析。” 他终生保持了阅读和记录的习惯，“钱学森家中，藏有15000多册他阅读过的期刊。”，他习惯剪报来记录资料和信息，“保存的629袋剪报，总共24500多份，整整装满了5个大书柜。” 细节决定成败 他们处事严谨、追求细节。 乔布斯是广为人知的细节狂魔，即使在别人看不见的细节上，也要做得工整漂亮。在做 Mac 电脑时，乔布斯会仔细查看内部的电路板，虽然用户永远不会看到它，但他仍会给出批评意见“这些存储芯片实在是太丑了，这些线靠得太近了。”，这是他的哲学理念，“希望设计能尽可能完美，即使是装在盒子里，没人看到。就好比好的木匠不会用烂木头做橱柜的背板。” 乔布斯对细节的把控，除了体现在产品设计上以外，在发布会的准备上也体现得淋漓尽致。他不仅对演讲稿字斟句酌，认真审阅了邀请人员名单，甚至还检查了午餐菜单。 而钱学森作为一名科研人士，严谨是必备的品性。 细节决定成败。作为导弹和火箭专家的他，尤其懂得每一根导线、每一个焊点、每一个元件都必须绝对可靠。他常跟学生说，“科学上不能有一点失误，小数点错一个，打出去的导弹就可能飞回来打到自己。” 也正是对细节的关注，使得他能够在美国特务的重重监视之下，与国内取得联系，最终回归祖国。 集聚众智 他们是伟大的帅才，他们的背后都有一个伟大的团队。 Mac、iPhone 等划时代的产品，并非乔布斯一人的创意，伟大产品的背后是一个伟大的团队。从刚开始的沃兹尼亚克，到后来的乔纳森·艾夫、蒂姆·库克，乔布斯非常善于识别人才，打造 A 级选手组成的团队，为自己出谋划策。 同样的，绝不是钱学森一人成就了中国“两弹一星”和载人航天的辉煌，他的背后还有任新民、孙家栋、王永志等一大批科技创新人才。正如钱学森所说，“科技帅才不仅个人要具备拔尖的学术水平，还要有本事团结一大批人，统领一大批专家攻克重大的科技难关。” 在钱学森看来，科研成果大都是“集体工作的结晶”。 多学科交叉 他们都是“杂”家。 乔布斯作为苹果公司的创始人，我们很容易把他与“理工科”联系起来。但他不仅是一名只会电子信息的“理工男”，他对美术、音乐、禅修等广泛的领域都有涉猎。他自视为一名艺术家，总是有意识地把自己置于艺术和科技的交会点。在他的所有产品中，“科技总是与精妙的设计、优雅的外观、人文的关怀，甚至浪漫的元素相结合。” 多学科交叉使得乔布斯具有独特的个人品味，当他把这种品味注入到产品时，总能引领时代的潮流。 钱学森晚年总结自己一生科学思想结晶为“集大成，得智慧”。在他看来，人的智慧是两大部分：量智和性智。缺一不成智慧！ https://yrunz.com/p/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95/ Sun, 08 Sep 2024 00:00:00 +0000 https://yrunz.com/p/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95/ 荐语 本文要介绍的是 2020 年 O’Reilly 出版的书籍 Unit Testing Principles, Practices, and Patterns，一本在豆瓣评分高达 9.9 的好书。 作为一名软件开发工程师，你应该对单元测试（unit test）很熟悉，但单元测试的目的、Mock 的正确用法、单元测试和集成测试的区别等等，你真的懂吗？书中对这些内容都做了深入的介绍，并通过实际案例教你如何写出好的单元测试。读完这本书，你一定会有醍醐灌顶的感觉，原来单元测试要这么写！ 书中的另一个重要观点认为，单元测试和代码架构是息息相关的，写不出好的单元测试，极有可能是代码架构设计得不好。为了写出好的单元测试，需要不断对代码架构的优化，它们相辅相成，从而让软件能够持续演进。 为什么要写单元测试？ 单元测试的目的 如今，在软件开发活动中，单元测试已经成为企业级软件不可或缺的一环，是代码门禁的必选项。 如果突然有人问你，“为什么要写单元测试？”，你很容易会想到这样的答案，1）为了找到代码中已有的 Bug；2）为了防止引入新的 Bug；3）让代码架构变得更好；甚至是 4）满足代码门禁中覆盖率的要求。 但这些都不是我们写单元测试的根本目的，它们只是“写单元测试”这一活动所带来的副产品。 书中认为，单元测试的目的是实现软件项目的可持续增长。 企业级软件应用通常都有着业务逻辑复杂度高和生命周期长的特点。随着产品的不断迭代，代码会变得越来越复杂乱，每次修改代码也会变得越来越难，这就是软件的熵增定律。而单元测试的目的就是降低熵增的加速度，使得重构代码或新增功能变得更加的容易。 单元测试也分好坏 代码并非资产，而是一种负债，单元测试代码也是如此。 然而，我们往往会将生产代码和测试代码区分对待，忽略了对测试代码的维护，久而久之，测试代码变得冗余、复杂，甚至出现误报的情况。这样的单元测试，只会让系统的演进更加难。 如何评判单元测试的好坏？最常用的方法是代码覆盖率，也即测试用例执行了多少源代码。其中，又可分为行覆盖率和分支覆盖率。 行覆盖率计算执行了多少代码行，比如下面的例子，return true 的代码行无法覆盖，因此代码行覆盖率为 4/5=80%： // C# public static bool IsStringLong(string input) { if (input.Length > 5) // 无法执行 return true; return false; } public void Test() { bool result = IsStringLong("abc"); Assert.Equal(false, result); } 但是，某些时候行覆盖率并不能放映真实的覆盖情况，比如将上述的 IsStringLong 使用三目运算符进行重构，行覆盖率 3/3=100% 了，但实际情况并未改善。 https://yrunz.com/p/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3lambda%E6%9E%B6%E6%9E%84/ Sun, 21 Jul 2024 00:00:00 +0000 https://yrunz.com/p/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3lambda%E6%9E%B6%E6%9E%84/ 荐语 本文要介绍的是 2015 年 O’Reilly 出版的书籍 Big Data: Principles and best practices of scalable realtime data systems，书中主要介绍一种常见的大数据架构 —— Lambda 架构。Lambda 架构通过批处理和流处理相结合的方法，有效处理了大数据场景下的工作负载。相比以关系型数据库为核心的传统数据系统，它在可扩展性、容错性等方面有了更进一步的提升。 虽然 Lambda 架构是十年前被提出的数据架构，但 Lambda 架构的以不可变数据作为核心、历史和实时数据分层处理的架构思想仍值得我们学习。 传统数据系统的局限 考虑有这么一个系统，根据用户的浏览记录，统计用户访问网页的次数： 在上述系统中，每次用户浏览一个 url，应用就会向数据库更新一行数据。随着用户量的不断上升，并发量急剧上涨，数据库最先达到瓶颈，频繁出现更新超时的现象。针对这种情况，我们可以引入消息队列，将单次写改成批量写，以此降低数据库的并发数。 但这并不是长久之计，随着用户量的再次上涨，单实例的数据库还是会成为单点瓶颈。为此，可以对数据库进行水平扩展，分库分表，将原本集中在单个数据库实例上的请求，负载均衡到多个实例之上。 分库分表虽能消除数据库单点瓶颈，但也会带来其他的一些问题： 应用逻辑更复杂。应用层需要根据数据的 key 找到其所在的数据库实例，以便进行数据更新。 维护成本更高。为了避免因数据库实例宕机导致的服务不可用，需要通过增加数据副本、缓冲队列等手段提升可用性。另外，随着数据量的增大，可能因数据库实例间负载不均衡，而产生对数据进行重分区的操作。这些都会导致维护成本的急剧增加。 容错性问题。一旦开发者在更新数据库时出现人为错误，比如在增加 pageviews 字段时多乘了 2，那么数据将难以恢复，因为很难溯源。 上述例子中，从简单的 CURD，到增加消息队列、分库分表、副本、重分区等，系统也越来越复杂。导致这一切的原因是，传统数据库系统并非为分布式而生，它无法很好地适用于大数据场景。 大数据技术的局限 那么，大数据技术就能解决这些问题吗？答案是，否！ 像 Hadoop、MapReduce、HBase 等这类大数据技术，虽然能够天然就处理海量数据，但它们都有各种局限，比如，MapReduce 是批处理系统，计算时延高；HBase 键值查询快，但无法满足复杂的 SQL 查询场景。 为了找到解决方法，我们还需从大数据系统的本质入手。 大数据系统的本质 作者对数据系统进行了如下定义： A data system answers questions based on information that was acquired in the past up to the present. https://yrunz.com/p/%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E4%B8%80%E5%88%87%E5%B0%BD%E5%9C%A8%E6%9D%83%E8%A1%A1/ Sun, 16 Jun 2024 00:00:00 +0000 https://yrunz.com/p/%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E4%B8%80%E5%88%87%E5%B0%BD%E5%9C%A8%E6%9D%83%E8%A1%A1/ 荐语 本文要介绍的是 2021 年 O’Reilly 出版的书籍 Software Architecture: The Hard Parts（后文简称 SAHP），某种程度上，它是 Fundamentals of Software Architecture（后文简称 FSA）的延续，两本书的主要作者相同。FSA 是基础篇，重点介绍了常见的 8 种架构模式；SAHP 是进阶篇，重点介绍了如何从单体架构演进到分布式架构。 软件架构，特别是分布式架构，是很复杂的。这世上不存在所谓的通用架构模式，针对特定的应用场景，架构师需要在数据一致性、可扩展性、性能等多个因素上进行权衡，这也是本书标题强调的 The Hard Parts。 FSA 里有一句名言，“Everything in software architecture is a trade-off.”。本书的重点就是要教会你，在单体架构演进到分布式架构的过程中，如何众多因素上进行权衡分析，以此来选择出一个符合实际业务场景的软件架构。 为什么叫 “The Hard Part”？ 书的名字叫 Software Architecture: The Hard Parts，其中，Hard 有两层含义。 第一，软件架构很难。设计软件架构需要考虑的因素很多，架构师也必然会遇到各式各样的难题，而且它们往往没有通用的解决方法。软件工程的问题，很多时候可以通过 Google 搜索来解决；而软件架构的问题，只能根据实际的业务场景，在众多的考虑因素上进行权衡。所以，在软件架构上，不要试图找到最好的设计，而是要努力实现最不糟糕的权衡组合。 Don’t try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs. 第二，软件架构是稳定的。Hard 取自于硬件的英文单词 Hardware，相比软件 Software，硬件是更稳定的一个，它是软件的基础。同理，软件架构是一款软件的架子、基础，好的架构通常都是稳定的，不轻易随软件的变更而变化。 https://yrunz.com/p/%E7%94%9F%E6%B4%BB%E6%98%AF%E5%BE%88%E5%A5%BD%E7%8E%A9%E7%9A%84/ Sun, 24 Mar 2024 00:00:00 +0000 https://yrunz.com/p/%E7%94%9F%E6%B4%BB%E6%98%AF%E5%BE%88%E5%A5%BD%E7%8E%A9%E7%9A%84/ 《人间草木》是汪曾祺先生的一本散文集，书分成了五个章节，分别是“一果一蔬”、“季节的供养”、“四方游记”、“联大师友”和“从容而安”，内容很杂，也很有趣。汪曾祺先生的文字很朴实、轻盈，能给人以温暖的感觉。 《人间草木》整本书给我的最大的感受是，文字很朴实、很有趣，作者很温柔、对生活甚是热爱。 汪曾祺先生的文字极朴实，上一个给我这种感觉的作家是阿城。按照阿城的话，“汪曾祺的白话句子，成精了，随手便是。” 同样是朴实，但两人的风格又很不一样。阿城的文字是朴实中带有力量感、给人以极强的画面感，比如《溜索》里面的这段： 那牛软下来，淌出两滴泪，大眼失了神，皮肉开始抖起来。汉子们缚了它的四蹄，挂在角框上，又将绳扣住框，发一声喊，猛力一推，牛嘴咧开，叫不出声，皮肉抖得模糊一层，屎尿尽数撒泻，飞起多高，又纷纷扬扬，星散坠下峡去。 汪曾祺先生的文字是朴实且轻盈、给人以温暖的感觉 ，比如《昆明的雨》里面的这段： 卖杨梅的都是苗族女孩子，戴一顶小花帽子，穿着扳尖的绣了满帮花的鞋，坐在人家阶石的一角，不时吆唤一声：“卖杨梅——”声音娇娇的。她们的声音使得昆明雨季的空气更加柔和了。 所以，《人间草木》读下来，很舒服。 汪曾祺先生知识渊博，很善于把各地方言融入到他的文字里，读《人间草木》最大的惊喜是找到了不少老家方言。 比如藠头（“藠”读 jiào），是薤的鳞茎，外观与未长熟的蒜类似，做法大多是入醋、糖腌制，酸甜、能开胃，现已不多见。一直以为藠头就是蒜头，因其辛辣而不爱吃。年前在陕西吃羊肉泡馍，岳母让店家上了糖蒜，说“泡馍要就糖蒜吃，才地道！”，还以为是一个东西。 比如香蕈（“蕈”读 xùn），就是冬菇，香蕈是南方的叫法。小时候很是好奇，好端端的菇，为什么要叫“xùn”？八竿子打不着。而且这个“xùn”要怎么写呢？ 汪曾祺先生是很热爱生活的，从《人间草木》的引言就能看出来： 如果你来访我，我不在，请和我门外的花坐一会儿，它们很温暖，我注视它们很多很多日子了。 热爱生活本是不易，了解完他的生平，感觉更为难得。汪曾祺先生一生经历过许多坎坷，在反右斗争中被打成“右派”、在“文革”中也进过牛棚，即便如此，他依然保持乐观。 他曾被下放到张家口沙岭子农业科学研究所劳动，摘去“右派”分子帽子后，被派去沽源画一套马铃薯图谱。在沽源，他“远离了家人和故友，独自生活在荒凉的绝塞”，但“日子过得非常悠闲”。每天都是重复的工作，画马铃薯的花、叶子、薯块，“画完一种薯块，我就把它放进牛粪火里烤烤，然后吃掉”，并且颇为得意，“全国像我一样吃过那么多种马铃薯的人，大概不多！”。 汪曾祺先生对吃甚是讲究！他“劝大家口味不要太窄，什么都要尝尝，不管是古代的还是异地的食物”。所以，在《人间草木》里，我们可以找到许多闻所未闻的美食及其做法。他对美食的描写很白话，但总能勾起人的味蕾。 比如豌豆黄： 北京以豌豆制成的食品，最有名的是“豌豆黄”。这东西其实制法很简单，豌豆熬烂，去皮，澄出细沙，加少量白糖，摊开压扁，切成5寸×3寸的长方块，再加刀割出四方小块，分而不离，以牙签扎取而食 比如豇豆： 嫩豇豆切寸段，入开水锅焯熟，以轻盐稍腌，滗去盐水，以好酱油、镇江醋、姜、蒜末同拌，滴香油数滴，可以“渗”酒。炒食亦佳。 比如中吃不中看的干巴菌： 颜色深褐带绿，有点像一堆半干的牛粪或一个被踩破了的马蜂窝。里头还有许多草茎、松毛，乱七八糟！可是下点功夫，把草茎松毛择净，撕成蟹腿肉粗细的丝，和青辣椒同炒，入口便会使你张目结舌：这东西这么好吃？ 汪曾祺先生常被人称作是“生活家”，他对身边的人、事、物都感兴趣，都观察得细致入微。他鼓励大家多积累一点生活知识，在他看来，“草木虫鱼，多是与人的生活密切相关。对于草木虫鱼有兴趣，说明对人也有广泛的兴趣。” 热爱生活，是我们现代人所欠缺的。我们总追求效率、以结果为导向，每天忙碌奔波于工作中。我们总说工作是为了更好的生活，但实际却是，工作让我们忘记生活本就很好。 汪曾祺先生有一句名言，“生活，是很好玩的”，我觉得很对！ （完） https://yrunz.com/p/2023-%E5%B9%B4%E5%B0%8F%E7%BB%93/ Sat, 10 Feb 2024 00:00:00 +0000 https://yrunz.com/p/2023-%E5%B9%B4%E5%B0%8F%E7%BB%93/ 2023 年最重要的是完成了一项人生大事。 生活 我和璐在年初相识、年末结婚，朋友们都说我们进度快。用一位同事的说法，我们在年度项目立项之后才认识，但项目还没结项就已经结婚了，比项目进度还快。其实，若非大家提起，我们俩倒没有这种感觉，反而觉得是相识已久的老朋友，从相识到结婚，每一步都走得很踏实。 与璐在一起之后，生活丰富了许多，我们会一起骑车买菜、吃宵夜、打游戏、追剧、彻夜长谈。有时候，幸福不一定要一夜暴富，俩人一起打卡生活的这些小事情，也会幸福感爆棚。 璐的身上一定有某种光环，跟她相处时会感到很舒适，她的朋友多，“小”朋友更多——家里的小孩、她朋友的小孩、我朋友的小孩，都爱跟她玩，特别是我那小侄女，每次回家和视频都会“璐璐阿姨”的叫个不停。我时常称她为“孩子王”，她总会回以一个得意的笑。 璐是一个很热爱生活的人，家里很快就被生活填满了，冰箱里的水果、茶几上的零食、还有一只叫做“栗子”的小猫到处跑酷。一猫两人三餐四季，我们的故事刚开始不久，但还会持续很久很久。 阅读 2023 年读的书少，表面上是工作更忙了，根本上还是变懒了，工作忙只是自我说服的一个说辞。由俭入奢易，由奢入俭难，现在再回头看 2019 年读过的书，真的佩服当初的自己。 虽然依然记得《曾国藩家书》里面的“少睡多做，一人之生气”，但已经很难再做到“少睡”了。2023 年，在多睡的情况下，也多做了一点，读了 8 本书。 Apache Spark In Action（2nd Edition），★★★☆☆，Spark 的入门读物，内容比较浅，读完可以对 Spark 有比较系统的理解。 High Performance Spark，★★★☆☆，Spark 的进阶读物，介绍 Spark 的调优方法，但主要集中在应用层调优。 计算机体系结构：量化研究方法（第 6 版），★★★★★，介绍了计算机体系结构相关知识，包括系统设计、指令集等与硬件相关的内容，只读了几章，对做计算机底层性能调优帮助比较大。 计算机组成与设计：硬件/软件接口，★★★★☆，也是介绍计算机体系结构的相关知识，相比《计算机体系结构》更底层一些，强调软硬协同设计及其对性能的影响。 芯片简史，★★★★☆，介绍芯片的发展史，与《芯片战争》类似。《芯片战争》更多从商业的角度来讲述，而《芯片简史》更多是从技术的角度。 把时间当朋友（修订版），★★★☆☆，李笑来的老书新编，与《财富自由之路》内容类似，介绍个人学习与成长的方法。 纳瓦尔宝典，★★★★☆，硅谷大佬纳瓦尔·拉维康特的一些智慧箴言，主题是关于如何积累财富和获得幸福人生，里面的很多观点都让人受益。 合作的进化，★★★★★，2023 年印象最深刻的书，《纳瓦尔宝典》的推荐书籍，作者以“重复囚徒困境”游戏作为切入点，讲述了在与他者的持续交往中，应该选择怎样的合作策略才能得到较好的收益。 https://yrunz.com/p/%E5%90%88%E4%BD%9C-or-%E8%83%8C%E5%8F%9B%E4%BD%A0%E6%80%8E%E4%B9%88%E9%80%89/ Thu, 28 Dec 2023 00:00:00 +0000 https://yrunz.com/p/%E5%90%88%E4%BD%9C-or-%E8%83%8C%E5%8F%9B%E4%BD%A0%E6%80%8E%E4%B9%88%E9%80%89/ 《合作的进化》是罗伯特·阿克塞尔罗德的一本博弈论经典之作，作者以“重复囚徒困境”游戏作为切入点，讲述了在与他者的持续交往中，应该选择怎样的合作策略才能得到较好的收益。本书的一个重要结论是，人们相互作用越频繁，合作的可能性就越大。 本文是对《合作的进化》核心内容的总结。 前言 先从两个简单的问题开始： 在与他人的持续交往中，人什么时候应该合作，什么时候只需为自己着想？ 一个人会继续帮助他的一位从来不思回报的朋友吗？ 合作，是我们常常要面对的事，小到个人，大到国家。合作虽然能带来好处，但并不总是能建立起来。 两国之间的贸易壁垒就是一个很好的例子。显然，自由贸易对两国都能带来好处，但问题是，无论谁单方面取消壁垒，都会导致自己国家处于不利的贸易状态。所以，无论一个国家如何做，另一个国家保持它的贸易壁垒总是比较有利的。因此，每个国家都有利益动机保持贸易壁垒。 同理，在人与人之间、公司之间，也会存在类似的场景，我们可以用一个简单的游戏来进行模拟，那就是著名的“囚徒困境”游戏。 囚徒困境 在“囚徒困境”游戏中，有两个对策者，每人都有两个选择：合作或背叛，并且都需要在不知道对方选择的情况下做出自己的选择。每种选择对应的收益如下图所示： 从图中可以看出，当双方都选择合作时，集体收益是最高的 6；当一人选择合作，另一人选择背叛时，背叛一方的个人收益是最高的 5。之所以称为“困境”，是因为不管对方怎么选择，从个人的角度，背叛都是更好的选择，而双方背叛却会导致最低的集体收益。 从上述结论来看，背叛是必然的选择，那么为什么现实世界中还会存在这么多的合作呢？ 其实，上述结论的前提是，对策者双方只相遇一次，在只考虑当前回合的最大收益情况下，背叛是必然的。但如果双方会在将来相遇多次，那么就要考虑后续的收益，情况将变得复杂，我们将这称为“重复囚徒困境”。 为了探讨“重复囚徒困境”下的最优策略，作者组织了重复囚徒困境游戏的计算机竞赛，并邀请众多博弈论专家参与。 “一报还一报” 在计算机竞赛中，参加者提交一个能给出每一回合策略（合作或者背叛）的程序，该程序在作策略选择时可以利用对局的历史。竞赛是循环的，即每个程序都会与其他程序相遇，每轮比赛有 200 次对局，以此来模拟出“重复”。 竞赛的结果有点出乎意料，胜者是“一报还一报”策略，它是所有提交程序中最简单的策略，结果却是最好的。 “一报还一报”的策略是，最开始选择合作，随后按对方上一回合的选择去做，如果对方出现背叛，那么“一报还一报”也会在下一回合背叛来进行“报复”，但只会报复一个回合。下图举例了“一报还一报”与其他策略的 6 个回合的对局情况。 从上述例子来看，“一报还一报”策略在每一个对局之中都不是得分领先的一方，甚至在遇到全背叛策略 A 时 6 个回合的得分仅仅 3 分。但在单回合不占优的情况下，“一报还一报”依然在竞赛中却能获得胜利。 值得注意的是，在所有竞赛参与者中，善良策略（不首先背叛）的平均得分要比非善良策略（首先背叛）的平均得分高 25%！前 8 名的策略都是善良的。而在善良策略中，得分最低的是最少宽容性的规则，一个采用永久报复的完全不宽容的规则，。 “一报还一报”策略成功的原因是它综合了善良性、报复性、宽容性和清晰性。善良性防止它陷入不必要的麻烦；报复性使对方试着背叛一次后就不敢再背叛；宽容性有助于重新恢复合作；清晰性使它容易被对方理解，从而引出长期的合作。 合作 or 背叛，你怎么选？ 那么，在人与人相处的时候，我们应该怎么做呢？作者给出了 4 点建议: 不要嫉妒 不要首先背叛 对合作与背叛都要以回报 不要耍小聪明 不要嫉妒 人们总是习惯考虑零和博弈，这种情况下，一个人赢，另一个就输，比如下棋。但在现实生活中，大多数情况属于非零和博弈，也即可以双赢，也能双输。这种情况下，合作是可能的，但并不总能实现。 人们倾向于采用相对的标准，经常把对方的成功与自己的成功联系起来，从而导致了嫉妒。当嫉妒出现时，人会企图抵消对方已经得到的优势，通常通过背叛来实现。但背叛往往会导致更多的背叛，进而是双输的局面。因此嫉妒无疑是自我毁灭。 要求自己比对方做得好不是一个很好的标准，除非你的目的是消灭对方。 更好的做法是，把你所做的，与处在相同情况下的其他人所做的，进行比较。对于相同的策略，你是否已经做得最好了？其他人在这种情况下能做得更好吗？ 因此，只要你自己能做得更好，就让对方做得和你一样或略好些，就像“一报还一报”在每个对局中并不是优胜的一方，但并不妨碍它能赢得竞赛的胜利。 我们没有理由去嫉妒他人的成功，因为在长时间的“重复囚徒困境”中，他人的成功是你自己成功的前提！ 不要首先背叛 竞赛和理论分析的结果都表明，在非零和博弈中，善良策略是表现更好的一方，善良性能够避免不必要的冲。非善良策略在开头还显得挺有希望，但是时间一长它就摧毁了它自己赖以成功的基础。 对合作与背叛都要给予回报 竞赛中，“一报还一报”的成功给我们一个简单且有力的建议：要回报。 对善良者报以合作，对非善良者报以背叛。 值得注意的是，在报以背叛时，我们要保持惩罚与宽恕的平衡。“一报还一报”总是在对方每次背叛之后只背叛一次，而不是永久背叛，因此它成功了。 https://yrunz.com/p/%E7%BA%B3%E7%93%A6%E5%B0%94%E5%AE%9D%E5%85%B8%E5%A6%82%E4%BD%95%E8%8E%B7%E5%BE%97%E5%B9%B8%E7%A6%8F/ Sun, 19 Nov 2023 00:00:00 +0000 https://yrunz.com/p/%E7%BA%B3%E7%93%A6%E5%B0%94%E5%AE%9D%E5%85%B8%E5%A6%82%E4%BD%95%E8%8E%B7%E5%BE%97%E5%B9%B8%E7%A6%8F/ 上一篇：《纳瓦尔宝典》：如何积累财富？ 你幸福吗？ “你幸福吗？”，看到这个问题，你的第一反应是什么？ 在孩童时候，我们常常会这样说，“我的梦想是…，然后过上幸福的生活。”，但是，实现了梦想，就真的能获得幸福吗？有人的梦想是开公司做老板，但成为公司老板之后，可能会面临工作压力大、应酬多、陪伴家人时间少等问题，幸福感依然不强。 所以，幸福到底是什么？我们要做些什么才能真正获得幸福？世俗意义上的成功与幸福是什么样的关系？ 对于这些问题，纳瓦尔有他的理解。 什么是幸福？ 幸福很难有一个标准的定义，有人认为幸福是欲望得到满足、财富自由；也有人认为幸福是知足常乐、身体健康。 在纳瓦尔看来，幸福是一种没有缺憾感、无欲无求、活在当下的状态。 幸福并不是一种客观存在，而是一种主观感受。大自然并没有“幸福”和“不幸福”的概念，它只存在于我们大脑之中，因为我们有了欲望，才会给事物打上“好”和“不好”的标签。 也因为有了欲望，人们才会深陷于过去的“错误”之中，总想着“要是…，就好了”；才会对未来的“失败”深深恐惧，总想着“如果…，那该怎么办”。这让我们长期处于焦虑的状态，从而无法真正感受当下，怎会幸福。 而当你无欲无求时，自然也就不会悔不当初、不会谋求未来，此时此刻，你的内心会是一片宁静，是满足的，是快乐的，是幸福的。 如何获得幸福 幸福，不是天生的，与基因无关，而是一种技能，能够通过后天习得的技能。 就像可以通过锻炼来提高身体素质一样，我们也能通过刻意的练习来提高幸福感，可以尝试这么做： 降低自己的身份感。我们都只是浩瀚宇宙中的一粒尘埃，没那么重要，关注自己就好。 屏蔽脑海中的噪音和杂念、不在乎那些无关紧要的事。人的精力是有限的，想得越多，做得就越少，就越焦虑。 冥想。冥想是锻炼屏蔽杂念能力的一个好方法。 远离郁郁寡欢的人、和快乐知足的人相处。情绪是会传染的，想要获得幸福，就要经常跟幸福的人相处。 珍惜时间。 幸福，需要心境平和、活在当下。 在任何时候，我们的大脑都只有很小一部分是关注当下的，大部分精力都在规划未来或悔恨过去。比如，在下班的路上，我们可能会想今天的工作怎么又没做好，也可能会想明天的汇报该怎么办，但很少会关注此时此刻走路时身体的状态，或感受周围的环境。 这样的状态，我们很难获得绝妙的生活体验，无法欣赏身边的一切美好；如果每天都沉浸于过去或未来，那无疑是亲手扼杀自己的幸福。 要想活在当下，必须要做到心境平和。但是，事情总是一件压着一件，永远有做不完的事，所以焦虑感才会普遍存在。那么，要怎样才能做到心境平和呢？ 纳瓦尔的方法是，不与焦虑对抗，接受这一现实，并不断问自己，“我是想一直执着于这些想法，还是想重获内心的平静？”，答案显而易见。于接受中寻找幸福，是我们必备的技能。 幸福，源于好习惯。 孩童时候的我们，幸福感都差不多。然而随着年龄的增长，有些人的幸福感越来越强，而有些人变得越来越不快乐，一个重要的原因就是，两类人群习惯不同。 好的习惯可能会导致短暂的痛苦，但会带来长期的幸福。比如，少喝酒少吃糖、远离社交媒体，都能提高情绪稳定性；不好的习惯能带来短暂的快感，却会摧毁长期的幸福，比如沉迷电子游戏、抽烟酗酒。 而幸福生活的本质，就是不断用精心培养的好习惯，去替换那些在不经意间养成的坏习惯。 成功与幸福 很多人把成功和幸福划上等号，而纳瓦尔则认为两者存在一定的冲突。幸福就是满足现状；而成功源于对现状的不满，是对现在的改造。 这里纳瓦尔所说的成功，指的是物质上的成功，对此，他是这样的解释的：再好的东西，很快就会习惯，它们无法持续带来刺激或愉快的感觉。人类的本性是贪婪的，普通人追求物质成功的脚步很难停下来，而追逐过程本就是对现状不满的过程。 所以，不要过度执着于成功，欲望是主动选择的不开心，减少欲望，反而能使幸福感增加。 最后 每个人对幸福的理解都各有不同；同一个人在不同年龄段，对幸福的理解也会有所差异。 我们可以参考纳瓦尔的幸福观，并得到一些启发，但更重要的是，探索出此时此刻自己对幸福的定义。 参考 [1] 纳瓦尔宝典，埃里克·乔根森 [2] 《纳瓦尔宝典》：如何积累财富？，元闰子 [3] 《认知觉醒》的读后感，元闰子 更多文章请关注微信公众号：元闰子的邀请 https://yrunz.com/p/%E7%BA%B3%E7%93%A6%E5%B0%94%E5%AE%9D%E5%85%B8%E5%A6%82%E4%BD%95%E7%A7%AF%E7%B4%AF%E8%B4%A2%E5%AF%8C/ Sun, 05 Nov 2023 00:00:00 +0000 https://yrunz.com/p/%E7%BA%B3%E7%93%A6%E5%B0%94%E5%AE%9D%E5%85%B8%E5%A6%82%E4%BD%95%E7%A7%AF%E7%B4%AF%E8%B4%A2%E5%AF%8C/ 关于《纳瓦尔宝典》 《纳瓦尔宝典》的主角，纳瓦尔·拉维康特，是一名成功的创业者和天使投资人，典型的硅谷大佬。本书收集整理了他的一些智慧箴言，它与记录查理·芒格智慧箴言的《穷查理宝典》有着相似的出发点，给大众传授大师的人生建议。 从书的副标题“财富与幸福指南”能看出，它的主题是关于如何积累财富和获得幸福人生。《纳瓦尔宝典》并非教你如何投资，而更偏向个人成长。与它类似的，除了前面提到的《穷查理宝典》，还有《认知觉醒》、《财富自由之路》等，都是好书，都值得一读。 本文主要总结《纳瓦尔宝典》中关于“积累财富”的一些人生建议。 财富是什么？ 很多人会把“金钱”和“财富”划上等号，但这两者有着本质的区别。纳瓦尔对财富给出了通俗易懂的定义： 财富就是在你睡觉时也可以帮你赚钱的资产 比如可出租的房子、投入生产的工厂、持续工作的计算机程序等，都是常见的财富。 而金钱只是转移财富的方式，是社会的信用符号，具有调用别人时间的能力。 大多数人终其一生都在追求财富，我们努力工作、省吃俭用，却仍然没能做到财富自由。 所以，获得财富跟努力程度没有必然的联系，与埋头苦干相比，更重要的是选择正确的方向。想要获得财富，你必须要知道做什么、怎么做、什么时候做。 我要做什么？ 这世上，有很多获得财富的成功案例，但并非所有案例都适合你。盲目追求热点，并不会带来财富，关键是找到你的专长。 专长指的是无法通过培训获得的知识。如果社会可以培训你，那么社会也可以培训他人来取代你。 每个人的 DNA 里或多或少都会有一些比大多数人都擅长的东西，我们把它称为，专长和天赋。这是与生俱来的，其他人很难通过社会培训习得，或者需要付出巨大的代价。 在“成为你自己”这件事上，没人能做得比你好， 专长能带来差异化的竞争力，而你要做的，就是要持续地扩大你的优势，彻底一骑绝尘。 识别自己的专长并不容易，这需要对自身有一个全面的了解，可以尝试这样： 从儿童时代开始回顾，找到那些别人要很努力，而你却毫无费劲就能完成的事。 从自己的兴趣中寻找，不是三分钟热度，而是你愿意为之付出一辈子的事。 我要怎么做？ 杠杆效应 给我一个支点，我可以翘起整个地球。 —— 阿基米德 当你找到自己的专长后，下一步就是，利用杠杆效应把专长规模化。一般来说，杠杆有 3 种： 劳动力杠杆，也即让别人给你打工。这是最古老的一种杠杆，但在现代社会中最低效。人员管理是一件极其复杂、极具挑战的工作，需要高超的领导技巧。 资本杠杆，也即利用今钱来扩大影响力。这是一种更现代的杠杆，虽然也需要一定的技巧，但管理资本要比管理人简单得多。但前提是，有钱。 复制边际成本为零的产品（下文统称新型杠杆），这是最新出现的一种杠杆，也是普通人最能触及的，并且借助互联网能够产生爆发式的增长，比如，书籍、媒体、代码。 使用劳动力杠杆需要有人追随你；使用资本杠杆需要资金；使用新型杠杆只需一台电脑或手机，而且无须经过他人的许可。 其中，代码是最强大的一种杠杆，只需运行一台计算机就够了。并且，随着 SaaS 愈发成熟，普通人利用代码来规模化产品也变得愈发简单。 复利效应 复利是世界第八大奇迹。知之者赚、不知之者被赚。—— 爱因斯坦 复利不仅仅适用于金融领域，在知识、经验、专长等方面，只要能积累的东西，都能产生复利效应。 明确了杠杆后，下一步就是相信复利效应，坚持、坚持、再坚持。没有一夜暴富，成功需要时间，需要你对自己热爱的事物孜孜不倦，需要你的专长不断精进，需要你相信时间的力量。 我要什么时候做？ 答案只有一个，现在！ 财富是人生的终极目标吗？ 财富不是人生的终极目标，幸福才是。财富只是通往幸福的一种工具，两者不能划等号，富豪的幸福感不见得一定比普通人的强。相比学习如何获得财富，其实，我们更应该学习如何获得幸福。 下一篇，我们将总结纳瓦尔关于如何获得幸福的建议。 文章配图 可以在 用Keynote画出手绘风格的配图 中找到文章的绘图方法。 参考 [1] 纳瓦尔宝典，埃里克·乔根森 https://yrunz.com/p/2022-%E5%B9%B4%E5%B0%8F%E7%BB%93/ Mon, 23 Jan 2023 00:00:00 +0000 https://yrunz.com/p/2022-%E5%B9%B4%E5%B0%8F%E7%BB%93/ 我想，2022 年的关键字，是“变”，工作、生活、心态都在变。人，总是趋于稳定；然而，变，才是生命中的主旋律。变化来临时，我们通常会经历阻力、挫折、迷茫，如何面对这些，将人分成了不同的样子。有人迷失自我、随波逐流；有人保持初心、逆风前行。 薛定谔说，“人活着就是在对抗熵增定律，生命以负熵为生。” 但是，在变化中保持不变的初心，很难。自问在过去的一年里·做到了吗？有点，但不多。2022 年也曾迷茫过，所幸每次都能调整回来，阅读、写作、生活，一直都在。 阅读 2022 年读过的书不多，读完的，也才一半。 最近一直在反思，人的精力是有限的，但书是无尽的；不同的书、同一本书的不同章节，质量也参差不齐。这种情况下，选择读什么、怎么读变得尤为重要。最直接地，读经典。但经典也很多、很厚，全部读完，也很难。 所以，还是要回到根本问题，你为什么要读书？ 个人以为，如果想学习一门技术、弄清楚一个问题，那么可以选读相关章节；如果是想提升人文素养、获得人生感悟，那么还是通读为好。所以，我的阅读策略慢慢调整为，选读技术类书籍，通读人文类书籍。不管那种方式，读书过程中，思考是必不可少的。 Computer Systems A Programmers Perspective (3rd edition)，中文名 深入理解计算机系统。CSAPP 不必多说，被誉为计算机必读经典，缺点是，难啃。今年因工作需要，专门把第二章精读了一遍，对数值类型有了更深刻的理解，还写了总结 深入理解计算机系统的数值类型。 Database System Concepts (7th edithion)，中文名 数据库系统概念。数据库领域的经典，值得通读，结合 CMU 的公开课更佳，目前只读到了第四章。 Clean Agile: Back to Basics，中文名 敏捷整洁之道。Martin 大叔继 代码整洁之道、架构整洁之道 之后的又一力作，介绍软件敏捷开发的流程。印象最深的一点是，项目管理是一个在 Good、Fast、Cheap、Done 之间 trade-off 的过程，四者只能满足其三，比如，想要在人力投入有限的情况下，快速完成需求交付，就必须牺牲软件的质量。 API Design Patterns，可以看成是 Google APIs 设计规范的详细版，对从事平台框架、微服务开发的同学很有帮助。 大数据处理框架 Apache Spark 设计与实现，对 Spark 的设计和实现原理都介绍得很清楚，做到了深入浅出，看完会对 Spark 有一个系统的认识。要是能够结合源码就更好了。 Spark SQL 内核剖析，读了前几章，算是 Spark 源码剖析类书籍里面讲的比较好的了，但对新手不友好，也可能是 Spark 太过博大精深了。 Trino: The Definitive Guide，可作为 Trino 的入门书籍，比较全，但很浅。Trino 是一个开源分布式 SQL 查询引擎，主打低时延和跨源查询，由 Facebook 开源的 Presto 演进而来。 Scala 编程（第三版），因工作需要在 Spark 上做开发，专门找来补 Scala 的知识，粗粗扫一遍。感受是，Scala 的语法糖真多。 棋王，阿城作品，包含了《棋王》、《树王》、《孩子王》三篇中篇小说，总结成一句话： 故事好、文字好。《棋王》最出名，关于“棋痴”王一生的故事，最后的九人车轮战，很有武侠风；《树王》最写实，两个“树王”，殊途同归；《孩子王》最童真，也是我最喜欢的一篇，探讨了教育问题，读完忍不住买了一本新华字典，想着每天学习几个字，最终没能坚持下来。 威尼斯日记、阿城文集之二，读完棋王，又专门找了两本阿城的作品来读。阿城的文字很有画面感，简洁、有力，而且读的过程中会不断惊叹于作者那渊博的知识。 芯片战争，因工作涉及，专门挑了一本关于芯片行业的通识书籍。读的时候会想起吴军的《浪潮之巅》，一本是互联网行业，一本是半导体行业，共同点是，可读性都很强。 极简欧洲史，把欧洲文明的基本要素总结为： 古希腊罗马文化、基督教教义以及日耳曼战士文化，以一个新颖的思路介绍了欧洲历史。印象最深的是，第一次发现，基督教里面的上帝和耶稣竟不是一个人。 人类群星闪耀时，描写了 14 个影响人类文明的历史瞬间，带有较多作者的主观感受。最喜欢的《决定世界的一分钟》，讲述拿破仑在滑铁卢战役上的惨败，记得还出现在初中课本上。 打开：周濂的 100 堂西方哲学课，介绍了从古希腊到近现代的西方哲学发展史，作为哲学入门读物很不错。今年看了不少哲学相关的知识，深感哲学对思维的重要性，它会让你养成思考的习惯。 刘擎西方现代思想讲义，2 年前买的书，没读完；阳的期间重新拿了起来，在发烧的深夜，读了 2 章，竟然神奇的退烧了。 写作 2022 年还算高产，写过的文章，比前两年加起来还多，类别也丰富起来了，技术类、思考类、记事类，都有。但也有很多计划写的，因为太懒、太拖，没完成。表达上，也有所转变，以前会想着，能不能再加点描述，再多点字；现在则是，能不能简洁点，再少点字。 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E4%BA%94%E4%B9%8B%E6%9C%8D%E5%8A%A1%E5%8C%96%E6%9E%B6%E6%9E%84/ Fri, 08 Apr 2022 00:00:00 +0000 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E4%BA%94%E4%B9%8B%E6%9C%8D%E5%8A%A1%E5%8C%96%E6%9E%B6%E6%9E%84/ 《从分层架构到微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章，这里不会事无巨细地介绍所有的细节，而是会挑选其中关键内容，更多详情请阅读原书。 往期精彩： 从分层架构到微服务架构（一） 从分层架构到微服务架构（二）之分层架构 从分层架构到微服务架构（三）之管道架构 从分层架构到微服务架构（四）之微内核架构 前言 从本文开始，我们进入了《从分层架构到微服务架构》系列中分布式架构的介绍，本文要介绍的是服务化架构（Service-Based Architecture，SBA）。 SBA 可以看成是单体架构和微服务架构之间的一个折中方案，它也是按照业务领域进行服务划分，但服务划分的粒度相比微服务要更粗。SBA 与微服务架构一大不同是，它允许各个服务间共享同一个数据库实例，这也使得 SBA 在架构上既有单体架构的特点，也有分布式架构的特点，显得更加的灵活。因此，从单体架构演进到 SBA，会比直接演进到微服务架构更加容易。 架构视图 基础视图 SBA 的基础架构视图分成 3 部分： User Interface，作为系统的接入口，接收客户端的请求，并转发到业务服务。。 Domain Services，业务服务按照领域进行划分，分开部署、业务独立。 Database，服务间共享的数据库实例，因为数据库实例只有一个，所以可以支持 ACID 事务。 使用 SBA 的系统通常只会划分 4 ～ 12 个服务，避免产生过多的数据库连接。服务数量不多，也决定了 SBA 中的服务相比微服务架构中的服务有着更粗的粒度。User Interface 与服务间通过远程通信协议来完成业务往来，常见的通信方式有REST、RPC、消息队列等。需要注意的是，SBA 是不允许服务间通信的，这与微服务架构有着本质的区别。 大多数情况下，SBA 中的服务只有一个或者少量实例，与微服务动辄成百上千个实例有着很大的区别。主要是因为 SBA 服务粒度更粗，无法做到像微服务那样精准的按需扩容，扩容太多反而会导致资源的浪费。 SBA 的另一大特点是允许所有服务共享同一数据库实例，使得它能够直接将传统单体架构的那一套 SQL 查询逻辑、ACID 事务搬过来，让架构的演进更加的平滑。不过，共享数据也会带来一些问题，比如数据模型变更的影响范围更大，后面会在“**数据拆分”**一节详细讲述。 拆分 User Interface 在大型系统中，单一的 User Interface 可能导致代码耦合、性能瓶颈等问题，这时候我们可以进一步对它进行拆分。拆分的方法可以是基于业务领域的拆分，业务相关的几个服务使用同一个 User Interface；或者基于服务的拆分，为每个服务都配备一个 User Interface。 拆分 Database 类似地，我们也可以对数据库进行拆分，可以拆分成几个服务共享一个实例；也可以像微服务架构中那样，每个服务独享一个实例。数据库拆分的原则就是：确保数据是解耦的，不会被其他服务所依赖，避免出现跨库查询或服务间通信。 https://yrunz.com/p/2021%E5%B9%B4%E5%B0%8F%E7%BB%93/ Mon, 31 Jan 2022 00:00:00 +0000 https://yrunz.com/p/2021%E5%B9%B4%E5%B0%8F%E7%BB%93/ 新年将至，照例还是要对过去的2021年做个小结。在过去的一年里，读过的书不多，写过的文章也少，生活倒是有不少感悟。 阅读 2021年读过的书不多，从数量上看，比起往年还是少了些。一方面是懒惰的天性驱使；另一方面也是读得更慢了。以前读书很多时候是为了追求知识广度，走马观花浏览一遍，留个大致的印象便算完事。久而久之，虽然明面上读了不少书，但是知识倒是没涨多少。 为此，自己也在不断思考如何更好地读书，于是开始尝试做笔记，在读书过程中把关键知识和自己的思考记录下来。然后发现，读书笔记不仅仅有助于加深对知识的理解，而且为文章的写作提供了很好的素材。于是就逐渐养成了读书过程中做笔记的习惯，读书的速度也就慢下来了。 《Fundamentals of Software Architecture》：被称为是架构师的入门指南，重点介绍了当今常见的8种架构模式。每种架构模式都有其优缺点以及适用场景，并不存在所谓的“银弹”。正如作者书中提到，Everything in software architecture is a trade-off。 《Microservices vs Service-Oriented Architecture》：可作为《Fundamentals of Software Architecture》的延伸阅读材料，重点对比了微服务架构和基于服务的架构之间的优缺点，有助于加深对两种架构的异同点的理解。 《Operating Systems: Three Easy Pieces》：读过的写得最好的操作系统书籍，作者把复杂的基本原理介绍得通俗易懂，又不乏深度。整本书条理清晰，非常值得一读，中文版被翻译成《操作系统导论》。 《软件架构设计：大型网站技术架构与业务架构融合之道》：同样是以架构设计为主题，相比于《Fundamentals of Software Architecture》，这本更“接地气”，不仅介绍了高并发、数据一致性等常用问题的解决方法，还介绍了诸如操作系统、数据库、网络等基础知识。 《凤凰架构》：周志明老师的又一力作，从架构的视角介绍了如何构建大型分布式系统，全书的话题涉猎很广，基本把分布式系统所能涉及的知识点都讲解了，比如远程服务调用、事务、安全、一致性等。书中罗列了很多参考阅读材料，可作为进阶架构师的一本导航书，如果把其中提到的知识点都研究透，那么可以就成为专家了。 《The Programmer’s Brain》：从认知科学的角度教你如何更好地阅读代码、理解代码、编写代码，对于程序员新手来说值得一读。书中提到的很多学习程序的方法，感觉就是将有经验的程序员的一些学习方法，结合认知科学的理论更好地呈现了出来。 《吴军阅读与写作讲义》：某天在一家书店上花了一下午的时间浏览完这本书的上半部分——“如何阅读和写作”，书中讨论的正是理工科学生容易忽视的阅读、写作、表达等软能力。 《邓小平时代》：读完本书，一方面被邓小平的坚韧、格局、领导力所屈服，另一方面也看到了我党一路走来也是在不断地犯错-反思-改正-进步。恰逢2021年是我党建党100周年，这一年里也看了很多关于党史的影视节目，对我党历史也有了更深刻的了解。从觉醒年代，到北伐战争，然后长征、抗日、大决战、抗美援朝、文革、改革开放，一路走来，我党在黑暗中不断摸索前行，磕磕碰碰，逐渐找到一条通往光明的道路。 《刘擎西方现代思想讲义》：通过介绍十多位西方思想家的思想结晶，将西方现代思想从启蒙逐渐走向成熟的过程呈现给读者。随着物质生活的满足，现代人也慢慢开始寻找人生的意义，“我是谁”，“我在做什么”，“我为什么这么做“，这些问题，那些伟大的思想家都有想过，读完这本书，也许会找到一些答案。 前些天有幸听了一场“哲学王子”王德峰的讲座，感触很大。中国的哲学（主要是孔子的儒家思想）和西方的哲学（主要是柏拉图的理念论）差别还是蛮大的，这也决定了西方和中国发展道路的不同。西方强调改变世界，中国则是强调天人合一。虽然目前结果来看，西方会更成功一些，但是天人合一的可持续发展也许更有潜力。 《人体简史》：印象最深的是书中最后关于衰老和死亡的描述，对于我们大多数人来说，死亡是能想象出的最可怕的事情，但是对于宇宙来说，人的死亡只不过又是物质的一次循环罢了。 “一具尸体仍然生机勃勃，只不过，它不再是你的生命。它属于你留下的细菌，以及其他蜂拥而至的细菌”。 《认知觉醒》：早冥读写跑，人生五件套；做每一件事情都要专注事情本身；坚持每日反思，每日计划。作者所提倡的这些虽然很难全部做到，但是至少在心里留下了个烙印，也在不断尝试在这个快节奏的生活里，学着慢下来专注和思考。 《巨人的陨落》、《世界的凛冬》、《永恒的边缘》：肯福莱特先生的三部史诗巨作，以小人物的视角讲述从一战到冷战的西方世界历史发展之路。在历史的滚滚车轮里，每一个迈向死亡的生命都在热烈地生长。这是对有声书的首次尝试，惠天和言亮老师（非星凡文化@喜马拉雅）的双人播讲体验极好，是通勤路上的必备小伴侣。除了小说剧情之外，两位老师以知识卡片的形式延伸了很多历史知识和人性感悟，非常值得一听。 写作 2021年只写了10篇文章，产出还是一如既往的少。而且一些打算写成系列的文章写着写着都烂尾断更了（2020年的《使用Go实现GoF的23种设计模式》系列，2021年的《从分层架构到微服务架构》系列），许多朋友催更也无果。倒不是因为偷懒，而是那份兴致很难再提起了，毕竟人总是喜新厌旧的😄。这也促使我后面宁愿写长文，也轻易不会再写系列短文。 https://yrunz.com/p/%E8%AE%A4%E7%9F%A5%E8%A7%89%E9%86%92%E7%9A%84%E8%AF%BB%E5%90%8E%E6%84%9F/ Mon, 14 Jun 2021 00:00:00 +0000 https://yrunz.com/p/%E8%AE%A4%E7%9F%A5%E8%A7%89%E9%86%92%E7%9A%84%E8%AF%BB%E5%90%8E%E6%84%9F/ 《认知觉醒》是前些日子在微信读书上无意中点开，然后利用碎片时间读完的一本关于个人成长的书籍。作者周岭结合自己的成长经历，对现代年轻人普遍的成长困扰给出了自己的一些看法，并提出了能够帮助大家正确、高效地成长的一些实用方法。 以前读过的关于个人成长的书籍还有李笑来的《财富自由之路》，《认知觉醒》的不同之处在于它更加的接地气。书中提到的很多高效成长的方法，在我看来，绝大部分人都可以做到。其中的一些方法，本人也一直在使用，效果确实很明显，这本书值得大家去翻一翻。 关键是“专注” 在这个信息爆炸的年代，专注一件事情变得越来越困难。古人总说“一心不能二用”，但现在的人似乎总是在追求着“一心二用”。在跑步时听音乐、在吃饭时看视频、在走路时听书、在睡觉时思绪万千… 我们追求时间利用率的最大化，却也导致了行为与感受的分离。 ”一心二用“这一习惯一旦养成，对个人成长必然会造成巨大的影响。个人的成长主要靠学习，科学的学习模式应该是极度的专注 + 适度的休息，如果我们没法专注，学习的效率急速下降，很多时候甚至是白忙活了。 所以，要想更加正确、高效地成长，学会“专注”是关键。在跑步时，我们可以试着感受抬腿摆臂和迎面微风；在吃饭时，可以试着感受饭菜的酸甜苦辣；在睡觉时，可以试着感受身体的紧张与松弛… 试着在生活的每一件小事情上养成“专注”的习惯。 善于刻意练习与关联学习 人的天性就是避祸就福，我们总是习惯于待在舒适区，对舒适区之外的东西避而不谈。然而，成长就是不断扩大舒适区的过程。并不是说你在舒适区里待得足够够久了，它就会扩大；相反，你需要不断的走出舒适区。就好比你练习了1000遍的C和弦，却也照样学不会大横按。 走出舒适区的一个关键点是刻意学习，找到我们的知识薄弱点，不断地进行补充，反复地练习。 比如，当你发现操作系统的基础知识不够牢固，那么就去找一本经典的操作系统书籍，仔细地阅读，认真地对待书上的每一道习题，以此达到查漏补缺的效果。 《认知觉醒》把成长区域分成了舒适区、拉伸区和困难区3部分，长期处于拉伸区才可以更快地进步。我们常犯的一个错误就是，从舒适区直接跳到了困难区，导致很容易受挫。 比如你发现操作系统的基础知识不够牢固之后，马上就去阅读起了Linux的内核源码，如此一来，估计要不了几天，就坚持不下去了。 除了刻意练习，学会关联学习也很重要，也就是我们常说的“举一反三”。关联学习除了可以加深对当前知识点的印象之外，更重要的是可以找到知识的本质原理。很多知识都是相通的，当你把一个知识的本质原理弄明白之后，就会达到所谓融会贯通的效果了。 比如你学习七层网络模型之后，记住了在这个模型中，网络分成了物理层、数据链路层、网络层、传输层、会话层、表示层、应用层等七层，但这也就仅仅记住了而已。 如果你学会了关联学习，就会开始联想在软件计算机领域还有哪些地方用到了类似的模型。接着，你很快就发现了Web应用中经典的三层架构；领域驱动设计中的领域层、应用层、接口层、基础设施层；还有前台、中台和后台的划分等等，这些其实都运用了同一个架构模式，分层架构。在分层架构中，每一层都只专注于自己的职责，也就是软件设计领域的一个重要原则：单一职责原则。 如此一来，以前学到的各种知识点，一下子就都融会贯通了起来。 学会反思 成长也是一个不断产生BUG，然后修复BUG的过程。现代的软件开发追求小步快跑、敏捷迭代，快速发现问题，然后解决问题。人的成长也一样需要敏捷迭代。我们每天都会犯一些错误（BUG），如果我们放任这些BUG不管，终有一天它们会酿成事故，在最关键的时刻，给你最致命的一击。 所以，我们要学会每日反思，复盘产生BUG的原因，探讨解决BUG的措施。方法也很简单，找一个可以记录文字的本子或软件，比如OneNote，每天晚上睡前按照如下的模板进行反思： 1、描述经历 —— 以便日后回顾时能想起当时的场景。 2、分析原因 —— 多问几个为什么，直到有深度的启发。 3、改进措施 —— 尽可能提炼出一个认知点或行动点。 只有正视我们自身的问题，不害怕，不逃避，并纠正之，不重犯，我们才能更快速地成长。 制定每日计划 制定每日计划很重要，它可以避免我们每天都像无头苍蝇一样迷失在茫茫的信息洪流之中。但计划有时候也会有副作用，当因为事情冲突而没完成当天计划时，可能会心生愧疚。久而久之，也就觉得没必要做计划了，因为做了也没法顺利完成。 其实，我们完全可以把计划当成是一种提示工具，而不是必须完成的任务。计划的作用只是在完成一件事情之后，提示我们还有下一件事要做，而不至于无所事事。至于今天列出的计划，有多少完成了，有多少还未完成，这些都不是很重要。 每日计划的模板不用很复杂，能够简单记录每天要做的事情即可，比如书中给出的模板就挺好。 早冥读写跑，人生五件套 早起。早起可以让一天的时间更加的充实。如今，大部分的程序员晚上的时间基本都被工作填满，长期下去，个人成长速度也会放缓。而早起能够改变这一现状。曾国藩曾说过，“少睡多做，一人之生气”，每天早起2小时进行充电，一年下来就多了接近100个小时的时间，足以让一个人得到快速成长。 冥想。冥想在最近几年变得流行起来，大家都在鼓吹冥想的好处，可以提升脑力，深度休息等等。在我看来，冥想最重要的是可以锻炼自己的专注力，磨练自己的耐心。当你能够沉住气在10分钟内什么也不想时，这份专注和耐心也足够强大了。 读书。书是人类进步的阶梯，读书就是跟智者的一次面对面交流，它是获得知识的最廉价的方法。但前提是要学会辨别好书，豆瓣读书上的评分是一个很好的参考方式，挑那些经受过时间考验的经典书籍来读，克服英文阅读的障碍。 写作。只读不写的学习很难把他人的知识转变成自己的知识，要学会使用自己的语言重新组织学到的知识。当你能够教授别人时，这份知识才真正成为你知识体系中的一部分。另外，不要把取悦读者作为写作的目的，要秉着自我提升的目的去写作，不断提升自己的知识总结能力，磨练自己的写作技巧。 跑步。脑力锻炼的同时也不能忽视体力锻炼，适当的运动除了能够让身体更健康，还能让大脑得到放松，为接下来的工作学习做好准备。 写在最后 《认知觉醒》这本书中有提到，评判一本书的好坏，关键点在于它有没有对你有所触动。对我来说，这本书做到了，其中的一些观点确实可以引发我的共鸣。书中提出了很多帮助个人成长的方法，但如果你仅仅是知道了这些知识点，而没有去行动落实，最终的结果终究还是“懂得很多大道理，却仍然过不好这一生”。所以，成长没有捷径，还得脚踏实地，一步一个脚印。 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E5%9B%9B%E4%B9%8B%E5%BE%AE%E5%86%85%E6%A0%B8%E6%9E%B6%E6%9E%84/ Fri, 23 Apr 2021 00:00:00 +0000 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E5%9B%9B%E4%B9%8B%E5%BE%AE%E5%86%85%E6%A0%B8%E6%9E%B6%E6%9E%84/ 《从分层架构到微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章，这里不会事无巨细地介绍所有的细节，而是会挑选其中关键内容，更多详情请阅读原书。 往期精彩： 从分层架构到微服务架构（一） 从分层架构到微服务架构（二）之分层架构 从分层架构到微服务架构（三）之管道架构 前言 微内核架构（Microkernel Architecture），也被称为插件式架构（plug-in architecture），作为一个在几十年前就被创建出来的架构模式，它如今仍然被广泛应用在各个领域中。比如在Web浏览器领域，谷歌的Chrome浏览器之所以被认为功能强大，一个很重要的原因是它有着丰富的插件类型；在开发工具领域，微软的VS Code初始安装后还只是个简单的文本编辑器，但用户可以安装各种插件，从而让它摇身一变成为功能强大的IDE。 Chrome和VS Code都是微内核架构的典型应用例子，它们提供一个具备最基础能力的核心系统，并定义好插件的开发接口。至于需要开发或安装哪种类型的插件，则完全由普通开发者和用户决定，这样的设计让系统具备了极强的可定制化和可扩展能力。 架构视图 微内核架构由以下两部分组成：核心系统（core system）和插件（plug-in component），将应用系统的业务逻辑拆分成核心系统和插件，能够提供很好的可扩展性和灵活性，极大地方便了后续需求的新增和修改。 核心系统 核心系统通常只需提供能够支撑整个系统正常运行的基本功能，比如前文所举的VS Code例子，用户初始安装的是VS Code的核心系统，它只是一个提供了打开文件、编辑文件内容和保存文件等基本功能的文本编辑器，其他的扩展功能（如语法检查）都是通过安装插件集成的。将复杂的业务逻辑从核心系统中剥离出来，并通过插件实现，能够提升系统的可扩展性和可维护性。同时，因为复杂的功能都成了互不干扰的插件，系统的可测性也得到了提高。 考虑现在需要实现一个电子设备回收系统，在回收之前，每种型号的手机设备的回收流程都不一样，那么我们可以这样去实现： public void assessDevice(String deviceID) { if (deviceID.equals("iPhone6s")) { assessiPhone6s(); } else if (deviceID.equals("iPad1")) assessiPad1(); } else if (deviceID.equals("Galaxy5")) assessGalaxy5(); } else ... ... } } 如果我们把assessDevice看成是核心系统，那么后面每次新增一个型号的手机，都需要新增一个if分支，也即对核心系统进行了改动。这样的设计会导致核心系统非常地脆弱，正所谓改的越多，出问题的概率也越大。 比起这种将所有的可定制业务逻辑放在核心系统上的设计，更好的应该是将它们实现为插件的形式，这样不仅每个设备回收逻辑都解耦了，还提供了强大的可扩展性：添加一个新的回收设备类型，只需新增一种插件即可，核心系统无需变动。 public void assessDevice(String deviceID) { String plugin = pluginRegistry.get(deviceID); DevicePlugin devicePlugin = (DevicePlugin)constructor.newInstance(); DevicePlugin.assess(); } 微内核架构在实现时通常都结合了其他架构模式，这主要体现在核心系统的设计上，比如根据具体的业务特点，我们可以将核心系统设计成technically partitioned的分层架构，或者是domain partitioned的模块化架构。 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E4%B8%89%E4%B9%8B%E7%AE%A1%E9%81%93%E6%9E%B6%E6%9E%84/ Mon, 05 Apr 2021 00:00:00 +0000 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E4%B8%89%E4%B9%8B%E7%AE%A1%E9%81%93%E6%9E%B6%E6%9E%84/ 《从分层架构到微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章，这里不会事无巨细地介绍所有的细节，而是会挑选其中关键内容，更多详情请阅读原书。 往期精彩： 从分层架构到微服务架构（一） 从分层架构到微服务架构（二）之分层架构 前言 管道架构（Pipeline Architecture），通常也被称为管道-过滤器架构（Pipes and Filter Architecture），是最常用的架构模式之一。大部分软件工程师都是通过Unix终端初次接触到该架构模式，Unix终端的Shell语言，对管道-过滤器有着原生的支持。 比如，现在需要实现这样的一个功能：读取一个文本文件的内容，找到使用频率最高的5个单词，并按照使用频率的大小顺序打印出单词及其使用频率。 那么，使用Shell可以这样来实现： cat content.txt | # step1: 读取文件内容 tr -cs A-Za-z '\n' | # step2: 将单词按行输出 tr A-Z a-z | # step3: 将所有单词转换为 sort | # step4: 对单词进行排序 uniq -c | # step5: 计算出单词的频率 sort -rn | # step6: 按照频率对单词进行排序 head -n 5 # step7: 获取排序前5的单词 # 输出结果示例： 4 to 4 and 3 the 3 networks 3 linux 这段Shell代码就是一个简单的管道架构实现，其中|表示管道pipe，每一个step就相当于一个过滤器filter。每个filter都将上一个filter的输出结果作为输入数据，对数据进行处理后再将结果输出到管道中。 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E4%BA%8C%E4%B9%8B%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84/ Sat, 30 Jan 2021 00:00:00 +0000 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E4%BA%8C%E4%B9%8B%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84/ 《从分层架构到微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章，这里不会事无巨细地介绍所有的细节，而是会挑选其中关键内容，更多详情请阅读原书。 往期精彩： 从分层架构到微服务架构（一） 前言 软件刚出现的时候，还是大型计算机的年代，一个软件系统一般都只会运行在一台机器上。随着软硬件技术的革新，计算机体积和成本逐渐变小，此时工程师们发现一个软件系统只运行在单台机器上会存在各种瓶颈。如果将系统按照功能划分成前端和后端，分别部署在两台服务器上，问题得到了缓解，于是便有了Client/Server架构的出现。 随后，个人电脑的兴起带动了众多富桌面应用（rich desktop application）的出现，它们基于操作系统上的user interface开发，数据则是存储在单独部署的database server上，通过标准的网络协议进行数据通信。这种Desktop + Database Server的架构和C/S架构一样，同属两层架构（two-tier architecture）。 随着90年代互联网的迅速崛起，Browser + Web Server + Database Server的组合也渐渐风靡。Browser为表现层，提供用户交互界面；Web Server为业务层，处理具体的业务逻辑；Database Server为数据层，存储系统数据。三个层次各司其职，这也是大家最熟悉的三层架构（three-tier architecture）。 上述的几种架构模式都属于分层架构（layered architecture）的范畴，分层架构并没有限定一定得有多少个层次，层次的数量可以根据应用场景灵活控制，因此也被称为n-tier architecture。它结构简单，基于此架构进行系统开发成本也很低（很多公司在组织结构上划分为前端工程师、后端工程师、DBA，根据康威定律，这天然就具备了分层架构开发的良好条件），因此它在业界备受欢迎。如果你的团队还不确定选择什么样的架构，又或者为了践行敏捷宣言中的“just starts coding“，那么分层架构会是一个不错的选择。 架构视图 在分层架构中，组件根据功能被划分在不同的层次上，虽然层次的数量和类型并没有被限制，但大多数的分层架构都由以下4层组成：表现层（presentation）、业务层（business）、持久层（persistence）和数据层（database），如下图所示。在一些简单的系统中，持久层的逻辑（如SQL）被嵌入到业务层中，形成了经典的三层架构；而在一些复杂的系统中，也会根据具体的业务划分为五层甚至更多的层次。 前文所述的表现层等4个层次都是逻辑的划分方法，在实际部署时，一般会有下图所示的几种部署形态。形态1中，表现层、业务层和持久层为一个部署单元，而数据层则单独部署，具体表现为一个独立部署的数据库或文件系统；形态2中，表现层被分离出单独部署，业务层和持久层组成一个部署单元，数据层依旧是单独部署的数据库或文件系统；形态3中，包括数据层在内的4层全都在同一个部署单元内，常见于业务简单的系统，它们往往使用的是嵌入式数据库或内存数据库。 分层架构中的每一层都扮演着各自的角色，比如表现层负责处理所有的用户请求和浏览器交互，而业务层则负责执行每次请求下的特定业务逻辑；表现层无需担心从哪里获取用户数据，它只需要将数据以特定的格式在浏览器上显示即可。同样地，业务层也无需关心用户数据从何而来以及如何呈现，它只需从持久层中取出数据，执行特定的业务逻辑（比如聚合数据），然后将结果返回给表现层。 每一层都是特定行为的抽象，这样的职责划分，使得组织能够快速高效地创建出责任模型，围绕各层打造开发团队。 层间隔离 分层架构中的每一层可以是封闭的或者开放的，封闭意味着当一个请求自顶向下在层间传递时，它不能跳过任意的一层。比如，当表现层接收到请求之后，它必须先后经过业务层和持久层才能到达数据层，如下图所示。 对于简单的数据获取类请求，如果让表现层能够直接访问数据层获取数据，无疑是最简单高效的。也即是让业务层和持久层变成开放状态，允许请求在层间传递时跳过此层。那么，究竟是封闭好，还是开放好呢？要解答这个问题，就要回到层间隔离的出发点上。 所谓的层间隔离，旨在降低一个层次上的变化对其他层次的组件的影响，简单来说，就是每个层次对其他层次的功能知道的越少越好。为了达到层间隔离的目的，就需要将每个层次置为封闭的状态。假设表现层能够直接访问持久层，那么持久层的变化将会直接影响到业务层和表现层，这加剧了层间的耦合，导致系统变化的代价高昂。 层间隔离可以降低层次变化对系统的影响，凡事没有绝对，在某些的场景，将特定的层次置为开放的状态也不失为一件好事。考虑以下例子，业务层中存在着一些共享组件承载着业务层公共的功能（比如日志类、审计类、日期和字符串工具类等）。现在有一项架构决策要求表现层不能直接访问这些共享组件，但矛盾的是，原则上表现层是可以直接访问业务层的，这种需要违反原则的决策将会很难落地。 一种解决方法是，新增一个服务层，该层包含了业务层的这些共享组件。因为业务层是关闭的状态，故表现层也就不能访问到这些共享组件了。然而，新增的服务层必须置为开放状态，否则业务层将无法直接访问持久层。新增一个服务层并置为开放状态，这样既落地了架构决策，也不会影响到原有的功能，一举两得。 注意事项 在使用分层架构时，需要注意以下两点： 1、做好模块的划分 为分层架构做好模块划分主要是为后续的架构演进做好准备，比如在业务复杂到一定程度后演进为微服务架构时，各个模块可以很自然地演进为微服务。为此，应该避免出现类的继承层次过深的现象，这会导致代码严重的耦合，不利于后续的架构演进。 2、避免掉进sinkhole反模式的陷阱 所谓sinkhole反模式指的是请求只是简单地路过各个层次，并没有做一些业务处理。 比如，表现层接收到一个获取基本用户数据（姓名、地址等）的请求后将它传递到业务层；然而，业务层并没有做任何的业务处理，直接将请求传递到持久层；持久层也仅仅是构造了一个简单的SQL语句，向数据层查询用户数据；最后，数据按照原路返回到表现层，中途没有经过任何的数据汇聚、转换等操作。 sinkhole反模式会导致很多不必要的对象实例化开销，从而增大了系统的内存消耗，并且影响了性能。 然而，一个系统多多少少都会存在一些sinkhole反模式场景，要判断一个系统是否已经彻底掉进sinkhole反模式的陷阱，主要还是看这类业务请求所占的百分比。根据20-80法则，当系统中有超过80%的业务请求是sinkhole类请求时，表示系统已经掉进sinkhole反模式的陷阱，这从侧面也说明该系统已经不再适合分层架构，是时候考虑架构演进了。 架构评分 从综合得分上看，分层架构的Overall cost和Simplicity得分很高，这很大程度上得益于分层架构本身是单体架构，少了很多分布式系统才有的复杂性。但这样导致Deployability得分很低，因为3行代码的改动就足以造成整个系统的重新部署。Testability得分不高也是这个原因，整系统的重新上线通常都需要将测试用例全部执行一遍，多了不少额外的工作量。 Elasticity、Fault tolerance、Scalability这些都是单体架构天然的劣势，自然地，分层架构在这些方面得分都很低。另外，sinkhole反模式的存在也拉低了分层架构在Performance上的得分。 总结 分层架构简单而高效，业界已经有很多成熟的应用，对那些项目刚刚起步，架构师们还没想好要采用哪种架构模式的系统而言，这是非常适合的。在实现分层架构时，我们需要合理地设置各个层次的封闭或开放状态，做好层间隔离，同时也要避免掉进sinkhole反模式陷阱。随着业务的不断扩张，分层架构在可维护性、可测试性、可扩展性等上的短板也会逐步被放大，此时就需要考虑往其他架构模式演进了。 每种架构模式都有其合适的应用场景，只有熟悉常用的几种架构模式，才能设计出更好的软件系统。下一篇文章，我们将继续介绍管道架构。 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E4%B8%80/ Sat, 23 Jan 2021 00:00:00 +0000 https://yrunz.com/p/%E4%BB%8E%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84%E5%88%B0%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E4%B8%80/ 《从分层架构到微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章，这里不会事无巨细地介绍所有的细节，而是会挑选其中关键内容，更多详情请阅读原书。 前言 谈到软件系统设计的方法论，在代码层面，有我们熟悉的23种设计模式（design pattern），对应到架构层面，则有所谓的架构模式（architecture pattern）。它们分别从微观和宏观的角度指导着我们设计出良好的软件系统，因此，作为一个软件工程师，我们不仅要熟悉设计模式，对常见的架构模式也要熟稔于心。正如看到一个设计模式的名字脑里就能浮现出大致的结构图，当我们看到一个架构模式的名字时，也要马上想到对应的架构图及其基本特点。比如，当谈到分层架构时，我们就应该想起它的架构图是怎样的、有哪些出色的架构特征（architecture characteristics）、系统是如何部署的、数据存储的策略是哪种、等等。 一般地，架构模式大致可以分成两类，单体架构（monolithic architecture）和分布式架构（distributed architecture）。本系列文章将会介绍以下8种常用的架构模式： 单体架构 分层架构（Layered architecture） 管道架构（Pipeline architecture） 微内核架构（Microkernel architecture） 分布式架构 基于服务的架构（Service-based architecture） 事件驱动架构（Event-driven architecture） 基于空间的架构（Space-based architecture） 面向服务的架构（Service-oriented architecture） 微服务架构（Microservices architecture） 软件设计中的谬误 在介绍架构模式前，我们先谈谈软件设计中的谬误（fallacy）。所谓谬误，就是在设计软件系统，特别是分布式系统时，我们先入为主地假设它们是正确，但实际上并非如此的一些观念。这些观念都是我们在设计软件时考虑不周的体现。 谬误1：网络是可靠的 很多软件工程师常常假设网络是可靠的，但实际并非如此。相比20年前，现在的网络会可靠很多，但是仍然具有很大的不确定性。如上图所述，Serivce B可能完全是正常运行的，但是因为网络的问题，Service A发出的请求无法到达Service B。一种更糟糕的场景是，Service B可以收到Service A的请求，并处理了相关的数据，但是网络问题导致了Service A无法收到Service B的响应，从而造成了数据不一致。网络的不可靠也是为什么系统中常常出现服务通信超时、服务熔断等的原因。 总而言之，如果假设网络是可靠的，那么我们设计出来的软件系统将会是不可靠的。 谬误2：时延是0 如上图所示，服务内组件间的函数/方法级别的调用，耗时是微妙，甚至是纳秒级别；但是服务间的远程调用（比如REST、消息队列、RPC），耗时会是微秒级别，甚至在异常场景会达到了秒级！在设计系统，特别是分布式系统时，时延是一个无法被忽视的因素，我们必须清楚系统的平均时延，否则设计出来的方案可能根本不可行。比如，假设系统中服务间通信时延为100ms，如果一个请求的调用链涉及到10个服务，那么该请求的时延将会是1000ms！这么高的平均时延对于一般系统来说是完全无法接受的。 进行系统设计时，考虑平均时延还不够，更重要的是95th和99th百分点。一个系统的平均时延可能仅仅只有数十毫秒，但是95th百分点的时延却达到了数百毫秒，很多时候，这也恰恰成为了拖垮整系统性能的那块“短板”。 谬误3：带宽是无限的 在单体架构中，业务流程都在单服务内闭环，消耗的带宽很少甚至为0，因此带宽并不是主要关注点。一旦将系统拆分成分布式架构，一个业务流程可能涉及多个服务间的通信，带宽就成了必须考虑的因素。带宽的不足，会导致网络变慢，从而影响系统的时延（谬误2：时延是0）和可靠性（谬误1：网络是可靠的）。 如上图所示，假设在一个Web系统中，Service A负责处理前端请求，Service B负责管理用户信息（包括姓名、性别、年龄等45个属性）。Service A每处理一个请求都需要向Service B查询用户姓名（200 bytes），而在一次请求中，Service B却返回了用户的所有信息（500 kb）。如果系统每秒处理2000次请求，每次请求消耗500 kb带宽，那么每秒消耗的总带宽会是1 Gb！如果Service B仅仅返回必须的姓名，那么同等条件下，每秒消耗的总带宽仅仅是400 kb。 此类问题就是所谓的stamp coupling，解决方法也很多，比如在请求中添加属性选择，使用GraphQL替代REST。相比于这些技术手段，更重要的是确定服务间通信所需的最小数据集，并在进行系统设计时将其作为一个重点关注的因素。 谬误4：网络是安全的 VPN、防火墙等的广泛使用，使得很多工程师在设计系统时忽略了“网络是不安全的”这一重要原则。特别是从单体架构演进到分布式架构以后，系统被攻击的概率将会大大增加。因此，在分布式系统中，每个服务都必须是安全的endpoint，这样才能确保任何未知或恶意的请求都被拦截掉。当然，安全是有代价的，这也是像微服务架构这类细服务粒度的系统，一次业务请求中调用链过长后性能极速下降的重要原因。 谬误5：网络拓扑一成不变 这里的网络拓扑指的是系统运行时所涉及到的网络设备，包括所有的路由器、防火墙、集线器、交换机等。很多工程师会假设网络拓扑是固定的，然而并非如此。 https://yrunz.com/p/2020%E5%B9%B4%E7%9A%84%E6%88%90%E9%95%BF%E5%8D%B0%E8%AE%B0/ Thu, 31 Dec 2020 00:00:00 +0000 https://yrunz.com/p/2020%E5%B9%B4%E7%9A%84%E6%88%90%E9%95%BF%E5%8D%B0%E8%AE%B0/ 前言 2020年是艰难的一年，对于中国和世界而言，是新冠疫情的卷席全人类；对于个人而言，是工作上的无比繁忙。 以前一直会开这么一个玩笑，“在我们公司工作，那是一年工作，三年经验”。在工作的前两年，说出这句话更多的是一种自嘲，但在今年，它却是一个真实的写照。回顾2020年自己所做的事情，初略一想，除了工作，貌似也只剩下工作了。年初时定下的一些计划，大部分都因为工作繁忙的缘故而被搁置。在阅读和写作上，梳理了自己今年读过的书，数量还不及去年的三分之一；而写过的文章，更是寥寥无几。特别是在作为主业的软件技术方面，更是没有实质的进步，感觉还是停留在2019年的水平。在这个技术日新月异的行业，不进则退，貌似，今年是失败的一年？ 一直以来都坚信《钢之炼金术师》中等价交换这一原则，既然花了这么多时间在工作上，那必定会有所收获。仔细一想，今年收获最大的，莫过于对意志的磨练。 身为一名软件工程师，相信大家对技术都有着执着的追求。特别是初入职场，肯定有过把所有相关的技术框架学个遍的想法，唯恐跟不上时代的潮流。如果在工作的第一年问我，“对于一名软件工程师而言，什么是最重要的？”，我会回答，技术；工作的第二年，在学习了一些软件方法论，特别是领域驱动设计之后，结合工作上的项目经验，这才慢慢认识到，软件技术万变不离其宗，业务才是软件的核心。如果还问我同样的问题，我会回答，业务和技术；工作的第三年，在经历了如此艰难的2020年之后，如果再问题同样的问题，我会回答，意志、业务和技术。 意志 一直以来大概是没有经历过很考验意志的时刻，高中按部就班地学习，然后考上大学；大学也是平平淡淡地度过六年，然后步入职场。连挑灯夜战都没几次，更别说引锥刺股了。工作的前两年虽说也有过曲折，但对比2020年，那都是不值得一提。因为新项目的巨大挑战，从3月初开始，下班的时间点逐渐延后，并在4月份达到了高峰，甚至在4月的最后一周里连睡觉都成了一件奢侈的事情。在整个4月里，为了解决新项目的难题，拼的已经不再是软件技术，更多的是意志力。 记得有一天晚上为了解决一个问题，已经通宵工作到凌晨6点，却还是连问题原因都没找出来。心情的低落，身体的疲惫，那一刻已经临近崩溃。这时想起《指环王》里面Sam对Frodo说的一番话： Frodo: I can’t do this, Sam. Sam: I know. It’s all wrong. By rights, we shouldn’t even be here. But we are. It’s like in the great stories, Mr. Frodo. The ones that really mattered. Full of darkness and danger they were. And sometimes you didn’t want to know the end. Because how could the end be happy? How could the world go back to the way it was when so much bad had happened? https://yrunz.com/p/2019%E5%B9%B4%E7%9A%84%E8%AF%BB%E4%B9%A6%E5%8D%B0%E8%AE%B0/ Tue, 31 Dec 2019 00:00:00 +0000 https://yrunz.com/p/2019%E5%B9%B4%E7%9A%84%E8%AF%BB%E4%B9%A6%E5%8D%B0%E8%AE%B0/ 前言 2019年最大的收获莫过于，静下心来，找到了读书和写作的乐趣。 说起读书的习惯，那要追溯到研究生即将毕业的那一年，在一个盗版的kindle上读完了《曾国藩家书》。书中有一句话让我铭记至今，也让我震撼至今：“少睡多做，一人之生气”。于是便有了早起读书的习惯。研究生在读时，每天都有着充裕的时间，对早起的定义是8点之前，这倒也不算难事；工作之后，9点便要开始上班，对早起的定义也跟着提到7点以前。刚工作的几个月，早起着实是一件极其痛苦的事情，总有着延绵不断的困意，很多时候读着读着便又睡着了，有时甚至把困意带去了公司。多亏了那段时间的磨练，早上的困意逐渐消失，养成了如今早起的习惯。虽说是习惯，但更多的是逼着自己早起，也因此有几段时间以各种借口（最常用的便是工作太累）为由没能坚持这一习惯。很幸运的是，在2019年又重新拾得这一习惯。 到目前为止，在读书习惯上的经历大致可以分成3个阶段。初读《曾国藩家书》时，便下决心要养成早起读书的习惯，这阶段读书的类别大多局限于史类、经济类和软件类；今年7月份读到《穷查理宝典》后，意识到多学科交叉的重要性，便开始刻意读一些各个领域的入门书籍。依旧记得读《穷查理宝典》时激动的心情，醍醐灌顶，读书的乐趣大概源至于此；当前所处的阶段，始于今年11月份读到《文心》。从前为了增加知识的广度（更多的是过于浮躁），喜欢快速把一本书读完，收得其中大概意思。读完《文心》，像是上了一堂不一样的国文课，“读书的目的，重在收得其内容意趣，否则只是文字的游戏而已。”，于是便学会了静下心来读完一本书。 今年有幸在公司听了侯捷老师（《STL源码剖析》的作者）的讲座，他对知识追根究底的精神，深深地影响了我。每次阅读技术书籍读到晦涩难懂之处，想要跳过之时，便会想起侯捷老师的做法，于是就乖乖地重新回去把知识彻底弄懂。 至于写作，对于我这么一个以写代码为业的工科生而言，那是很难想象的事情。从没想过写800字作文都得憋出内伤的我，会在2019年找到写作的乐趣。虽说工作以来，偶尔也会在公司平台写一些总结性的博客，但那都是记流水账似的，谈不上写作。搭建个人博客网站来写文章，那是很久之前的想法了，但一直都没有去落实。一是觉得搭建网站太浪费时间了；另外则认为写作更是浪费时间，还不如多读些书。 今年双十一的时候，趁着优惠在腾讯云买了个云服务器，花上一天时间，搭建了个人博客网站。本着"一份时间出售多次“的原则，顺着把微信订阅号也注册了。尽管如此，对写作的热情还是没有明显地上升，依旧不情愿花超过一小时的时间去完成一篇文章。真正让我找到写作乐趣的，是《文心》。如今，写作不再是一件痛苦的事情，每个周末都舍得花上一天的时间去写完一篇文章。 2019年读了不少书，有匆匆浏览的，也有仔细读完的。基本上做到了读完每本书都有所“触发”，不枉开卷。或是深刻地记住了其中的某句话，又或是学会了其中的一套方法。大体上，今年读过的书可以分成三类：软件类、人文社科类和科普类。 软件类 道 今年对我影响最深的一本技术类书籍，对提升软件设计能力、写出优雅代码很有帮助。相比于Eric Evans的那本《领域驱动设计》，该书结合了大量的例子，让DDD中的各种概念更容易理解些。 领域驱动设计（DDD）的开山之作，内容比较偏理论。去年在学校图书馆偶然遇见，初读晦涩难懂，只依稀记得几个概念。今年读完《实现领域驱动设计》后，再回来重温这本书，里面的一些概念也就清晰多了。 主要介绍软件的复杂性以及降低复杂性的方法，书里用 “深” 和 “浅” 来表示一个模块的复杂性形容得非常形象。 《代码整洁之道》作者的又一力作，涵盖软件研发完整过程及所有核心架构模式。 目前流式计算框架五花八门，这本书以Apache Beam框架为例子，介绍了流式系统的一些通用概念。先了解Apache Beam，再来读这本书，里面的概念更容易理解些。 深入浅出地把微服务的架构设计、开发、测试和发布运维都介绍了一遍，而且提供了很多例子，有助于加深理解微服务的各种概念。 介绍阿里巴巴架构的演变过程，帮助了解时下热门的 “中台“ 概念的由来和含义。 与“架构”相关的概念居多，没有太多的干货，可以当成是睡前书来读。 术 《Java编程思想》的Java 8版本，全面而详细地介绍了Java 8的各种基础知识。即使已经使用Java两年了，读这本书的过程中的还是获益匪浅。 介绍了Java 8的各种新特性，新的日期API、Stream、Optional等都非常地好用，读完这本书，可以让你写出可读性更好的Java 8风格代码。 函数式编程范式逐渐成为各种语言的必备特性，这本书从理论出发，介绍了如何使用Java进行函数式编程。虽然Java不是函数式的语言，但是加点函数式的东西进去会很酷。 深入介绍了Docker的原理，去年初读时也是晦涩难懂。等到今年有了Docker实践之后，再回来读，对里面的概念和原理更有体会了。 今年公司提倡 重构 和 Clean Code，于是重新拿出来读了一遍。书中通过详细的例子介绍了一些常用的重构手法，真正做到了深入浅出。 介绍了HBase的架构原理和用法，适合入门，相对于《HBase权威指南》，这本书确实不容易让人睡觉。 《Effective C++》作者的又一力作，介绍改善C++ 11和C++ 14代码的一些方法和经验，对于写出现代C++风格代码很有帮助。 侯捷老师翻译的一本大作，详细介绍了C++标准库。虽然只是快速浏览了一遍，但是对里面STL的一些用法印象很是深刻。熟练使用STL可以帮助你写出更优雅的C++代码。 介绍使用C++进行API设计时的一些方法和技巧，对提升C++程序员的模块设计水平很有帮助。 人文社科类 今年读过的最好的人文社科类书籍，跟着书中的王先生重新上了堂国文课，极大的提升了我对读书和写作的兴趣。 来自西方的语言学家的著作，作者知识面很广，在书中融入了大量其他领域的知识来介绍语言学，读完会发现，原来人类的语言竟是如此有趣。 读完《文心》，马上又找了鲁迅先生的这本散文集。鲁迅先生用平凡的语言描绘了他的少年往事，很温馨。读到有趣之处，不自觉也露出了笑容。 同样也和语言有关，内容略显枯燥，读完最深刻的就是，对任何的言和事都要保持批判性的思考。 查理·芒格的个人传记，被他那百科全书般的知识所折服，更深受其终身学习、时刻保持求知欲望的精神所影响。 富兰克林是查理·芒格的偶像，从一个普通家庭的小孩，通过自学，逐渐成长为美国的开国元勋，而且还是一个科学家！读完这本书，像是经历了一遍他那传奇的一生。 描写了秦孝公和商鞅对秦国进行变法的那段历史，在作者的笔下，春秋战国变成了一个让人无比向往的时代。读完，让人有种想穿越回到那伟大的时代的冲动。 整个系列有5册，类似于《明朝那些事儿》的风格，但是文笔略逊一筹，可以当作了解宋朝历史的入门读物。 刚开始以为是一本讲投资的书，读了之后发现原来是一本讲如何学习、如何提升自己的书。书中的一些观点和《穷查理宝典》中的很类似，获益良多。 对冲基金公司桥水创始人的人生经验之作，分成传记、生活原则、工作原则三部分。其中传记部分最为精彩，对于 “保持极度开放的头脑” 和 “保持极度求真” 这两个观点印象深刻。 确实可以称得上世界上最简单的会计书，通过案例来解释会计学的种种概念，小白入门会计学的力荐之作。 很早以前就听过这本书了，直到今年才在微信读书上读完，收获比想象中要多，有助于学会如何管理自己的财务。 科普类 读完此书，在了解到神奇的量子世界的同时，也如同亲身经历了那个星光璀璨的伟大时代。科学史上的乌云和暴雨、追逐流星的辉光、重重的迷雾和险滩，感同身受。 这本书极大地扩展了我的宇宙观，读完会让你觉得人类太过渺小，这个世界太过美妙，世间万物有太多值得我们去探索、去求真的规律。如果早些年读到，说不定就选择读物理专业了。 整本书更像是一篇长长的论文，作者对物种起源的论证实在是太过严谨了，以至于读起来略显枯燥。 高中时死记硬背的元素周期表，其中的元素性质早已忘光了。但在作者的笔下，元素竟变得如此的有趣，而且充满了规律，再次体会到了这世界的奇妙。 这个世界充满着随机性，就像书中所说 “你的成功不见得是因为比其他人高明，而很可能是运气的结果。”。这本书可以让你认识到身边的事情多多少少都有些随机成分，并需要对“黑天鹅”事件时刻保持警惕。 这本书通过现实事例来阐述博弈论，看完虽说对博弈论还是一知半解，但明白了这世上很多现象原来是博弈的结果。 这本书读起来很有亲切感，因为几乎整本书都是在讲述“反馈”。对于学控制专业的人而言，这是再熟悉不过的概念了。反馈，真的是无处不在。 总结 王国维曾经说过，读书有三重境界。第一境界 “昨夜西风凋碧树，独上高楼，望尽天涯路“ 说的是博览群书，厚积薄发；第二境界 “衣带渐宽终不悔，为伊消得人憔悴” 说的是坚定不移，追根究底；第三境界 “众里寻她千百度，蓦然回首，那人却在，灯火阑珊处” 说的是融会贯通，知行合一。2019年末之际，有幸拾得读书乐趣，也算是踏进了读书的第一境界。 https://yrunz.com/p/%E4%B8%8D%E4%B8%80%E6%A0%B7%E7%9A%84%E5%9B%BD%E6%96%87%E8%AF%BE/ Sun, 15 Dec 2019 00:00:00 +0000 https://yrunz.com/p/%E4%B8%8D%E4%B8%80%E6%A0%B7%E7%9A%84%E5%9B%BD%E6%96%87%E8%AF%BE/ 起 读完《文心》，就像是重新上了一堂国文课一样，跟之前不太一样的国文课。 国文课是民国时期的叫法，现在都改称为语文课了。从小学、初中、至高中，语文作为一门基础课程 —— 从平时喊“语文、数学、英语”就可得知 —— 在我们学生心里，一直都是最重要的科目。对我而言，语文更是到了让人敬畏的程度。“敬”是语文作为高考必考的科目，不得不认真对待；“畏”是对语文所考察的知识点感到无力，完成一道题，你很难确认自己是否做对了。 不像数学有着固定的公式解法，语文的很多题目感觉就像是随机作答一般。就拿阅读理解中体会作者情感一题来说，就算这次猜对了，下一次给出另外一篇文章，难道就会解了吗？ 以至于高考完以后，心里莫名的愉快，因为从此再无语文课。直到最近读完叶圣陶和夏丐尊两位大师所著的《文心》，对 国文 算是有了重新的认识。书中以故事的形式介绍了国文的种种，阅读的过程，就像是跟着书中王先生重新上了堂国文课。 国文的种类很广，散文、叙事文、诗、词、小说、戏剧等等都属于这一范畴。而国文课所教授的，概括起来，莫过于是 读 的功夫与 写 的功夫。 读 “作者把经验或想象所得的具体的事物翻译成白纸上的黑字，我们读者却要倒翻过去，把白纸上的黑字再依旧翻译为具体的事物。” 从前读描写景物的文章最多只是脑海里浮现出文中情景，读讲述故事的文章最多也只是弄清楚文中情节，至于作者的感情，那是读再多遍也无法体会出来。所以，读大师的文章却丝毫鉴赏不出大师的风采，不看作者，还以为只不过是个普通的作家写出的文章罢了。 这其中原因，除了不善于挖掘作者在文章中所表达的事物之外，另一个很重要的就是不了解文章的背景。每篇文章都有一个背景，作者便是在此背景下，把当时经验、感情编织到文章里面。 辛弃疾的那首起句“郁孤台下清江水”的《菩萨蛮》词，题目只作《题江西造口壁》，如果我们不知道宋室南渡的变乱及造口的位置，读去会有什么趣味呢？ 在读一篇文章之前，尝试着先去把背景弄清楚，这样也许就可以感受到当时作者的情感，读起来也会更有趣味些。 “读书的目的，重在收得其内容意趣，否则只是文字的游戏而已。” 从前为了增加知识的广度（更多的是过于浮躁），喜欢快速把一本书读完，收得其中大概意思。至于书中的一些细节知识点却不会去记住，甚至很多时候根本都没有留意到，想着用到时再回去查阅。这样下来，虽说看起来懂得挺多知识，但其中大部分都是些皮毛，被深入地一问，便回答不上了。 最近公司需要进行软件认证，平时没少进行Java编码，之前《Java编程思想》也看过，而其中一些关于Java的基础知识很多却还是都不懂。直到最近静下心来细读《On Java 8》，才发现很多基础知识在书上都有介绍，只是以前没有关注罢了。 如果很难集中注意对一本书进行细读，可以通过写读书笔记或博客来驱动。读书笔记不是读到好的文段便摘录下来的几句，而是读到这些文段时的感想。“读书要精细，才能写出读书笔记，反过来，试写读书笔记，也就是使读书不苟且的一种方法。”。另外，写博客也是一种好的驱动方法，在阅读时不断去想着如何去给别人讲述这些知识点，这样对知识的理解也会更深刻些。 “读书贵有新得，作文贵有新味，最重要的是触发的功夫。” 所谓触发，就是由一件事感悟到其他的事。比如，读《文心》读到作文追求简炼，便想到也有代码简洁一说，这就是一种触发。我们常常听别人说要多学科交叉，触发就是一种可以把各科知识点关联起来的好方法。在阅读的过程中，多联想些之前学得的知识，便通过触发来逐步构建自己的知识体系。 写 “文字是心的表现，也可有三种分别，就是知的文、情的文与意的文。” 我们心的作用，普通心理学家分为知、情、意三种，文字是心的表现，因此也可分为这三类。知是知识，情是感情，意是意欲。知的文最典型的就是科普文章，作者通过文字给大众传授一些普遍的科学规律；情的文最典型的就是抒情散文，作者借景物或事物来寄托当时的情感；意的文最典型的就是广告，作者通过文字来煽动大家对商品的购买欲望。 写作的第一步就是要认清目标，确定要写哪一类的文章。比如写一篇技术文章，却往文章里添加了些个人感情的文字，这是混淆了写作的目标；第二步就是要认清读者，只写这类读者可以接受的知识。比如要给Java新手写一篇入门的技术文章，而文章里写的却是JDK的源码剖析，这是混淆了文章受众；第三步就是要组织文章，根据中心旨意把要表达的知识组织成一篇条理清晰的文章。 “对于文章的组织，也不妨举出一个总方法来，那就是 ‘回问自己’ 四个大字。” 在写作的三个步骤里，文章的组织是最难的一步，这是关于怎么写好文章的学问。对于写作新手，难免会遇到“心中想法万千，却无从下笔”的窘境。这时候，可以尝试通过回问自己来着手一篇文章写作，以上一篇文章《一步步降低软件复杂性》为例： “是为了要说些什么才写这篇文章的?” —— 为了总结些降低软件复杂性的方法。这样文章的中心意旨就明确了。 “中心意旨在我们意念中间是怎么来的？” —— 读完《A Philosophy of Software Design》一书深有感触，想分享给大家。这样文章依据的材料范围也就确认了。 “这个材料可以增加中心意旨的力量吗？” —— 书中关于深浅模块例子可以很好地比喻软件的复杂性。这样就可以不断筛选出好的素材，文章的主要内容也就确认了。 “还有更简练通顺的表达吗？” —— 这样写好像更通顺一些。这样经过不断的修正，一篇文章也就出来了。 “习作只是法则与手腕的练习，应用之作只是对付他人和事务的东西，创作才是发挥自己天分的真成绩。” 文章写作活动可以分为三类，习作、应用和创作。这三者之中，最基本最重要的是习作。只有当习作到了相当的程度，才能谈得到应用，才能谈得到创作。最基本的往往坚持下来最困难。想起初中时的语文老师蔡先生让我们每天都写一篇随笔，但总是不愿花超过半个小时的时间去完成。有时实在憋不出东西来，就把一段话拆成多行，撑满一页纸后便当作一首新体诗交差了上去。想起来也是可笑至极。如果当时能认真对待些，写作水平也不至于到现在这么差了。 结 《文心》算是今年读过的社科类书中最好的一本了，读完不敢说文章鉴赏和写作能力有多大的提升，但至少兴趣是上来了，舍得花上一天的时间去完成一篇文章了。 所有的习惯和知识都可以通过锻炼习得，文章的读和写也一样，而且它们是可以相互促进的。多读，学习优秀文章的写法，写作水平也就提升了；多写，知道写作在哪方面有缺陷，就会主动去阅读同类优秀文章来学习了。 说到底，最重要的还是坚持，每天坚持让自己进步一点，一年下来，就会发现自己成长了许多。