这片文章想讲一下软件架构的基础，一些基本的原则和思想。我理解的架构是指导我们设计和实现软件的方法论；这意味着我们对复杂度、可扩展性、稳定性（分别对应迭代上手成本、迭代效率、事故损失）这三个方面有非常高的要求，尤其是复杂度，对修改代码的影响范围、成本、难易程度都有显著的影响，是架构要解决的核心问题。 另外，我们也不额外考虑性能，因为业务中的性能瓶颈距离我们讨论的问题往往还有几个数量级，往往是异步、流程优化、io等待等方面更加能有作为，采取什么样的设计方法能起到的作用微乎其微。 设计原则 关于原则，我想说一句话，原则是开发迭代中总结出来的经验，而不是开发迭代的规范。判断是不是原则适用的场景（而不是无脑用原则）往往更加有效，也更加困难。类似“没有银弹”。 KISS: Keep it simple, stupid，不要引入不必要的复杂 DRY: Don‘t repeat youself，不要重复代码 迪米特法则: The Least Knowledge Principle，使用者不知道实现细节 SOLID原则: S 单一职责原则：对象应该仅具有一种单一功能 O 开闭原则：软件的目标应该是可扩展，不可修改 L 里氏替换原则：子类在任何代码中替换父类，行为一致 I 接口隔离原则：多个特定接口要好于一个宽泛用途的接口 D 依赖反转原则：抽象不应该依赖于具体，具体应当依赖于抽象（DDD就是这样，实际需求 ->抽象领域 -> 实现细节） 上面这些法则，几乎都在说： 代码简单可复用，架构高内聚低耦合 过程而非对象 面向对象（OOP）还是面向过程（函数式FP）？ 这里的面向过程是对过程做结构化抽象，并不是平摊代码，这种明显的靶子行为不在我们讨论范围内。 我们先看看面向对象的核心特征（Java为例）：封装、继承、多态 封装：和自己数据有关的操作封装成成员方法，并控制可见性 继承：得到父类的属性和方法 多态：不同类型调用同一个成员方法会产生不同的结果 我们看看非面向对象的做法（Go为例）： 封装：和自己数据有关的操作封装成接收器，并控制可见性（非常类似）；和自己数据无关的操作，直接做成普通函数 继承：得到别人的属性和方法都用组合的方式，避免构造函数、重载、层次设计 多态：类型之间没有继承关系，不同类型实现同一个接口的方法。调用的时候按自己的类型去做出对应行为 封装：函数和数据的耦合 编程的宗派，王垠 对象作为数据访问的方式，是有一定好处的。然而“面向对象”（多了“面向”两个字），就是把这种本来良好的思想东拉西扯，牵强附会，发挥过了头。很多面向对象语言号称“所有东西都是对象”（Everything is an Object），把所有函数都放进所谓对象里面，叫做“方法”（method），把普通的函数叫做“静态方法”（static method）。实际上呢，只有极少需要抽象的时候（为访问对象数据提供间接的封装），你需要使用内嵌于对象之内，跟数据紧密结合的“方法”。其他的时候，你其实只是想表达数据之间的变换操作，这些完全可以用普通的函数表达，而且这样做更加简单和直接。 这种把所有函数放进方法的做法是本末倒置的，因为函数并不属于对象。绝大部分函数是独立于对象的，它们不能被叫做“方法”。强制把所有函数放进它们本来不属于的对象里面，把它们全都作为“方法”，导致了面向对象代码逻辑过度复杂。很简单的想法，非得绕好多道弯子才能表达清楚。很多时候这就像把自己的头塞进屁股里面。 过度封装会导致几个结局： 类的职责逐渐变得模糊，越来越大，远远超出了设计时的职责 对象的成员变量太多，且有没有赋值、赋值产生的依赖很难管理 对象的成员函数太多，类有哪些功能、哪些函数很难辨别 我们实践的时候，会有entity作为数据的封装，和一系列操作entity自身的成员方法。但如果涉及别的对象呢？我们有converter，helper等方法包作为补充 继承vs组合 不要仅仅为了代码复用而继承。当你使用组合来实现代码复用的时候，是不会产生继承关系的。过度使用继承的时候，如果修改了父类，会损坏所有的子类。这是因为子类和父类存在紧耦合。 不要仅仅为了多态而继承。如果你的类之间没有继承关系，并且你想要实现多态，那么你可以通过接口+组合的方式来实现，这样不仅可以实现代码重用，同时也可以实现运行时的灵活性。 Rust程序设计语言 子类不应总是共享其父类的所有特征，但是继承却始终如此。如此会使程序设计更为不灵活，并引入无意义的子类方法调用，或由于方法实际并不适用于子类而造成错误的可能性。 考虑到实际的工程往往都是多层次的组合和复用，继承能带来的收益非常小，但是后期的维护成本却是很难评估的。所以我建议在任何时候都不要使用继承。 我们讨论完面向对象的核心特质：封装、继承、多态，发现这些行为的滥用都需要格外地小心。这也是为什么工业界越来越多的go和rust，仅仅从这一章节讨论的结果来说，这些更年轻的语言汲取了面向对象（数据封装、成员方法）和函数式（接口、一等公民）的优点，取消了他们诸多迷惑的特性，这是在任何语言都可以借鉴的行为。 “干净”的代码，贼差的性能 数据和方法 数据是肉，方法是血。按数据里有多少量的方法，我们划分为下面几种模型。我们按保存用户信息这样一个简单的操作来举例 失血模型 1 2 3 4 // dal 代码 func saveUser(user){.

