这个有点学习的方法论的意思，画个滋味导图顺便整理一下。
遇到问题的时候，解决的方法大致有3中，而针对学习的建议有一部分是值得考虑学习的。
方法一：查看FAQ以及其他相关文档
这方面我自己一直以来的学习中做的不算好，我遇到过很多FAQ文件，但是我似乎基本都没有翻看过。至于其它文档倒是翻看过，看得也算是比较少。学习Linux可以充分利用本身自己就存在的文档数据库，再一个就是查看网络上的相关文档。
方法二：注意信息输出
好歹写了一阵子代码，这方面还是有这么一点习惯性的技能。对于软件的反馈提示信息以及屏显信息捕捉我自己做的还不错，不过说到对所有的记录文件进行深刻剖析这样的做法我做的还是少一些。
方法三：借助于网络的力量
现在的技术论坛是个好地方，实在是找不到答案这就是一个很好的学习咨询场地。我问的偏少，不过在初级问题的解答上倒是也多多少少贡献过自己的一点力量。当然，从别人的问题与回答中，我学到了更多。
如果选择这种方式，提问之前问题信息整理以及提供必需得做好准备。别人看问题看得一头雾水的时候肯定是不好给做出很好的解答的。
至于过来人的经验：
1，哪怕是使用Windows，遇到软件问题的时候也尽量不要进行系统重启。必需关掉某个软件的时候，尝试使用资源管理器杀死进程。
这方面我自己的经历以及经验不算多，但是做得还不坏。比起公司的IT运维工程师的“重启”来说，我还是自主性解决了不少问题。
2，设计文件目录，不要随意保存文件
从去年开始，一直在加强我自己这方面的修养。电脑的文件管理其实也是一门学问，这方面真得想图书馆的管理节俭点经验。
3，遇到好的资料拷贝保存
做的也还不坏，只是积累了大量的资料到现在还没有怎么翻看。
4，用户：迁就机器
作为一个软件用户，不必要更多去解决一个普遍性的问题。而是看看怎样在自己所用的电脑上操作软件能够避过问题解决自己的困扰。不然，用户跟软件工程师的角色就重叠了，自己的注意力也被过多的牵制。这是我对这句话的理解，不知道是否理解到位。
5，开发者：机器迁就人
跟第4点有点类似，作为开发者应该考虑的是做出一个普遍适用的程序。因此，机器环境来看的话应该是尽量得满足开发者的要求。
关于4、5，这是我自己的一点理解，书中没有明确的说明。当然，这两点很可能是针对机器的性能来说的，那就该另外理解了。
6，学会借用别人的成果并且进行适合自己使用的修改
书中这部分是针对脚本的编写来说的，过去这么多年其实这样的事儿我没少干。不过，我觉得即使是跳出这个层面这句话说得也是有道理的。除非你想成就一场突破性的个革新，否则尽量还是不要去造车轮。毕竟，站在别人的肩膀上会看得更远，借助于别人的力量走得更稳。
