阅读笔记

阅读感悟 暂略 阅读摘录 《我看见的世界：李飞飞自传》 [美]李飞飞 82个笔记 03 鸿沟渐窄 ◆ 1956年，他们将好奇心编撰成文，提出了现在广为人知的《达特茅斯人工智能夏季研究项目提案》，“人工智能”一词就是在这份提案中诞生的 ...

阅读感悟 暂略 阅读摘录 《奔跑吧，程序员：从零开始打造产品、技术和团队》 叶夫根尼·布里克曼 194个笔记 1.2 什么是科技创业公司 ◆ 创业公司就是在极度不确定的条件下创造新产品或服务的人类组织。——Eric Ries, 《精益创业》 ...

最近发现 ★ wizard zines 中的这本 《Hell Yes! CSS!》 对于理解 CSS 的核心概念特别有用。结合 DeepSeek 的解释，对于理解 CSS 似乎非常有帮助，因此结合原文核心内容和 DeepSeek 的解释汇集为本文。 ...

阅读感悟 职场道路必经之路，通透一些人间的事情。 阅读摘录 《赵玉平说职场智慧》 赵玉平 137个笔记 第一章 好领导要送公明——宋江的团队领导策略 ◆ 宋江这个没形象、没背景、没水平的人，凭什么领导了英雄团队？宋江的团队领导策略其实就在他的名字中，宋公明——送、公、明。 ...

