写代码要有对于“美”的追求Google 的很多同学说（至少 hankzheng 这么说），软件工程=科学+艺术。当前业界，很多人，不讲科学。工程学，计算机科学，都不管。就喜欢搞“巧合式编程”。刚好能工作了，打完收工，交付需求。绝大多数人，根本不追求编码、设计的艺术。对细节的好看，毫无感觉。对于一个空格、空行的使用，毫无逻辑，毫无美感。用代码和其他人沟通，连基本的整洁、合理都不讲。根本没想过，别人会看我的代码，我要给代码“梳妆打扮”一下，整洁大方，美丽动人，还极有内涵。“窈窕淑女，君子好逑”，我们应该对别人慷慨一点，你总是得阅读别人的代码的。大家都对美有一点追求，就是互相都慷慨一些。很无奈，我把对美的追求说得这么“卑微”，必须要由“务实的需要”来构建必要性。而不是每个工程师发自内心的，像对待漂亮的异性、好的音乐、好的电影一样的发自内心的需要它。认为代码也是取悦别人、取悦自己的东西。如果我们想做一个有尊严、有格调的工程师，我们就应该把自己的代码、劳动的产物，当成一件艺术品去雕琢。务实地追求效率，同时也追求美感。效率产出价值，美感取悦自己。不仅仅是为了一口饭，同时也把工程师的工作当成自己一个快乐的源头。工作不再是 overhead，而是 happiness。此刻，你做不到，但是应该有这样的追求。当我们都有了这样的追求，有一天，我们会能像 Google 一样做到的 。
08
应用程序框架是实现细节以下是《整洁架构之道》的原文摘抄：
我们与框架作者之间的关系是非常不对等的。我们要采用某个框架就意味着自己要遵守一大堆约定，但框架作者却完全不需要为我们遵守什么约定。请仔细想想这一关系，当我们决定采用一个框架时，就需要完整地阅读框架作者提供的文档。在这个文档中，框架作者和框架其他用户对我们提出进行应用整合的一些建议。一般来说，这些建议就是在要求我们围绕着框架来设计自己的优秀的系统架构。譬如，框架作者会建议我们基于框架中的基类来创建一些派生类，并在业务对象中引入些框架的工具。框架作者还会不停地催促我们将应用与框架结合得越紧密越好。对框架作者来说，应用程序与自己的框架耦合是没有风险的。毕竟作为作者，他们对框架有着绝对的控制权，强耦合是应该的。与此同时，作者当然是非常希望我们的应用与其框架紧密结合的，因为这意味着脱离框架会很困难。作为框架作者来说，没有什么比让一堆用户心甘情愿地基于他的框架基类来构建派生类更自豪的事情了。换句话说，框架作者想让我们与框架订终身-这相当于我们要对他们的框架做一个巨大而长期的承诺，而在任何情况下框架作者都不会对我们做出同样的承诺。这种婚姻是单向的。我们要承担所有的风险，而框架作者则没有任何风险。解决方案是：请不要嫁给框架!我们可以使用框架-但要时刻警惕，别被它拖住。我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它进入内圈。如果框架要求我们根据它们的基类来创建派生类，就请不要这样做，我们可以创造一些代理类，同时把这些代理类当作业务逻辑的插件来管理。另外，不要让框架污染我们的核心代码，应该依据依赖关系原则(DIP)，将它们当作核心代码的插件来管理。以 Spring 为例，它作为一个依赖注入框架是不错的。也许我们会需要用 Spring 来自动连接应用程序中的各种依赖关系。这不要紧，但是千万别在业务对象里到处写 @autowired 注释。业务对象应该对 Spring 完全不知情才对。反之，我们也可以利用Spring将依赖关系注入到 Main 组件中，毕竟 Main 组件作为系统架构中最低层、依赖最多的组件，它依赖于 Spring 并不是问题。
对，DIP 大发神威。我觉得核心做法就是:▶︎ 核心代码应该通过 DIP 来让它不要和具体框架绑定！它应该使用 DIP（比如代理类），抽象出一个防腐层，让自己的核心代码免于腐坏。▶︎ 选择一个框架，你不去做防腐层(主要通过 DIP)，你就是单方面领了结婚证，你只有义务，没有权利。同学们要想明白。同学们应该对框架本身是否优秀，是否足够组件化，它本身能否在项目里做到可插拔，做出思考和设计。trpc-go 对于插件化这事儿，做得还不错，大家会积极地使用它。trpc-cpp 离插件化非常远，它自己根本就成不了一个插件，而是有一种要强暴你的感觉，你能凭直觉明显地感觉到不愿意和它定终身。例如，trpc-cpp 甚至强暴了你构建、编译项目的方式。当然，这很多时候是 c++语言本身的问题。“解耦”、“插件化”就是 Golang 语言的关键词。大家开玩笑说，C++已经被委员会玩坏了，加入了太多特性。less is more, more means nothing。C++从来都是让别的工具来解决自己的问题，trpc-cpp 可能把自己松绑定到 bazel 等优秀的构建方案。寻求优秀的组件去软绑定，提供解决方案，是可行的出路。我个人喜欢 Rust。但是大家还是熟悉 cpp，我们确实需要一个投入更多人力做得更好的 trpc-cpp。
看错题集没多少用, 我们需要教练和传承上面我列了很多例子，是我能列出来的例子中的九牛一毛。但是，我列一个非常庞大的错题集没有任何用，我也不再例举更多。只有当大家信奉了敏捷工程的美，认可好的代码架构对于业务的价值，才能真正地做到举一反三，理解无数例子，能对更多的 case 自己做出合理的判断。同时，把好的判断传播起来，做到“群体免疫”，最终做好 review，做好代码质量。
林强约 18 分钟