这篇文章是一篇方法论，并且肯定也已经有许多人对此做过总结与分享。然而我写这篇文章的目的不主要在于分享，因为有些东西分享了别人也大都只是匆匆一瞥，也许仅能做到给别人一些启发。写这篇文章还是想理清自己的思路，希望自己能在一些事情上得到收获。
这些总结目前我还没有完全实践过，只不过今天突然灵感来了，觉得有必要记录一下。接下来一段时间我会用这个办法实践一下，结束了之后再写一下反馈。
在做总结之前，我先讲一下我最近的工作，也是和工具相关。
近期正在做一份更新公司开发的一个工具的用户手册的工作，过程中心情也跌宕起伏，虽然有过振奋的时候，但更多的是焦虑，烦恼。尤其是我对这个工具的熟悉程度仅限于能够使用它来做完一个流程。在最近开始更新文档之前，我也仅仅是接受过几次培训，对这个工具有个大概的了解。不过所幸我也只是来更新文档，需要我自己重新撰写的部分很少。我需要做的工作就是把以前别人写的文档整理综合写到一个文档里。在这一过程里，每一篇文档我都至少要看一遍，而且是英文，然后再把之前的部分更新到新文档的结构框架里。而且只有反复的看，才能做到心里有数。有时候如果隔几天不去看文档，再返回来写文档的时候，就会感觉已经忘了。
下面说说我觉得写文档有个很重要的部分，就是搭框架，我想这和写代码有异曲同工之处。我更新的这个文档的大框架是我主管给我写好的，其中还有一些细节的部分我需要自己考虑。一个框架搭好了，就对自己要写的东西有了大致的了解，然后就可以排计划，一步一步完成了。当然在写的过程中也许会有小的改动，但也无妨。
那么写文章和学习工具又有什么关系呢？碰巧在我写文档这段期间，我又要去学习Robot Framework + Cucumber。经过领导对我们的悉心指导，我也在思考，到底学习一个东西，应该怎么入手，怎么安排，怎么保证质量呢？
这又让我联系到我前几天看的一篇文章里说的，人应该学会提问题，这比解决问题还重要。而我觉得，在学习任何一个东西之前，多提一些问题总是好的。可能一开始你提的问题毫无规律可言，也缺乏针对性，并且每个基础不同的人提的问题深入度是不同的，可是努力总会让人进步的，不是吗？拿我这次学习测试框架Robot framework来说，我会提出以下问题：
- 它是用来测什么的？
- 它的测试用例长什么样子？
- 我应该怎么写测试用例，它的语法是什么？
- 它可以与什么语言结合？
- 它常用的库是什么？
- 它怎么安装，启动？
- 它怎么跑用例？
- 它可以生成测试报告吗，长什么样子？
- ......
像这样提出一些问题，然后再去有针对性的学习，肯定要比什么都不问，只遵循脑海里一些潜在的想法去学习要好。有计划总是好的，在讲究效率的时候。
但是如果只单单通过解决这些问题去学习，我觉得还是有所欠缺的。首先，这些问题杂乱无章，像打游击，东打一下西打一下，那么学习起来效率应该不是很好。所以现在要解决的问题是，怎么把这些问题按照一定的逻辑组合起来，让它显得循序渐进又面面俱到呢？
我想，这里可以借鉴一下写文档的思路。你想怎么学习一个东西，就先想如果你已经了解这个东西，那么你会怎么下笔去写它。这句话也许看起来挺扯的，但是我觉得这样想有一个好处，就是把握整体。当然，去想怎么写是说要去想文章的结构，而非具体内容。而且这样一来，时间长了，就可以总结出一些模式，以后学习的时候思路就有了。所以我们可以在想文章结构的同时提出相应的问题，那么问题的结构也就有了。那么现在问题来了，文章的结构要怎么想呢？这个问题确实挺难，我觉得需要时间去总结与积累。但是万物皆有其法则，虽然每一篇文档都各不相同，但是我相信，从它们的骨骼上我们总可以把它们分门别类。关于具体怎么做，我也没有答案。
就我目前的经验来看，我可以将一个介绍工具类的文章这样解构：
- 概述：是什么，为什么
- 特性：优点，缺点
- 安装运行环境
- 架构
- 组成
- 工作流程
- 例子
在提出问题之后我觉得还有一点需要考虑的是，解决问题的顺序。目前我的想法就只是针对那些流程性很强的东西，先做一个小的例子出来，然后再去学习其他的东西。学习不同的东西，肯定切入点会不同，但如果找好了切入点，之后从这个切入点散发出来的东西，吸收起来肯定快一些。
以上皆是我的经验，想法以及想象，不构成事实。
其实我之前学习的规律一般是先去网络上搜索一些相关的文章来看，然后再去官网上查看用户手册，然后按着用户手册一点一点看，这样其实如果肯花时间与精力，收获肯定是有的，但是效率不一定高。不过我觉得在考虑文章结构的时候，参考官方文档是一个很好的帮助。
最后，实践是检验真理的唯一标准。
GOOD LUCK TO EVERYBODY
THANKS