阅读感悟 暂略 阅读摘录 《凤凰架构：构建可靠的大型分布式系统》 周志明 41个笔记 ** 自序** 软件工程小说《凤凰项目》（见图1）讲述了徘徊在死亡边缘的凤凰项目在精益方法下浴火重生的故事 ** 5.2.2 OAuth 2** [插图] ** 第10章 可观测性** 日志收集和分析大多被统一到Elastic Stack(ELK)技术栈上，如果说未来还能出现什么变化的话，也就是其中的Logstash有被Fluentd取代的趋势，让ELK变成EFK，但整套Elastic Stack技术栈的地位已是相当稳固 度量方面，跟随Kubernetes统一容器编排的步伐，Prometheus也击败了度量领域里以Zabbix为代表的众多前辈，即将成为云原生时代度量监控的事实标准，虽然从市场角度来说Prometheus还没有达到Kubernetes那种“拔剑四顾，举世无敌”的程度，但是从社区活跃度上看，Prometheus已占有绝对的优势，在Google和CNCF的推动下，未来可期。 Kubernetes是CNCF第一个孵化成功的项目，Prometheus是CNCF第二个孵化成功的项目。Kubernetes起源于Google的编排系统Borg，Prometheus起源于Google为Borg做的度量监控系统BorgMon。 ** 11.1.4 封装系统：LXC** LXC的出现肯定受到了OpenVZ和Linux-VServer的启发，站在巨人的肩膀上过河并没有什么不对。可惜的是，LXC在设定自己的发展目标时，也被前辈们的影响所局限住了。LXC眼中的容器与OpenVZ和Linux-VServer定义的并无差别，是一种封装系统的轻量级虚拟机，而Docker眼中的容器则是一种封装应用的技术手段。这两种封装理念在技术层面并没有什么本质区别，但应用效果差异巨大 以封装系统为出发点，仍是按照先装系统再装软件的思路，就永远无法在一两分钟甚至十几秒钟就构造出一个合乎要求的软件运行环境，也决定了LXC不可能形成今天的容器生态，所以，接下来舞台的聚光灯落到了Docker身上 ** 11.1.5 封装应用：Docker** 至少对早期的Docker而言，确实没有什么能构成壁垒的技术，它的容器化能力直接来源于LXC，它的镜像分层组合的文件系统直接来源于AUFS。在Docker开源后不久，有人仅用一百多行Shell脚本便实现了Docker的核心功能（名为Bocker[插图]，提供了docker build/pull/images/ps/run/exec/logs/commit/rm/rmi等功能）。 那为何历史选择了Docker，而不是LXC或者其他容器技术呢？对于这个问题，笔者将引用（转述非直译，有所精简）DotCloud公司（当年创造Docker的公司，已于2016年倒闭）创始人Solomon Hykes在Stackoverflow上的一段问答来回应。 为了符合OCI标准，Docker推动自身的架构继续向前演进，首先将libcontainer独立出来，封装重构成runC项目，并捐献给Linux基金会管理。runC是OCI运行时的首个参考实现，提出了“让标准容器无所不在”的口号。 为了能够兼容所有符合标准的OCI运行时实现，Docker进一步重构了Docker Daemon子系统，将其中与运行时交互的部分抽象为containerd项目，这是一个负责管理容器执行、分发、监控、网络、构建、日志等功能的核心模块，内部会为每个容器运行时创建一个containerd-shim适配进程，默认与runC搭配工作，但也可以切换到其他OCI运行时实现上（然而实际并没做到 2016年，Docker把containerd项目捐献给CNCF管理。runC与containerd两个项目的捐赠托管，既是Docker对开源信念执着的追求，也是Docker在众多云计算大厂夹击下无奈的自救，这两个项目将成为未来Docker消亡和存续的伏笔。（看到本节末尾你就能理解这句矛盾的话了。） ** 11.1.6 封装集群：Kubernetes** Kubernetes Master→kubelet→DockerManager→Docker Engine→containerd→runC ，现在连LXC都还没有被淘汰，反倒发展出了更加专注于与OpenVZ等系统级虚拟化竞争的LXD，相信Docker本身也很难彻底消亡，如已经习惯使用的CLI界面，已经形成成熟生态的镜像仓库等都应该会长期存在，只是在容器编排领域，未来的Docker很可能只会以runC和containerd的形式存续下去，毕竟它们最初都源于Docker ** 11.2.1 隔离与协作** Docker设计的Dockerfile只允许有一个ENTRYPOINT，这并非无故添加的人为限制，而是因为Docker只能通过监视PID为1的进程（即由ENTRYPOINT启动的进程）的运行状态来判断容器的工作状态是否正常，然后根据状态决定是否执行清理自动重启等操作。 ** 11.2.2 韧性与弹性** 故障恢复、滚动更新、自动扩缩这些特性，在云原生时代里常被概括成服务的韧性(Resilience)与弹性(Elasticity)，ReplicaSet、Deployment、Autoscaling的用法，也属于所有Kubernetes教材资料都会讲到的“基础必修课” 如果你准备学习Kubernetes或者其他与云原生相关的技术，建议最好不要死记硬背地学习每个资源的元数据文件如何编写、有哪些指令、有哪些功能，而是站在解决问题的角度去理解为什么Kubernetes要设计这些资源和控制器，为什么这些资源和控制器会被设计成现在这种样子 ** 11.3.1 Kustomize** 最初，由Kubernetes官方给出的“如何封装应用”的解决方案是“用配置文件来配置配置文件”，这不是绕口令，你可以理解为一种针对YAML的模板引擎的变体 Kubernetes官方认为应用就是一组具有相同目标的Kubernetes资源的集合 如果逐一管理、部署每项资源元数据过于烦琐的话，那就提供一种便捷的方式，把应用中不变的信息与易变的信息分离开以解决管理问题，把应用所有涉及的资源自动生成一个多合一(All-in-One)的整合包以解决部署问题 ** 11.3.3 Operator与CRD** 有状态应用(Stateful Application)与无状态应用(Stateless Application)是指应用程序是否要自己持有运行所需的数据，如果程序每次运行都跟首次运行一样，不会依赖之前任何操作遗留下来的痕迹，那它就是无状态的；反之，如果程序推倒重来之后，用户能察觉到该应用已经发生变化，那它就是有状态的 Operator提供了一种kind:Elasticsearch的自定义资源，在它的帮助下，仅需十行代码，将用户的意图是“部署三个版本为7.9.1的ES集群 ** 12.1.1 网络通信模型** 从整体上看，Linux系统的通信过程无论按理论上的OSI七层模型，还是以实际上的TCP/IP四层模型来解构，都明显呈现出“逐层调用，逐层封装”的特点，这种逐层处理的方式与栈结构，譬如程序执行时的方法栈很类似，因此它通常被称为“Linux网络协议栈”，简称“网络栈”，有时也称“协议栈” [插图]图12-1 Linux系统下的网络通信模型 ** 12.1.2 干预网络通信** 这套名为Netfilter的框架是Linux防火墙和网络的主要维护者Rusty Russell提出并主导设计的，它围绕网络层（IP协议）的周围，埋下了五个钩子(Hook)，每当有数据包流到网络层，经过这些钩子时，就会自动触发由内核模块注册在这里的回调函数，这样程序代码就能够通过回调函数来干预Linux的网络通信 [插图] ** 12.1.3 虚拟化网络设备** 普通交换机只会单纯地做二层转发，Linux Bridge却还支持把发给它自身的数据包接入主机的三层协议栈中 对于通过brctl命令显式接入网桥的设备，Linux Bridge与物理交换机的转发行为是完全一致的，都不允许给接入的设备设置IP地址，因为网桥是根据MAC地址做二层转发的，就算设置了三层的IP地址也毫无意义。然而Linux Bridge与普通交换机的区别是除了显式接入的设备外，它自己也无可分割地连接着一台有着完整网络协议栈的Linux主机，因为Linux Bridge本身肯定是在某台Linux主机上创建的，可以看作Linux Bridge有一个与自己名字相同的隐藏端口，隐式地连接了创建它的那台Linux主机 Linux Bridge允许给自己设置IP地址，比普通交换机多出一种特殊的转发情况：如果数据包的目的MAC地址为网桥本身，并且网桥设置了IP地址的话，那该数据包即被认为是收到发往创建网桥那台主机的数据包，此数据包将不会转发到任何设备，而是直接交给上层（三层）协议栈去处理 此时，网桥就取代了eth0设备来对接协议栈，进行三层协议的处理。设置这条特殊转发规则的好处是：只要通过简单的NAT转换，就可以实现一个最原始的单IP容器网络。这种组网是最基本的容器间通信形式， 单臂路由不属于任何VLAN，它与交换机之间的链路允许任何VLAN ID的数据包通过，而这个通信的接口也被称为TRUNK。这样，A1要和B2通信，就要将数据包先发送给路由（只需把路由设置为网关即可），然后路由会根据数据包上的IP地址得知B2的位置，去掉VLAN-A的VLAN Tag，改用VLAN-B的VLAN Tag重新封装数据包后再发回给交换机，交换机收到后就可以顺利转发给B2了 ** 14.2 服务质量与优先级** Kubernetes选择哪个节点运行Pod，只会根据requests的值来进行决策；limits才是供cgroups使用的，Kubernetes在向cgroups传递资源配额时，会按照limits的值来进行设置。 用户提交工作负载时设置的资源配额，并不是容器调度必须严格遵守的值，因为根据实际经验，大多数的工作负载在运行过程中真正使用到的资源，其实都远小于它所请求的资源配额。 要进行驱逐，首先Kubernetes就必须制定资源不足时该先牺牲哪些Pod、保留哪些Pod的明确准则，由此就形成了Kubernetes的服务质量等级(Quality of Service Level，QoS Level)和优先级(Priority)的概念 Kubernetes目前提供的服务质量等级一共分为三级，由高到低分别为Guaranteed、Burstable和BestEffort 如果Pod中所有的容器都设置了limits和requests，且两者的值相等，那此Pod的服务质量等级便为最高的Guaranteed；如果Pod中有部分容器的requests值小于limits值，或者只设置了requests而未设置limits，那此Pod的服务质量等级为第二级Burstable；如果是上文说的那种情况，limits和requests两个都没设置则属于最低的BestEffort ** 14.3 驱逐机制** Pod的驱逐机制是通过kubelet来执行的，kubelet是部署在每个节点的集群管理程序，由于本身就运行在节点中，所以最容易感知到节点的资源实时消耗情况。kubelet一旦发现某种不可压缩资源将要耗尽时，就会主动终止节点上较低服务质量等级的Pod，以保证其他更重要的Pod的安全。被驱逐的Pod中的所有容器都会被终止，Pod的状态也会被更改为Failed ·软驱逐：通常配置一个较低的警戒线（譬如可用内存仅剩20%），触及此线时，系统将进入一段观察期。如果只是暂时的资源抖动，在观察期内能够恢复到正常水平的话，那就不会真正启动驱逐操作。否则，若资源持续超过警戒线一段时间，就会触发Pod的优雅退出(Grace Shutdown)，系统会通知Pod进行必要的清理工作（譬如将缓存的数据落盘），然后自行结束。在优雅退出期结束后，系统会强制杀掉还未曾自行了断的Pod 硬驱逐：通常配置一个较高的终止线（譬如可用内存仅剩10%），一旦触及此红线，立即强制杀掉Pod，而不会优雅退出 软驱逐是为了减少资源抖动对服务的影响，硬驱逐是为了保障核心系统的稳定 总而言之，在Kubernetes还没有成熟到变为“傻瓜式”容器编排系统之前，因地制宜地配置和运维是非常必要的 来自微信读书 ...

