在早期刚入行IT行业时，常常会遇到要接手别人项目，或者是要去查看底层源代码的情况。当时常常是 一不做，二不想，闷着头皮就往下闯，结果往往是弄得自己头昏眼花，源代码还是没看懂。
后来因为对自己在这方面有所不满，所以决定改变自己，反思自己的方法的问题出在哪里。实际上，仔细想来，每一位作者在写代码的时候，首先想到的就是业务流程应该是怎么展开的，然后在业务流程的基础上设计软件的结构图，也就是各个组件之间的关系图，然后深入下去，就是在各个组件中，设计对应的类，对应的接口，函数等待。
结果当时的自己，或许是完全没有后来这样的想法吧，竟然啥都不管就直接钻进去。倘若自己一开始通过其他渠道，查资料，或者请教 弄明白业务流程功能，然后能看到整个软件的设计结构图，接下来找到对应组建中的类关系图，这样看源代码不就很happy了吗。
这种从整体到局部的方式不得不说，的确很高效，而且竟然和自己的学习方式竟然有异曲同工的效果。
早期自己因为不是计算机专业，自学的andorid应用层开发时做的最多的就是从网上下载视频教程看，当时追求的仅仅只是把需要的功能实现就行了，也不管使用的方法是否是最合适的，也不管效率的高低。这种一开始就钻到细节的学习方法，使得我在后来的很长一段时间内，知识体系总是一鳞半爪 ，参差不齐。自己对过去所取得的进步越来越不满，力图寻求改变。
后来同样也是开始反思自己过去的学习方向是否存在问题，过去常常是，公司需要用到新的技术，完成新的功能，自己才去学一下，这种学习不过是在扩展枝干上的一片树叶罢了。
随即下定决心，辞职，这一次从整体往细节上进行扩展，把大学时落下的补回来。以 计算机操作系统，高等数学，离散数学，编译原理，数据结构，关系型数据库原理，计算机网络原理等等为主干，以前端，后台，移动端，算法，驱动开发等为枝干，以各种框架，基础API调用为枝干上的树叶，来构建自己的整个计算机领域的知识体系。
虽然完善这样的一棵知识树需要较长的时间，但我可以一边完善主干，一边利用工作的机会，尽可能的完善枝干。待主干长成后，自己倘若想换个枝干，有主干作为支撑，想换过去也不会很难。况且，仅仅是不断的完善这棵知识树，也可以指引着我往架构师的方向前进。
最后说一句，希望有更多的人能看到这篇文章，让后来者尽量避免掉入我曾经趟过的坑。
