后端好书阅读与推荐

阿里巴巴Java开发手册

阿里巴巴Java开发手册 (豆瓣): https://book.douban.com/subje...

阿里在Java技术方面具有广阔而深入的研究和应用，而本书正是阿里技术团队的集体智慧结晶和经验总结，非常值得借鉴和学习。

亮点：

• 现代软件行业的高速发展对开发者的综合素质要求越来越高，因为不仅是编程知识点，其它维度的知识点也会影响到软件的最终交付质量。的确是这样，这一行不存在“一招鲜吃遍天”的说法，每个人都要进行广泛而深入的终身学习
• 现代软件架构的复杂性需要协同开发完成，如何高效地协同呢？无规矩不成方圆，无规范难以协同。适当的规范绝对不是扼杀创新性，而是管理软件复杂度的一种手段
• 为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达其意。不要嫌长，毕竟这是Java的一大特色(*￣︶￣)
• 任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。变量像自己的小孩，尽量在自己的视线内，变量作用域太大，无限制的到处跑，那么你会担心的。这一句说的很贴切
• 在高并发场景中，避免使用” 等于” 判断作为中断或退出的条件。如果并发控制没有处理好，容易产生等值判断被“击穿” 的情况（亦即瞬时状态跳变），使用大于或小于的区间判断条件来代替可以保证一定能终止
• 捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。如果预期对方抛的是绣球，实际接到的是铅球，就会产生意外情况。
• 好的单元测试必须遵守 AIR 原则：Automatic（自动的，不要人工的print而是自动的Assert）、Independent（独立的，不依赖于其他单元测试、也不依赖于其他模块，必要时可以Mock）、Repeatable（可重复执行，支持持续集成）
• 对用户相关的数据要做校验（防止攻击）、鉴权（防止越权操作）、脱敏（防止信息泄露）、转义展示（避免代码逻辑泄露，或者让用户懵逼），还要做防刷（避免资损或骚扰用户）、违禁词过滤等风控策略
• MySQL中 varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果长度大于此值，定义字段类型为 text，独立一张表，用主键对应，避免影响其它字段索引效率（因为MySQL是按行存储的）
• 分层设计中，Dao层异常不要打印，而是直接抛出，因为Service层一定会借助日志并记录；web层绝不应抛出异常，因为已处于顶层，应自己记录，并选择合适页面渲染给用户；对于领域对象，DO与数据表一致,DTO是service向外传输对象,BO是Service层封装的业务逻辑对象,AO是Web与Service之间的复用对象模型,VO是显示层对象,Querry是上层给下层的查询对象

书比较薄，涉及面也较广，可以把本书当做一个目录，我们自己按需去发散，针对每个方面进行更深入的学习。
此外本书还有进阶版，可以看做是对本书的一个扩充。

Clean Architecture

Clean Architecture (豆瓣): https://book.douban.com/subje...

本书是代码整洁之道作者 Robert C·Martin 的Clean系列的最新大作，译为架构整洁之道，是作者多年软件架构经验的合集，值得细细品味。

亮点：

