這篇文章是一篇方法論，並且肯定也已經有許多人對此做過總結與分享。然而我寫這篇文章的目的不主要在於分享，因為有些東西分享了別人也大都只是匆匆一瞥，也許僅能做到給別人一些啟發。寫這篇文章還是想理清自己的思路，希望自己能在一些事情上得到收穫。

這些總結目前我還沒有完全實踐過，只不過今天突然靈感來了，覺得有必要記錄一下。接下來一段時間我會用這個辦法實踐一下，結束了之後再寫一下反饋。

在做總結之前，我先講一下我最近的工作，也是和工具相關。

近期正在做一份更新公司開發的一個工具的使用者手冊的工作，過程中心情也跌宕起伏，雖然有過振奮的時候，但更多的是焦慮，煩惱。尤其是我對這個工具的熟悉程度僅限於能夠使用它來做完一個流程。在最近開始更新文件之前，我也僅僅是接受過幾次培訓，對這個工具有個大概的瞭解。不過所幸我也只是來更新文件，需要我自己重新撰寫的部分很少。我需要做的工作就是把以前別人寫的文件整理綜合寫到一個文件裡。在這一過程裡，每一篇文件我都至少要看一遍，而且是英文，然後再把之前的部分更新到新文件的結構框架裡。而且只有反覆的看，才能做到心裡有數。有時候如果隔幾天不去看文件，再返回來寫文件的時候，就會感覺已經忘了。

下面說說我覺得寫文件有個很重要的部分，就是搭框架，我想這和寫程式碼有異曲同工之處。我更新的這個文件的大框架是我主管給我寫好的，其中還有一些細節的部分我需要自己考慮。一個框架搭好了，就對自己要寫的東西有了大致的瞭解，然後就可以排計劃，一步一步完成了。當然在寫的過程中也許會有小的改動，但也無妨。

那麼寫文章和學習工具又有什麼關係呢？碰巧在我寫文件這段期間，我又要去學習Robot Framework + Cucumber。經過領導對我們的悉心指導，我也在思考，到底學習一個東西，應該怎麼入手，怎麼安排，怎麼保證質量呢？

這又讓我聯絡到我前幾天看的一篇文章裡說的，人應該學會提問題，這比解決問題還重要。而我覺得，在學習任何一個東西之前，多提一些問題總是好的。可能一開始你提的問題毫無規律可言，也缺乏針對性，並且每個基礎不同的人提的問題深入度是不同的，可是努力總會讓人進步的，不是嗎？拿我這次學習測試框架Robot framework來說，我會提出以下問題：

1. 它是用來測什麼的？
2. 它的測試用例長什麼樣子？
3. 我應該怎麼寫測試用例，它的語法是什麼？
4. 它可以與什麼語言結合？
5. 它常用的庫是什麼？
6. 它怎麼安裝，啟動？
7. 它怎麼跑用例？
8. 它可以生成測試報告嗎，長什麼樣子？
9. ......

像這樣提出一些問題，然後再去有針對性的學習，肯定要比什麼都不問，只遵循腦海裡一些潛在的想法去學習要好。有計劃總是好的，在講究效率的時候。

但是如果只單單通過解決這些問題去學習，我覺得還是有所欠缺的。首先，這些問題雜亂無章，像打游擊，東打一下西打一下，那麼學習起來效率應該不是很好。所以現在要解決的問題是，怎麼把這些問題按照一定的邏輯組合起來，讓它顯得循序漸進又面面俱到呢？

我想，這裡可以借鑑一下寫文件的思路。你想怎麼學習一個東西，就先想如果你已經瞭解這個東西，那麼你會怎麼下筆去寫它。這句話也許看起來挺扯的，但是我覺得這樣想有一個好處，就是把握整體。當然，去想怎麼寫是說要去想文章的結構，而非具體內容。而且這樣一來，時間長了，就可以總結出一些模式，以後學習的時候思路就有了。所以我們可以在想文章結構的同時提出相應的問題，那麼問題的結構也就有了。那麼現在問題來了，文章的結構要怎麼想呢？這個問題確實挺難，我覺得需要時間去總結與積累。但是萬物皆有其法則，雖然每一篇文件都各不相同，但是我相信，從它們的骨骼上我們總可以把它們分門別類。關於具體怎麼做，我也沒有答案。

就我目前的經驗來看，我可以將一個介紹工具類的文章這樣解構：

1. 概述：是什麼，為什麼
2. 特性：優點，缺點
3. 安裝執行環境
4. 架構
5. 組成
6. 工作流程
7. 例子

在提出問題之後我覺得還有一點需要考慮的是，解決問題的順序。目前我的想法就只是針對那些流程性很強的東西，先做一個小的例子出來，然後再去學習其他的東西。學習不同的東西，肯定切入點會不同，但如果找好了切入點，之後從這個切入點散發出來的東西，吸收起來肯定快一些。

以上皆是我的經驗，想法以及想象，不構成事實。

其實我之前學習的規律一般是先去網路上搜索一些相關的文章來看，然後再去官網上檢視使用者手冊，然後按著使用者手冊一點一點看，這樣其實如果肯花時間與精力，收穫肯定是有的，但是效率不一定高。不過我覺得在考慮文章結構的時候，參考官方文件是一個很好的幫助。

最後，實踐是檢驗真理的唯一標準。

GOOD LUCK TO EVERYBODY

THANKS