故事要从虎跳峡的一段徒步说起。走过人满为患的虎跳峡主景区之后，我们迅速远离了商业化的景区服务（不到三层楼的台阶居然修了收费的电梯，破坏了自然的景色不论，居然是封闭的，看不到半点峡谷和河流，甚是乏味）和拍游客照的熙熙攘攘的人群之后，心里略有不甘。眼见太阳已经走过了头顶，徒步的心又痒了起来，于是和朋友们驱车继续深入，前往中虎跳。 行车没有多久，一段曲折的山路就出现在了我们面前。路一看就没有完全修好，一眼就能看到夸张的U形弯，不仅狭窄到仅能一车通过，还有很多细碎的石子。我们下车观望，齐齐看向了队伍中驾驶经验丰富的唐，但路线的艰难和我们超长的9座商务车也只让唐无奈地点起了烟。于是我们讨论了几分钟，便留下了一部分体力不足的朋友原地等待，剩下人徒步上山（后来证明了这是极其明智的选择，路上搭到的便车阿姨已经在这条山路上开了19年，高超的驾驶技术和艰难的路况实在令我们汗颜）。 阿姨把我们送到了徒步的起点，茶马客栈。客栈后是三三两两的韩国人和美国人，看来远道而来的不止我们几个朋友。客栈后的玉龙雪山已经被夕阳渲染成了金色，颇为壮观。我们意识到自己来对地方了，便绕过客栈，顺着路标牌走了起来。 徒步路程并不劳累，但却颇具特色。路上有当地的农户，种植了一些蔬菜，我们不禁讨论起这里拉货和盖房子的困难，他们是如何把生活物资运上山。路上还有很多各种语言的路标牌，指向法国人和美国人开的客栈，我们朝着路标望去，却发现是一条蜿蜒的山路，还要攀爬数百米，只能望洋兴叹。再有很多面对圣山的堆叠起来的石片，我们后来才了解到这是一种古老的祈福仪式，在西南地区十分常见。我们一路走走拍拍，每绕过一座山就能看到远处的雪顶金山又近了一点，在愉悦的心情中行程迅速过半。 即使一路已经看过了各种美景，按理来说应该对大多数景色免疫，但是再次穿过一个山头后，我们还是对眼前的景象大为震惊。被劈的几乎垂直的峭壁中间，是一条极其深邃的山涧，里面传出清脆流水的声音，而我们的小路恰到好处地在山涧上方穿过。走过小桥的时候，虽然双腿发软，但是下面的深谷仿佛有一种魔力，让我的眼睛贪婪地搜刮着峡谷中的诸多细节。再补一眼陡峭的山壁，再看看山壁对面的金山当做佐料，一种壮阔的感觉油然而生。 朋友小W忍不住拿起手机，试图把这种壮阔记录下来，但是尝试过各种角度之后，不免垂头丧气，发现拍到的照片似乎表达不出眼前景色的百分之一。是啊，眼前的景色是流动的，我们心中的印象是由一段时间的感受组合而成，相机只能框选其中一部分，自然无法还原。朋友说要是眼睛里有个无限分辨率的摄像机该多好，就可以完整记录我们看到的景色，可惜现在的科技还无法达到。我思考了下，总觉得即使完全如他所说，却还差了一些什么，但又说不上来。 直到云南的行程过去大半年，一次偶然听到一位写生的画家讲起写生和摄影的区别，我才幡然醒悟。这位老师说，“绘画写生可不是去找哪个合适的角度，而是寻找我们感受最深的一个瞬间”，我终于意识到，除了一双无限分辨率和能看到各种角度的大脑记忆，无论如何都无法描述当时的美；因为美不仅仅包含了峭壁、小溪和雪山的各种角度，还包含了流水的声音，徒步过程的愉悦，曲折的上山过程，和朋友在一起欣赏的心情，甚至从嘈杂游客中回归自然的焕然一新，都是我们感受到美的原因，但这似乎是每个人都迥异的感受，是一张照片远远无法表达的信息。这就是摄影和眼睛的区别。 但如果认为静态的图片无法给人带来相同美的感受，也未免过于武断。艺术史已经告诉我们前人做了诸多尝试，比如捕捉瞬间极美感受的印象派，从各种视角去描绘事物本身特点的立体主义，以及描绘内心感情的抽象主义，甚至他们摒弃的写实流派，都是用不同方法试图还原美的成功案例。当产生强烈的美感时，记住美，了解美，思考美，无论是眼前的画面、景物的角度或组合、声音气味还是心情，都可以体现在照片中，让我们的摄影作品也会成为别人的眼睛。