• 软件架构的终极目标是用最小的人力成本来构建满足和维护该系统的需求。如果你觉得好的架构太费钱，大可看看先用随意的架构然后再慢慢改的成本，事实上国内好多公司也是这样做的，都是快速扩张追求速度，后面再慢慢还技术债。从软件开发的角度看，一开始偷懒妄想后期重构是不大可能的（因为市场的压力永远不会消退，你永远都在完成新功能，重构旧代码的机会不会再有了，系统越来越乱），所以精心设计的架构的确对后来的工作有好处，但是我觉得对于需要快速抢占市场的应用，先跑起来才是王道，这是已经超出了软件开发的范畴的理念。
• 软件的价值来自于两个维度：行为（业务逻辑，是直接产生利润的价值，也是大多数人唯一关注的价值）和架构（软件的灵活性，具体下来可以理解为可扩展性、复杂性管理等，这部分价值常被人忽略，但确是软件可以持续低成本地产生行为价值的基础，也是软件之所以“软的原因”）。如果用艾森豪威尔矩阵来衡量，行为价值是紧急的，但并不总是特别重要，架构价值是重要的，但并不总是特别紧急。我们需要很好的平衡这两个价值
• 结构化编程限制了goto语句，赋予了我们创造可证伪程序单元的能力，相应的，在架构领域，功能性降解拆分是最佳实践之一；C支持完美的封装，部分支持继承（结构体超集），支持多态（函数指针模拟，getchar、putchar等函数），所以这三大特性并不能代表OOP，OOP的真正精髓在于对于程序间接控制权的转移，亦即安全的多态（比如Java将函数指针封装到jvm中，程序员不可直接用指针了），这种多态能方便地实现依赖反转（implemention源码依赖于interface，控制流和源码依赖相反），让底层组件插件化，独立于高层组件进行开发和部署（边界划分的艺术）；函数式编程中变量（叫参数更好）不可变，借鉴到架构中就是隔离不可变与可变的部分（我们目前做不到完全不可变性，要么速度太慢，要么空间太小，如果有足够的空间和速度，就可以实现只需CR而不是CRUD的程序）
• 软件构建的底层目标（也就是具体的代码逻辑，类比砖头）应遵循“整洁之道”；中层目标（也就是组件，类比房间）是软件可容忍改动、更易理解、组件可复用，应遵循SOLID原则（是设计类和模块适用的原则，在架构领域也适用）；高层目标（也就是软件系统。类比建筑）要遵循复用和发布等同（为复用而组合）、共同闭包（为维护性而组合）、共同复用（为避免不必要的发布而切分）三个原则，这三个原则互相牵制，架构师要在这三者中找到平衡；组件之间要避免循环依赖，打破循环依赖的方式有DIP、创建新组件两种方式，依赖要指向更稳定的方向
• 软件架构师首先是程序员，也许不是代码量最多的，但是应该亲自承接编程任务，不然体会不到不良设计带来的麻烦，逐渐就会迷失正确的设计方向；软件架构的最高优先级是系统正常工作，同时也要保留尽可能多的选项（这是让系统好理解、可扩展、易修改，为其将来正常工作打下基础），架构是要考虑软件系统的全周期，而非仅是当前；软件架构的目标是让系统的策略和细节分离，以允许具体决策过程中推迟与细节相关的内容，留下更多的选项
• 我们常说“Don't repeat yourself”，很有可能就陷入了见到重复就消灭的应激模式中，事实上，要区分真重复和假重复，如果两段代码走的是不同的演进路径，那么即使他们现在看起来比较像也要即时分开，不然后期的改动就会难以下手

我发现老外写书大致有两种风格，一种是大部头，经书似的。这种书看着人头疼，但是往往能把一个领域说的非常清楚和考究，属于科研派的，比如TCP/IP详解 卷1：协议这种；另一种是散文似的，每一部分都短小精悍，看着也不累，比如Head First 设计模式。这本书显然是后者，感觉学了不少，也不觉得累，究其原因我想是因为本书通篇就反复讲了一个概念：隔离变化（重要的事情说三遍？），所以看完还是感觉稍微有点水。

可伸缩架构

可伸缩架构：面向增长应用的高可用 (豆瓣): https://book.douban.com/subje...

高可用是我们做系统的人不变的追求，本书就是该领域的一部佳作，从可用性谈起，介绍了监控并提高可用性的方法，然后重点讲了风险管理和伸缩性，最后讲了最近几年流行的微服务和逐渐成为主流趋势的上云。看完之后就能对高可用这个概念有一个全面系统的了解。

亮点：