阅读感悟 暂略 阅读笔记 《芯片战争：世界最关键技术的争夺战（财之道丛书）》 克里斯·米勒 17个笔记 ** 推荐序 国运升级点** 客观地说，当今中国的经济和科技发展水平，不但比不了美国，而且连20世纪80年代正在崛起中的日本都比不了。当时日本已经有索尼、夏普、丰田、本田、东芝、佳能、尼康等一系列拥有自己的核心技术、自己的设计、自己的品牌，且受到全世界消费者追捧的公司。日本曾经在芯片上把美国打到近乎绝望。就连韩国，早在一二十年前，也已经有了三星、LG、现代这样的全球知名企业。而当今中国除了华为和字节跳动，全球品牌还很少，独家技术也很少 中国排在前列的大公司都是像石油、银行、电网和电信这些国有企业，一些国产品牌只在中国能做到家喻户晓。中国经济体量大、数字好看，而我们的真实经济实力，特别是创新能力，距离发达国家还很远 中国被“卡脖子”的绝不仅仅是芯片。我们在工业母机、医疗仪器、农牧业育种等很多领域都受制于人。我们的产业升级远远没有完成。芯片只是一个聚焦点，但是透过芯片，我们也许可以反思一下一些人过去那种比较幼稚的世界观 简单说，米勒这本书能纠正我们三个错误认知。 第一个错误认知是任何高科技都可以用“堆积”的方法获得。 不可堆积的东西往往要求高水平人才的奇思妙想，要求复杂的环境，要求可遇不可求的机遇。 而要造芯片，从芯片设计软件到光刻机，再到硅材料，每一个步骤都需要很多个聪明人的奇思妙想，这里没有“大力出奇迹”。你需要成千上万个“邓稼先”和“于敏”，而且他们必须都在自己的行业里做得树大根深。 芯片的科学原理没有秘密，都是公开的。但是要做到技术上的可行性，尤其是商业上的可盈利性，那可就太难了。花一亿元人民币造出一颗芯片是没有意义的，我们必须保证大规模制造、保证良品率、保证更新速度，还得保证做出来很便宜才行 现实是中国制造从未离开过全世界的技术支持 是，我们现在有一些像量子信息、碳纳米管芯片之类的领先研究，但是这些都还处于探索科学可能性的阶段——全世界有无数个类似的研究在赌，它们距离技术可行性、商业可盈利性还差十万八千里，根本谈不上“第四次工业革命”。 第二个错误认知是创新应该由政府来主导。 第三个错误认知是我们应该独立自主。 现实是就芯片技术而言，连美国都不能独立自主。美国必须依赖荷兰的光刻机、日本的硅片和中国台湾的制造 所谓的芯片战，美国卡中国脖子，恰恰就是逼着中国去独立自主。这叫作“把互相依赖武器化”：为了打击你，我不让你依赖我 互相依赖是一种生存条件，被孤立是一种打压。现代化已经形成了一个全球“圈子”，只有圈里人得到这个圈的各种好处和帮助，互相依赖，才能把事情做成，独立于圈外没有任何前途。 不被卡脖子的正确做法不是独立自主，而是让自己变得更值得依赖，让包括美国在内的全世界不得不依赖我们，以此跟美国讨价还价，若你要再敢卡我脖子我就卡你脖子 然而进入21世纪，中国经济就到了下一个阶段。允许引进的技术已经引进完毕，剩下的得自己研发，创新走到了无人区。人口步入老龄化，劳动力越来越贵。全球化在退潮，美国等国家已经不拿中国当发展中国家，开始对抗 来自微信读书 ...

