结构化思维：构建自己的知识树

　　知识树要解决的问题，我们看一些场景：

　　1为什么我知道很多东西，但是当场景来的时候老是会记不起来使用；

　　2完成一个方案你只能想到一些点状的手段，还有其他方案被漏掉了；

　　3讲一件事情的时候逻辑非常混乱，前后没有逻辑性关联。

　　但是很有可能你的知识都是知道的，为什么会出现这种悲剧？

这个就跟大脑中的知识结构有关，这是知识学习中“索引”没有建立，也就是说，你的知识只有点，没有线！大家想一想，把东西乱七八糟地丢在房间中，到用的时候没有查找的线索和路径，怎么找得到呢？

　　来看一下我们工作场景的结构化的典型案例，大家体会一下：

　　项目中测试MM提了一个bug，我总结出来的比较标准的问题定位步骤：

　　1确认刚才是否有过代码变更和部署，因为有比较高的概率是刚才变更的代码又搞坏了……

　　2追踪链路日志看链路是否有异常；

　　3通过RPC的控制台调用看接口输入输出是否符合预期；

　　4追踪关键方法的入参和出参，看是否有问题；

　　5定位到方法细节后，推理逻辑是否有问题；

6如果无法通过推理，那就最后一招，回放异常流量debug，这样肯定能够找到原因。

　　某个链路耗时比较长，需要进行性能优化，我的分析步骤是：

　　1通过实际流量制造一个耗时较高的trace；

　　2进行trace分析，看清楚耗时最多的原因，然后按优先级进行排序；

　　3针对对原因找解决方案，可能的方案有： a) 减少数据访问次数或者计算量，常见手段是增加cache：线程内的invokeCache；分布式缓存tair；页面缓存…… b) 增强处理速度，比如多线程加速； c) 减少循环调用次数，比如请求合并后再分发； d) 减少数据处理范围，比如减少查询内容，异步加载分页； e) 逻辑简化，比如逻辑进行优化，或者非核心逻辑异步化等； ……

　　4.改掉以后，回放同样的case，看性能消耗是否满足预期，不满足预期继续优化；

　　如何熟悉一个新系统，我的步骤是：

　　1要一个测试账号，把相关功能走一遍，这样能非常快地了解一个系统的功能；

　　2看关键的核心表结构，这样可以快速了解系统的领域模型；

　　3根据功能步骤找到系统对外的接口列表，了解系统的L0业务流程；

　　4下载系统工程，熟悉整个工程结构和模块职责；

　　5以一个最重要的流程为入手点，阅读代码，看清楚核心的执行逻辑，可以变看边画时序图；

　　6制造一个debug场景，以debug方式走一遍流程，这样可以实际加深一下对系统的理解；

7做一个小需求，掌握相关的流程和权限；

　　下单这里来了一个新的需求，出一个技术方案的步骤：

　　1看清楚之前的需求，把这个需求所在的场景和链路大致阅读一遍，搞懂；

　　2找到需求的变化点；

　　3分析变更的方案，涉及的内容可能会有：

　　4数据结构会不会变，如何变；

　　5交互协议会不会变，如何变，交互协议分为：端和组件要不要变；和下游接口要不要变；

　　6执行逻辑会不会变，如何变，执行逻辑变更的细化考虑点：是否变更域服务；是否变更流程编排；是否变更主干逻辑；是否变更扩展点是否变更扩展点的内部逻辑，变更内部逻辑的时候，又可以进一步拆解： a. 重构原有的方法，覆盖之前的逻辑，那就需要进行回归； b. 通过逻辑路由到新的方法，这里需要增加路由逻辑；

　　7稳定性方案；

8发布方案；

　　可以看到，面对任何一个场景，不管多大多小，我们所需要掌握的知识或者技能都可以构建成一个树结构，同类之间是顺序关系，上下之间是父子关系（或者粗细颗粒度）。

当这个树在大脑中构建起来以后，你会发现你做什么事情都是有一个明确的分析和执行逻辑，不太可能产生遗漏和混乱！

　　那么如何训练出自己的知识树呢？我给一些比较有效的实践方案：

　　1一定要总结出自己的知识树，而不要盲从书本上的或者别人的，为什么呢？一是因为人的思维速度和习惯、技能有一定差异，不一定每个人都是一样的；二是如果没有内化别人的知识成为自己的知识，这棵树不太能够很熟练地运用；

　　2习惯性总结，做完任何一个事情，都习惯性地回顾一下，往自己的树上面挂新东西，这个是构建知识树的必备手段，这个总结不需要花很多时间，比如做完事情后花个几分钟回顾一下就可以，但是需要坚持；

　　3推荐一个很常见的工具：xmind，把自己的树记录下来；

4训练自己的思维习惯和做事方式变得结构化，当你做事情的时候，习惯性用树的方式推进，强迫自己按照这个方式来。