• 程序员一开始接触的是一个确定性的世界，什么样的输入就有什么样的输出，但是在面对分布式系统时首先要承认的就是不确定性，不能再把系统看做单体应用那样稳定，要充分考虑不确定状态（机器本身、代码质量、网络等因素所致），并把整个系统的不确定性因素梳理出来，作为风险进行管理，制定相应的措施，并持续地进行测试和评估，避免问题发生时手足无措
• 提高可用性的5个要点：时刻考虑应对故障（everything can fail at anytime，所以要为故障做出计划）；时刻考虑应对伸缩（具备快速扩展数据库、应用等的能力）；缓和风险（风险不能完全消除，但是应该做出缓和风险亦即降低问题带来的影响的努力）；监控可用性（眼睛，问题定位）；以可预期及明确的方式来处理可用性问题（对监控出的问题进行标准化流程处理，降低不可用时间）
• 计划和日常维护导致的不可用时间也应计算在可用性百分比之中，因为用户只在乎可用与否，而不管你是意外故障还是计划维修
• 可用性下降时有几点可以做：首先要跟踪并测量可用性（包括关键事件如变更和可用性之间的关系）；手动流程自动化（人肉操作不靠谱，自动化操作则有预期、可审查、可重复、易版本控制和回滚）；关注一致性、可重复性、标准的配置管理流程
• 风险管理就是在消除风险的成本与风险发生的成本之间保持平衡，其第一步就是列出所有已知风险，包括可能性和危害性并依此分级（最严重的风险自然就是可能性大、危害性大的），制定风险缓和措施（降低可能性和危害性，危险性更要首先关注）来控制风险并定期检查和持续维护（比赛日，也就是容灾演练）。当风险仍然不可避免的发生后采用恢复计划（风险发生后采取的行动，也属于风险缓和措施，如容灾计划）降低问题的危害性
• 如何从根本上缓和风险呢？那就是从一开始就考虑构建低风险系统，要素有：冗余（合适的冗余可以降低整体故障概率，但是过度冗余带来了复杂性，反而增加了风险）、幂等接口（通过简单重试避免失败）、独立性（看似冗余的服务如果运行中同一个物理机或者机架上那就不独立了）、简单（微服务降低了单体复杂性，但是服务数量增多也带来了构建大规模系统的整体复杂性，所以构建微服务要在单个服务和整体应用之间的复杂性做权衡，这个权衡取决于你的系统、组织和公司文化）、自修复（人工修复会显著降低可用性，比如半夜你还得先起床，所以要自修复，比如负载均衡自动剔除坏server、热备数据库自动上线等）、自动化流程（人总是会犯错）
• 微服务主要解决的是单体程序臃肿难理解、无法多组人员并行开发、难以测试、发布缓慢等问题，且可以给更重要的业务单独增加更多资源，当然这个进步的前提是服务之间边界明确且独立（代码库、数据、API、Owner的权利和责任），否则既不能解决这些问题，反而由于组件数量增多而增加了系统的复杂性。服务边界划分的原则有：业务需求、团队所有权、天然隔离的数据、对外服务的能力
• AWS的可用区针对不同用户来说是不同的，主要是为了负载均衡，避免用户集中选择字母表中靠前字母的可用区，导致负载不均，同一个数据中心对甲是a可能对乙就是b，这个设计还是挺巧妙的

文中说可靠性很容易通过测试解决，所以主要讲了可用性，但是分布式数据一致性、持久化等也应属于可靠性，但是很难测试，所以书里的可靠性定义还是狭隘了一点，仅指传统软件测试方面的。而且我觉得广义上的可靠性应该是包含正确性和可用性两方面的，而广义上的可用性又包含能用和性能两方面（比如你的一个简单的服务虽然能用，但是RT是5分钟也可认为该服务是不可用的）。
另外后面关于云计算方面的内容稍有注水和广告之嫌，毕竟按固定量和使用量的方式分配资源这种话题太过浅显（虽然也属于伸缩性的范畴）。

软件架构师的12项修炼

软件架构师的12项修炼 (豆瓣): https://book.douban.com/subje...

架构师的技术能力属于硬技能，关系技能、个人技能和商务技能等属于软技能。在商业化的社会，硬技能的确非常重要，是我们生存的基础，但是软技能也同样重要，是我们扩大影响力和业务面的基础，能帮我们超脱技术本身，为公司创造利润，为社会创造价值。这本书就着重帮我们培养这些软技能，并且基本按照原则、策略等要点来组织，非常有条理。

亮点：

