知识树要解决的问题
1. 为什么我知道很多东西，但是当场景来的时候老是会记不起来使用
2. 完成一个方案你只能想到一些点状的手段，还有其他方案被漏掉了；
3. 讲一件事情的时候逻辑非常混乱，前后没有逻辑性关联。
读懂大脑原理
但是很有可能你的知识都是知道的，为什么会出现这种悲剧？
这个就跟大脑中的知识结构有关，这是知识学习中“索引”没有建立，也就是说，你的知识只有点，没有线！
大家想一想，把东西乱七八糟地丢在房间中，到用的时候没有查找的线索和路径，怎么找得到呢？
工作场景的结构化的典型案例<br>
项目中测试MM提了一个bug，我总结出来的比较标准的问题定位步骤：
1. 确认刚才是否有过代码变更和部署，因为有比较高的概率是刚才变更的代码又搞坏了……
2. 追踪链路日志看链路是否有异常；
3. 通过RPC的控制台调用看接口输入输出是否符合预期；
4. 追踪关键方法的入参和出参，看是否有问题；
5. 定位到方法细节后，推理逻辑是否有问题；
6. 如果无法通过推理，那就最后一招，回放异常流量debug，这样肯定能够找到原因
某个链路耗时比较长，需要进行性能优化，我的分析步骤是：
1. 通过实际流量制造一个耗时较高的trace；<br>
2. 进行trace分析，看清楚耗时最多的原因，然后按优先级进行排序；
3. 针对对原因找解决方案，可能的方案有：
i. 减少数据访问次数或者计算量，常见手段是增加cache：线程内的invokeCache；分布式缓存tair；页面缓存……<br>ii. 增强处理速度，比如多线程加速；<br>iii. 减少循环调用次数，比如请求合并后再分发；<br>iv. 减少数据处理范围，比如减少查询内容，异步加载分页；<br>v. 逻辑简化，比如逻辑进行优化，或者非核心逻辑异步化等；<br>vi. ……
4. 改掉以后，回放同样的case，看性能消耗是否满足预期，不满足预期继续优化；<br>
如何熟悉一个新系统，我的步骤是：
1. 要一个测试账号，把相关功能走一遍，这样能非常快地了解一个系统的功能；
2. 看关键的核心表结构，这样可以快速了解系统的领域模型；<br>
3. 根据功能步骤找到系统对外的接口列表，了解系统的L0业务流程；
4. 下载系统工程，熟悉整个工程结构和模块职责；
5. 以一个最重要的流程为入手点，阅读代码，看清楚核心的执行逻辑，可以变看边画时序图；
6. 制造一个debug场景，以debug方式走一遍流程，这样可以实际加深一下对系统的理解；
7. 做一个小需求，掌握相关的流程和权限；
下单这里来了一个新的需求，出一个技术方案的步骤：<br>
1. 看清楚之前的需求，把这个需求所在的场景和链路大致阅读一遍，搞懂；
2. 找到需求的变化点；
3. 分析变更的方案，涉及的内容可能会有：
i. 数据结构会不会变，如何变；<br>ii. 交互协议会不会变，如何变，交互协议分为：端和组件要不要变；和下游接口要不要变；<br>iii. 执行逻辑会不会变，如何变，执行逻辑变更的细化考虑点：
是否变更域服务；
是否变更流程编排；
是否变更主干逻辑；
是否变更扩展点是否变更扩展点的内部逻辑
a.重构原有的方法，覆盖之前的逻辑，那就需要进行回归；<br>b.通过逻辑路由到新的方法，这里需要增加路由逻辑；
4. 稳定性方案
5. 发布方案
可以看到，面对任何一个场景，不管多大多小，我们所需要掌握的知识或者技能都可以构建成一个树结构，同类之间是顺序关系，上下之间是父子关系（或者粗细颗粒度）。当这个树在大脑中构建起来以后，你会发现你做什么事情都是有一个明确的分析和执行逻辑，不太可能产生遗漏和混乱！
那么如何训练出自己的知识树呢
1. 一定要总结出自己的知识树，而不要盲从书本上的或者别人的，
一是因为人的思维速度和习惯、技能有一定差异，不一定每个人都是一样的；
二是如果没有内化别人的知识成为自己的知识，这棵树不太能够很熟练地运用；
2. 习惯性总结<br>
做完任何一个事情，都习惯性地回顾一下，往自己的树上面挂新东西，这个是构建知识树的必备手段
这个总结不需要花很多时间，比如做完事情后花个几分钟回顾一下就可以，但是需要坚持；
<b><font color="#b71c1c">3、使用思维导图工具</font></b><br>
4. 训练自己的思维习惯和做事方式变得结构化
当你做事情的时候，习惯性用树的方式推进，强迫自己按照这个方式来。