解密 《解密（陈思诚导演，刘昊然主演电影同步上映中）》 麦家 66个笔记 02 ◆ 牛顿数学桥是剑桥大学城里的一大景观，全桥由7177根大小不一的木头衔接而成，有10299个接口，如果以一个接口用一枚铁钉来计算，那么至少需要10299枚铁钉。但牛顿把所有铁钉都倒进了河里，整座桥没用一枚铁钉，这就是数学的奇妙。 ...

阅读感悟 暂略 阅读摘录 《Helm学习指南：Kubernetes上的应用程序管理》 马特·布彻 马特·法里纳 乔什·多利茨基 32个笔记 1.1 云原生生态系统 ◆ 有一项关键的技术提供了移动容器镜像的能力，即镜像登记站（image registry），这是一种专门的块存储技术，它容纳容器，使其可供主机使用。主机可以将容器镜像推送（push）到登记站，该动作会将各层传输到登记站。然后另一台主机可以将镜像从登记站拉取（pull）到该主机的环境中，如此一来该主机就可以执行此容器了。 ...

阅读感悟 暂略 摘录笔记 《大话设计模式》 程杰 225个笔记 ** 前言** [插图]本书希望能给渴望了解OO世界的初学者、困惑于僵硬、脆弱、无法复用的代码编程体验者、一直打着OO编程的旗号，做着过程式开发的基于对象的编程实践者一些好的建议和提示。 ** 本书起因** 技术课的教学同样如此，除非学生是抱着极大的学习动机来参与其中，否则照本宣科的教学、枯燥乏味的讲解，学生一定会被庞杂的概念和复杂的逻辑搅晕了头脑，致使效果大打折扣。 ** 本书读者** GoF的《设计模式》好比是世界顶级足球射门集锦，《重构》、《敏捷软件开发》、《设计模式解析》好比是一场场最精彩的足球比赛。 可是我并不只是想做一个球迷（软件使用者），而是更希望自己能成为一个足球运动员（软件设计编程者），能够亲自上场比赛，并且最终能成为球星（软件架构师） 本书显然不是培养足球明星（软件架构师）的俱乐部，而是训练足球基本功的学校，培训的是初学足球的小球员（面向对象的程序员），本书希望的是读者阅读后可以打好面向对象的基础，从而更加容易并深入的去理解和感受GoF的《设计模式》以及其他大师作品的魅力。 ** 本书研读方法** 本书源代码下载地址：http://www.cnblogs.com/Files/cj723/BigTalkDesignPattenSourceCode.rar也可到清华大学出版社网站（www.tup.com.cn）查找并下载本书源代码。 我的电子邮箱是chengjielong@163.com，博客是http://cj723.cnblogs.com/。 ** 关于本书学习的疑问解答** 设计模式有四境界：1．没学前是一点不懂，根本想不到用设计模式，设计的代码很糟糕；2．学了几个模式后，很开心，于是到处想着要用自己学过的模式，于是时常造成误用模式而不自知；3．学完全部模式时，感觉诸多模式极其相似，无法分清模式之间的差异，有困惑，但深知误用之害，应用之时有所犹豫；4．灵活应用模式，甚至不应用具体的某种模式也能设计出非常优秀的代码，以达到无剑胜有剑的境界。 ** 不是一个人在战斗** 本书起源于本人在“博客园”网站的博客http://cj723.cnblogs.com/中的一个连载文章《小菜编程成长记》。 写作过程中，本人还参考了http://www.dofactory.com/关于23个设计模式的讲解，并引用了他们的结构图和基本代码 ** 1.5 活字印刷，面向对象** “第一，要改，只需更改要改之字，此为可维护；第二，这些字并非用完这次就无用，完全可以在后来的印刷中重复使用，此乃可复用；第三，此诗若要加字，只需另刻字加入即可，这是可扩展；第四，字的排列其实可能是竖排可能是横排，此时只需将活字移动就可做到满足排列需求，此是灵活性好。” ** 1.6 面向对象的好处** 是呀是呀，你说得没错，中国古代的四大发明，另三种应该都是科技的进步，伟大的创造或发现。而唯有活字印刷，实在是思想的成功，面向对象的胜利。 ** 1.11 UML类图** 类图分三层，第一层显示类的名称，如果是抽象类，则就用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法或行为。注意前面的符号，‘+’表示public，‘-’表示private，‘#’表示protected。” 它表示一个接口图，与类图的区别主要是顶端有<<interface>>显示。第一行是接口名称，第二行是接口方法 接口还有另一种表示方法，俗称棒棒糖表示法 继承关系用空心三角形+实线来表示。” 实现接口用空心三角形+虚线来表示 当一个类‘知道’另一个类时，可以用关联（association）。 聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分[DPE]（DPE表示此句摘自《设计模式》（第2版） 聚合关系用空心的菱形+实线箭头来表示 合成（Composition，也有翻译成‘组合’的）是一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样[DPE]。 合成关系用实心的菱形+实线箭头来表示 依赖关系（Dependency），用虚线箭头来表示。” ** 2.3 简单工厂实现** 面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类 ** 2.4 策略模式** 策略模式定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户 封装变化点是我们面向对象的一种很重要的思维方式 ** 2.6 策略与简单工厂结合** 你的意思是说，简单工厂模式我需要让客户端认识两个类， CashSuper和CashFactory，而策略模式与简单工厂结合的用法，客户端就只需要认识一个类CashContext就可以了。耦合更加降低。” ** 2.7 策略模式解析** 策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合[DPE] “当然。这个办法就是用到了反射技术，不是常有人讲，‘反射反射，程序员的快乐’，不过今天就不讲了，以后会再提它的。” （注：在抽象工厂模式章节有对反射的讲解） ** 3.4 单一职责原则** 就一个类而言，应该仅有一个引起它变化的原因[ASD] ** 3.5 方块游戏的设计** 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏[ASD] 软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离[ASD] 如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责[ASD]，就应该考虑类的职责分离。” ** 4.2 开放-封闭原则** 开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改 ** 4.3 何时应对变化** 开放-封闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。 “在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化[ASD] 我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难[ASD]。 开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要[ASD]。 ** 5.3 依赖倒转原则** 因为CPU的对外都是针脚式或触点式等标准的接口。啊，我明白了，这就是接口的最大好处。CPU只需要把接口定义好，内部再复杂我也不让外界知道，而主板只需要预留与CPU针脚的插槽就可以了。 依赖倒转原则，原话解释是抽象不应该依赖细节，细节应该依赖于抽象，这话绕口，说白了，就是要针对接口编程，不要对实现编程 高层模块不应该依赖低层模块。两个都应该依赖抽象 抽象不应该依赖细节。细节应该依赖抽象 比如我们做的项目大多要访问数据库，所以我们就把访问数据库的代码写成了函数，每次做新项目时就去调用这些函数。这也就叫做高层模块依赖低层模块。 ** 5.4 里氏代换原则** “里氏代换原则是Barbara Liskov女士在1988年发表的[ASD]，具体的数学定义比较复杂，你可以查相关资料，它的白话翻译就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化，简单地说，子类型必须能够替换掉它们的父类型[ASD]。” 里氏代换原则（LSP）：子类型必须能够替换掉它们的父类型。[ASD] 只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。

阅读记录 很奇怪，书中说大部分程序员都是乐观主义者，但是我自以为自己不是，也是。 这本 ...