加入新員工訓練營的有開發(fā)也有測試，大家的coding水平參差不齊。

我發(fā)現(xiàn)一個問題，就是當面對一個新學的語言時，我們這期訓練營里除了我以外所有的測試人員甚至一些開發(fā)人員都不會讀代碼，不知道怎么去讀，或者雖然讀了，卻一知半解，毫無效率。

?

首先分享一下我讀代碼的方法供從手工測試轉自動化測試的同學們參考（可能各人思維模式不同，僅供參考）：

我讀代碼時的思維方式屬于一級一級嚴密的邏輯思維，所以一旦我的邏輯鏈中間斷掉，我就不能理解這些代碼。

?

一句話總結：先跑起來，再調試，理解原理，掌握細節(jié)。

?

第一步，看有沒有文檔。遺憾的是通常要么么有，要么不全。但通常我們能找到一些參考資料，可能來自某些文檔也可能來自某些人。

在開始之前先收集所有可利用的資源，這個習慣在這次訓練營里成功讓我從scrum master處得到了一個“可以不看的需求文檔”和對于整個工具架構的大致介紹。

后來我發(fā)現(xiàn)這個“可以不看的需求文檔”在我的編碼過程中起到了巨大作用， 并且令我驚訝的是，除了我以外，其他人竟然在沒有這個文檔的情況下硬看代碼，于是他們雖然可以看懂一部分代碼，但卻無法完全把這個工具轉化成“和自己寫的一樣”的內化知識。

第二步，看有沒有單元測試。有單元測試的，那么就可以執(zhí)行單元測試。看看結果。看看測了哪些東西。有很多人不知道單元測試框架，實際上，不管你用java，c，c++，python，ruby，還是隨便什么語言，據我所知絕大部分語言都有自己的單元測試框架，或者叫單元測試執(zhí)行器。這些名字通常叫xxxUnit的東西，全都是一樣的原理。隨便學一個，其他都一樣掌握了。如果你是測試人員，建議你至少掌握一鐘單元測試執(zhí)行器，比如java語言的testNG。有這個基礎的人才能搞自動化測試，不要等老師來教你，教比學麻煩多了。

第三步，找獨立模塊。比方說我們的中間件測試工具里，對消息的編碼解碼部分調用了第三方庫來做。而對第三方庫的調用和一些數(shù)據結構的準備，就是一個相對獨立的模塊。并且我發(fā)現(xiàn)這個獨立的模塊還有自己獨立的單元測試。所以這就是我閱讀代碼的突破口。

第四步，從突破口調試代碼。我從編碼解碼的單元測試文件里開始單步執(zhí)行他的單元測試，于是我看到了整個代碼執(zhí)行的全過程，消息是如何從一段英文轉化成指定數(shù)據格式的對象，再以怎樣的方式定義消息頭設置消息長度，傳怎樣的數(shù)據給第三方庫，以及最后編碼的結果如何去驗證。這一步對后續(xù)工作的意義重大。

第五步，看核心模塊。我們這個工具的核心模塊是消息收發(fā)的模擬器。可以把他理解成單元測試里的樁的概念（stub）或者驅動（driver），也有人喜歡說這是類似于mock的東西。

這個核心模塊做了幾件事：

1，建立socket連接，等待客戶端連接他。

2，使用多線程，支持復數(shù)的客戶端連接。

3，和客戶端之間進行消息收發(fā)。調用了我前面看到的消息編碼解碼獨立模塊，把消息封裝好，然后通過socket連接把消息發(fā)送出去和接收回來。

4，建立消息隊列，把和復數(shù)客戶端的通信的消息序列分別存放。

5，即時處理需要立刻回復的消息。

6，生成一些需要自動生成的消息字段。

7，定時發(fā)送一些類似于心跳消息的東西給客戶端，以及處理對方發(fā)過來的這種消息。

第六步，從總的單元測試開始，一個一個單步調試。

第七步，為了證明我完全讀懂了，我自己畫了一個結構圖：

整個工具我劃成4個模塊，

1.消息編碼解碼

2.模擬器及其相關api封裝，調用消息編碼解碼模塊來發(fā)送消息

3.robot關鍵字，調用模擬器提供的api發(fā)送用戶想發(fā)的消息

4.單元測試

并且對每個模塊內部的邏輯，畫了詳細流程圖，從哪個類到哪個類，了解清楚單元測試的執(zhí)行中每一步驟的流程和消息是怎么組裝、怎么編碼、怎么發(fā)送、怎么接受回復的。

?

全部讀完，我一共用了越24小時，也就是3天（每天8小時）。至此整個測試工具不說了如指掌，也已經掌握得八九不離十了。再看我們要做的任務，我的感覺只有兩個字：簡單。

此時我們的其他成員（已讀了5+3=8天這些代碼）仍在埋頭苦讀，最令我不解的是，在我之前，沒有人嘗試去執(zhí)行單元測試，也沒有人去問訓練營的導師這個測試代碼可不可以執(zhí)行。

有開發(fā)人員能讀懂核心模塊，但每個人都在重復讀，沒有形成合力。至于測試人員則都根本不知道在讀什么東西。

于是我提議大家把自己讀的東西開會分享，讓完全不知道在讀什么東西的人也能對代碼有一定了解。

?

第一次編寫簡單的中間件測試工具（2） - 讀代碼的方法