本文介绍了Go的语言设计和一些容易踩坑的细节： 理解Go为什么X，摆脱原语言的思维 解决写代码时比较困惑和不满的点，对容易出错的语法有个印象 Go学起来非常简单，但是这是语言设计者刻意为之，很多复杂的细节都藏在语言实现里，导致我们迅速学会Go之后不断踩坑 Why Go 2007年，Google设计Go，目的在于提高在并行编程（多核CPU越来越多）、分布式部署、大型代码库（以及维护他们的非常多的开发人员）的情况下的开发效率。设计时，在吸收C++优点的基础上，收集于很多工程师之间流传的的“不要像C++” Go like C++： 内存消耗少 执行速度快 启动快 Go not like C++： 程序编译时间短（按照我过去的经验，一个C++大型项目即使make -j8也需要编译一个小时以上） 像动态语言一样灵活（runtime、interface、闭包、反射） 内置并发支持（C++的协程至少得等到std23才有，非常落后） 丰富的原生库（C++解析json，建立http服务器，使用redis这种都很难找到靠谱的库） 多语义（取消了指针运算、取消隐式类型转换、取消类型别名，取消重载，++和赋值作为表达式…） Go的优点： 面向工程：简单。只有25个关键字，代码风格统一，可读性高，go mod包丰富 自动垃圾回收：语言运行时内置垃圾回收 语言级并发：非常好用的routine和channel，更高层次的并发抽象 静态语言动态特性 Go的缺点： runtime的性能还需要提高 没有泛型 冗余的错误处理 Go mod不够完善 Go语⾔将⾛向何⽅? 我为什么放弃Go语言 Go的设计哲学 创始人Rob Pike在SPLASH上的演讲，阐述了设计Go的初衷 许式伟，Go和Java在继承观念上的对比 对面向对象的批评 王垠：解密“设计模式”，对设计模式的批评 少即是多（less is more）：如果一个特性并不对解决任何问题有显著价值，那么go就不提供它；如果需要一个特性，那么只有一种方法去实现 面向接口编程：非侵入式接口，反对继承、反对虚函数和虚函数重载（多态）、删除构造和析构函数 正交+组合的语言特性：语言的特性之间相互独立，不相互影响。比如类型和方法是互相独立的，类型之间也是相互独立的，没有子类，包也没有子包。不同特性用组合的方式来松耦合 并发在语言层面支持：并发更好利用多核，有更强的表现力来模拟真实世界 在设计上，Go秉承了C的简单粗暴。 为什么没有继承？ Go没有子类型的概念，只能把类型嵌入到另一个类型中，所以没有类型系统。Go的作者认为类型系统被过度使用了，应该在这个方向上退一步。 使用伸缩性良好的组合，而不是继承 数据和方法不再绑定在一起，数据的集合用struct，方法的集合用interface，保持正交 类似子类父类的系统造成非常脆弱的代码。类型的层次必须在早期进行设计，通常会是程序设计的第一步，但是一旦写出程序后，早期的决策就很难进行改变了。所以，类型层次结构会促成早期的过度设计，因为程序员要尽力对软件可能需要的各种可能的用法进行预测，不断地为了避免挂一漏万，不断的增加类型和抽象的层次。这种做法有点颠倒了，系统各个部分之间交互的方式本应该随着系统的发展而做出相应的改变，而不应该在一开始就固定下来。 作者附了一个例子，是一些以接口为参数并且其返回结果也是一个接口的函数： 1 2 3 4 5 6 // 入参是接口的函数，而不是成员方法 func ReadAll(r io.Reader) ([]byte, error) // 封装器 - 出入参都是接口 func LoggingReader(r io.