• 对于更高职位的人而言，深谙技术细节固然有用，但能力已经开始向与别人成功交互方向倾斜，为了将事情办成而倾销其观点，一个项目要成功，支付账单的人要获得最大回报其实并不一定需要完美的技术解决方案，所以遇上争执首先问自己：纠正重要吗？不纠正公司会付出很大成本吗？很大可能答案是不，此时最好就是保持平静而非面红耳赤，记住人不是软件（有问题就一定要立马解决），人有情绪，所以要时刻保持文雅
• 就像好的web服务一样，你应采用“无状态”的方式——只对当前输入做出响应（而不是很久之前别人对你冒犯），毕竟你的脑子是能处理几件事，不要将你的精力浪费在过时、无用的信息上，记住你学会的知识，放下不快的事情，你会成为一个真正进步、快乐的人
• 架构师通常不能直接管理别人，这样指示别人完成特定行动的能力就受到限制了，所以真正有效的手段就是你的影响力，一方面体现在你的专业知识上，另一方面就是沟通技能
• 出于本能，当别人说出对我们不是正面意义的话的时候我们往往会找借口、转移话题或者责怪别人，但事实上别人不一定出于恶意，先想想自己能从别人的话中得到改进吗？如果是，则是你成长的机会，所以要避免这种本能
• 我们常常会说“我早就告诉你会这样”，是下意识的想展示自己的优越感或者甩锅，但是这样对团队合作与项目进度毫无用处，所以要想成为一名好的team worker，我们要扔掉许多下意识的东西，并且尝试去了解肢体语言和心理学可以帮你更好的进行协商
• 管理是将事情做对，而领导力是做对的事。应该通过影响而不是要求别人来做一件事才是真正的领导力。领导力建立于信任之上，是为了建立一种共识，取决于建立战略伙伴关系和身体力行的能力。
• 透明化能为自己和他人带来清晰性，让公司充分评估风险。包括三大类：自我透明，向别人充分展示自己，不隐藏，让别人可信赖并对你有合理的期待；项目透明，展示项目的优缺点、风险、成本和假设条件，让别人也可以充分参与决策；关系透明，给别人信任，倾听，让别人对你也透明
• 激情是推动你事业进步的内在动力
• 商务就是为了赚钱，了解一些商务知识可以大大促进你了解伙伴（市场、销售）、领导和客户的能力，能帮你做出真正有商业价值的产品。
• 创新不会凭空而来，需要多阅读（书记、博客等），这样你才有知识储备，在你面临一个挑战性问题时，你才有原材料进行创新；平时有了点子都可以记录下来（好记性的确不如烂笔头，而且如今大家都很忙，很多想法不记录就溜走了），这就是将来灵感的种子

这本书还有个好处就是全书都在培养我们问自己问题的习惯，遇上一件事时先全方位多角度地问自己若干问题，然后再下手，这样才不会片面，不会走入“锤子与钉子”的桎梏，才能有更宽阔的眼界，走向创新的大门。
另外说一点和书没关系的话，我们工作中自己是锤子，不能看见啥都是钉子，这样容易走入死胡同。但是我们自己是锤子，看见啥都要想一想是不是钉子，这样才有可能发挥自己工作的最大价值。
最后，我觉得本书不只是架构师需要，而是各行各业的各类人都需要。

和秋叶一起学PPT

和秋叶一起学PPT (豆瓣): https://book.douban.com/subje...

如果说代码能力、架构能力等技能属于我们的硬实力，那么表达能力、沟通能力就是我们的软实力，只有软硬兼修才能立于不败之地。在如今的学习和工作中，少不了汇报、组会等，制作一个好的PPT能帮我们更好地表达、展现和沟通。通过本书可以学到PPT的制作技术，而且书本身就可以看做一个素材库，针对不同行业、场合，帮助你选择不同的风格和素材，适合长留案边，以备不时之需。

亮点：

• 感觉写书和写PPT有共性，作者一开始就把自己的书和其他书作对比，强调突出了自己的优势（比如同名微博+微信+书籍，打造学习闭环），一下子就把我震住了，可见PPT做得好不仅能会说，还能会写书，好处多多
• 从结果导向来说，还是要关注业务。office2003出来后，一众发烧友做了一大堆复杂动画模拟翻书切换效果，结果office2010直接一键实现，所以对于好多工具（比如开发语言、中间件）没必要耗费时间完全搞清楚它所有花里胡哨看起来高大上的特性，而是要关注业务的实现，在必要的时候再去了解特性（因为所谓特性其实很容易过时）
• serif（有衬线字体），在字的笔画开始、结束的地方有额外的装饰，且笔画的粗细有所不同；反之，sans serif 没有额外的装饰，且笔画的粗细差不多。投影状态下受设备影响，大字部分适合serif（透气、美观） ，小字部分适合sans serif（简洁、识别度高、有冲击力）；此外，不同字体的使用要注意法律风险
• 打造一个高大上的PPT其实也是有章可循的，一般四步走起：统一字体、突出标题、巧取颜色（通过沿用logo或企业VI用色对PPT进行简单配色）和快速搜图（用关键词搜图法对PPT进行配图）
• ......

