原文：https://mp.weixin.qq.com/s/qRjn_4xZdmuUPQFoWMBQ4Q
学以致用
文中提到：
- 设计模式的底层逻辑是：“找到变化，封装变化”。设计模式的基石是面向对象。
- 学习设计模式的目的不是画出各种设计模式的类图，而是要学习它的思维：找到变化，封装变化。
- 设计模式还是要应用到实际的业务中才能发挥它的价值
短短几句话，却句句珠玑。
再延展来讲，学习的目的在于学以致用而不在于理论本身，此外我们学习一些技术时更重要的是学习其核心的原理而不是形式。
就像我们不能盲目的追逐技术本身，而是要用技术来解决问题，从而创造价值。
想做到学以致用，我们要完成思维的转变，克服原有以记忆或者热衷技术本身的惯性思维和学习方式，学技术时了解场景，熟悉优缺点，懂得某些技术的核心原理，甚至抽象出最本质的目的。
归纳和演绎法
文中提到归纳法和演绎法，这一点深有感触。
我们看到的很多文章更多地是在传递信息，而只有经过抽象和归纳过的精华才叫知识。
之前就对性能优化这一块通过归纳法进行学习，得到一些自己的思考。
如：
- 性能优化是为了：解决追求良好的用户体验和有限资源之间的矛盾。
- 性能优化的核心思路： 开源和节流外加限制，即使用更多的资源，减少不必要的浪费，此外加一些限制条件
性能优化常见的一些方法：同步转异步、串行转并行、空间换时间(缓存、预热等)、压缩、对象池模式、减少上下文切换、减少IO操作、降低冲突的范围、随机读写转顺序读写、选择适合的数据结构、产品层面加限制等都符合上述核心思路。
演绎法也非常重要，我们学习知识不在于死记硬背，而在于学以致用，所谓的学以致用更多地讲内化和知识的迁移运用能力。
如我们归纳了性能优化的一些思路，再反向再去理解 MySQL、HBase 中一些性能优化的设计背后的原因就会容易很多，平时做技术方案如果考虑性能优化的话也更容易信手拈来。
知其所以然
之前也读了很多书，总是读完就忘，或者单纯问能够答出来，但是实际工作生活中却理论和实践的脱节，无法灵活运用。
现在读书思路有些转变，主要去思考为什么这么设计，这么设计带来什么好处等，能能够从书中得到自己认为最核心的思想，等开发中遇到类似的场景就更容易提取和使用。
跳出惯性思维，以终为始
文中提到的一种现象自己深有感触：“平时我们在做业务需求开发时，要有这种识别变化的意识，先不要陷入面向过程的思维中，不要一上来就考虑如何去实现，而是思考它是什么，会有哪些变化”。
想到工作中之前一个 TL 讲到：我发现很多人就是需求翻译机器，拿到项目之后就去设计表，而不是思考价值、目的，不去思考领域。
越来越多的人记住了解决办法，却忽略了做某些事情的目的，某些技术的本质。
而且工作过程中越来越发现，越是优秀的老员工，越是有很好的抽象能力，全局视野；越是职级高的同事，越能够从全局去思考和看问题。
抓住问题的核心，以终为始，从更抽象和全局的视角看待问题，才能容易真正掌握住变化。
简一律
文中提到店铺类目设计的案例，不同方案的权衡依据总结的非常好：能简单就不要搞复杂，用简单的技术方案实现就不要用复杂的技术方案。
同时衡量一个人是否真正理解一个知识点的标准也是能否用通俗易懂的语言表达出来。
这也就是所谓的“大道至简”。
面向未来编程
工作编码过程中，我们通常会面向失败编程，考虑参数合法性，考虑各种异常场景。
在这里还要提到面向未来编程，所谓的面向未来编程是指针对未来可能的变化事先做出一些准备。
所谓的发现变化，封装变化，某种程度上来说就是面向未来编程。
如果未来一定不会发生变化，那么费劲地去发现变化，去封装变化为了啥呢？
因此封装变化就是为了在我们预测到的变化地方发生了变化时，能够减少工作量，降低复杂度等。
和“人无远虑必有近忧”、“未雨绸缪” 讲得道理都是一致的。
读经典
文中关键的依据都引用自一些经典的图书或者软件领域的理论。（这本身就是对这篇文章作为一个案例的抽象）
比如设计模式一书中提到“找到变化，封装变化”。
我们要做的是学习作者学习的模式。
比如我们读“任何计算机科学领域的问题都可以通过增加一个间接的中间层来解决”。
那么我们再看各种缓存机制，两阶段提交、分布式协调组件、分库分表中间件、消息队列、领域驱动设计等这些看似完全不想干的概念却有着莫名的内在联系，他们其实都是通过增加中间层来解决各种问题。
如通过增加缓存，解决对读的速度要求；通过消息队列实现削峰、解耦；通过增加协调者，实现分布式事务；通过添加领域层隔离变化实现更好的内聚性；通过新增代理层，解决分库分表的复杂度。
通过这种方式我们可以从更抽象的层次来看到不同技术之间的联系，更容易理解和认同一些经典理论的说法。