这本书连真小白都可以看，所以老手们要跳着看啊，不然浪费很多时间（比如教你怎么下百度云，￣□￣｜｜）。

Kubernetes in Action

Kubernetes in Action中文版 (豆瓣): https://book.douban.com/subje...

xx in action 系列的书一直不错，既有原理性的解读，又有实战性的上手指导，阅读价值非常高。而k8s作为云原生的代表技术，非常值得学习。

亮点：

• Kubermetes 抽象了数据中心的硬件基础设施，使得对外暴露的只是一个巨大的资源地，可以被当作集群的一个操作系统 看待，它让我们在部署和运行组件时，不用关注底层的服务器，使开发者可以自主部署应用，完全脱离运维团队的帮助，同时能让运维团队监控整个系统，并且在硬件故障时重新调度应用，系统管理员的工作重心，从监管应用转移到了监管 Kubermetes，以及剩余的系统资源，因为 Kubermetes 会帮助监管所有的应用
• 作者不喜欢先解释事物是如何工作的，然后再解释它的功能并教人们如何使用它 。 就像学习开车，你不想知道引擎盖下是什么，你首先想要学习怎样从 A 点开到 B 点 。只有在你学会了如何做到这一点后，你才会对汽车如何使这成为可能产生兴趣。毕竟，知道引擎盖下面是什么，可能在有一天它抛锚后你被困在路边时，会帮助你让车再次移动
• 一个 pod 是一组紧密相关的容器，它们总是一起运行在同一个工作节点上，以及同一个 Linux 命名空间中。为什么发明了pod的概念呢？ 首先，容器被设计为每个容器只运行一个进程（除非进程本身产生子进程），如果在单个容器中运行多个不相关的进程，那么保持所有进程运行、管理它们的日志等将会是我们的责任，所以不能将多个进程聚集在一个单独的容器中，我们需要另一种更高级的结构来将容器绑定在一起，并将它们作为一个单元进行管理，这就是 pod 背后的根本原理
• 注解也是键值对，所以们本质上与标签非常相似，但注解并不是为了保存标识信息而存在的，一般用来保存更多的信息，而标签更像是索引。此外，向Kubemetes引入新特性时，通常也会使用注解，一般来说，新功能的alpha和beta版本不会向API对象引入任何新字段而是用注解，当API更改变得清晰并得到所有相关人员的认可，就会引入新的字段并废弃相关注解。
• 尽管工作节点上的组件都需要运行在同一个节点上，控制平面的组件可以被简单地分割在多台服务器上。为了保证高可用性，控制平面的每个组件可以有多个实例。etcd和API服务器的多个实例可以同时并行工作，但是调度器和控制器管理器在给定时间内只能有一个实例起作用，其他实例处于待命模式
• 控制器执行一个“调和”循环，将实际状态调整为期望状态（在资源spec部分定义），然后将新的实际状态写入资源的 status 部分。控制器监听API Server来订阅变更，但使用监听机制并不保证不漏掉事件，所以仍然要定期执行重列举操作来确保不会丢掉什么
• ......

Kubernetes网络权威指南

Kubernetes网络权威指南：基础、原理与实践 (豆瓣): https://book.douban.com/subje...

本书是要不要推荐我其实犹豫了一下，因为本书有许多代码，有充数之嫌，而且在阐述上有许多不清晰的地方。但是我还是推荐给大家，因为本书勾勒了一个基本上完整的k8s网络大图，值得通盘了解。

亮点：

• 结合CNM，Libnetwork要达成的效果是，用户可以创建多个网络，也可以创建多个容器，最后选择让容器加入某个网络，从而使容器和网络分离，让开发者专注于自己感兴趣的地方
• 要支持大规模的容器集群，网络才是最基础的一环，其中的挑战是“以隔离的方式部署容器，在提供隔离自己容器内数据所需功能的同时，保持有效的连接”，隔离和连接是两个矛盾但是又缺一不可的关键词
• Overlay是指在传统底层网络上构建一个虚拟网络，底层网络不需做任何适配，虚拟网络在底层网络上进行封包拆包完成通信，L2 overlay是一个大二层的概念，大是指这个网络可以跨越数据中心，二层是指通信双方在一个逻辑网段内，支持容器迁移而不用改变Ip的特性，L3 overlay类似，但是在节点上增加网关（不同节点网段可以不同），节点内通信走L2,节点间走L3；Underlay是指底层网络，传统组网就是underlay类型，L2 underlay就是2层互通的网络，L3 underlay就是L3互通的网络
• Docker在容器的普及和迅速推广起到了非常重要的作用，但是它也正在集成网络、编排等功能，势必会被k8s弱化其作用，而拥抱更轻量的容器技术比如containerd、cri-o等
• k8s网络策略和一些安全组在某些功能上有重叠，但是区别也较为明显，安全组一般记录在上层网关，网络策略则实施在每个节点上，节点上的agent需要watch pod、namespace、policy等资源
• Linux内核在做SNAT时，由于端口分配和将连接插入contrack表存在时延，可能导致端口冲突而丢包（尤其是高并发模式下），所以不推荐在生产环境使用nodePort模式
• 受制于k8s的基于客户端的负载均衡架构（由每个节点的kube-proxy决定real server），即使用了支持多种负载均衡算法的ipvs也很难支持，比如least-connection算法，每个kube-proxy只能知道自己链接数最小的rs，而不能知道全局最小的rs
• Flannel 通过监视etcd获取可用ip范围，在启动容器时指定ip范围，从而使得不同节点成为一个子网，容器ip不重复；通过overlay（用户态udp或内核态的vxlan）或者host-gateway（直接刷节点路由表，由于不能刷路由器所以需要节点2层可达）的方式实现容器间通信。Calico 也是通过类似的刷节点（虚拟路由器）路由表来实现容器通信，但是由于采用了BGP协议，其模拟的路由表信息可以被传递到其它路由设备中，直接实现了3层网络通信
• BPF 可以理解为一个高性能沙箱，使得内核变成可编程，内核有其加持后，linux的安全则不局限于传统的ip+port的包过滤模式，内核可以理解什么是微服务、安全性如何等问题。Cilium就把BPF带入了K8S

大型系统应用架构实战

大型系统应用架构实战：部署、容灾、性能优化 (豆瓣): https://book.douban.com/subje...

本书作为阿里全球化的经验沉淀之作，不仅介绍了宏观的架构策略，还探讨了具体的算法实现，非常值得急速扩张的互联网公司借鉴。
此外，本书展现出来的知识面也告诉我们，要想作一个优秀的架构师，既要了解业务，也要了解技术，这样才能做出最适合业务的技术方案

亮点：

• 互联网的本质是提高信息传递的效率，它极大地促进了全球化，而全球化对技术有如下几个要求：性能、可用性、互联互通、数据一致性、隐私保护、本地化对接、可伸缩性
• 区域化部署技术的本质是多层路由，每一层都要基于用户来调用路由服务，确定该用户所属的机房。而多层路由的最佳方式是接入层RPC调用路由服务后缓存起来（有一定的失效期）并透传给下面的服务层、消息层和数据层。有人可能会问了，都在接入层判断了，为啥后面每一层都要再判断一次？因为有可能路由服务变更了，还有可能一份数据被多个用户共享，所以每一层都要做路由决策
• 区域化容灾技术，在进行灾备切换时并不需要更新整个机房的用户路由表，也不会因为完全依赖DNS切换而必须等待DNS失效，因为区域化部署已经提前在路由服务中准备好了灾备机房，所以在统一接入层即可完成灾备切换，即使统一接入挂了，也只是会影响部分用户而不会带来危害
• ......

后记

有时候会觉得“知道了许多道理，却依然过不好这一生”，看了许多书，却觉得自己依然没有进步。我觉得主要有两点，一是看书要带着思考去看，不要用眼睛过一遍就完事了，要对书中的内容多想想：书里说的对不对？如果是对的我有没有做到？书对我的学习和工作有实际价值吗？等等，多问几个问题书里的内容就能自然而然转化为自己的知识，平常和别人交流就能用上了。二是要及时地把书中的知识运用起来，并有意识的对自己进行相应的训练，比如对于很内向的人，看了《架构师修炼这本书》后就可以好好实践一下透明化这一章节，多展示自己，让别人了解并信任你，这就是你的进步。

查看原文，来自MageekChiu。