很長時間以來，我每天花在地鐵上的時間都在一個小時以上。閑來無事，我就在手機上下載了多看閱讀，并且購買了很多電子書。最近，我閱讀了《異類》，頗有感觸。作者在書中提出了一個“一萬小時”的定律，也就是說，當一個人花在某件事情上的時間超過一萬個小時之后，就會發生質的改變，就會做到比絕大多數人好。我們耳熟能詳的一些天才，像蓋茨、喬伊等等，雖然天賦很高，但自身也很勤奮，花了比常人多得多的時間在自己所喜歡的事業上。也就說是，是“一萬小時”定律讓他們與眾不同。

量變引起質變的規律也適用于軟件開發領域，本文中提到的問題，即是一例。

問題描述

在某項目進行了長期的自動測試工作之后，我們組建了如下的系統架構：

最近，在進行自動測試的過程中，我們發現測試用例的執行總是失敗的。更具體地說，就是消息觸發腳本無法調用發消息工具，兩者之間無法建鏈。

原因分析

本測試系統已搭建了長達兩年，已經累積了上千個測試用例。之前從未遇到過此類消息觸發腳本無法調用發消息工具的問題。那么，究竟是什么原因引起的呢?

我們首先檢查了自動測試環境，發現一切正常。之后，我們修改了自動測試的調用腳本，變成了手動觸發。也就是說，當發消息工具成功啟動之后，我們再點擊消息觸發腳本，發現鏈路能夠正常建立，且消息發送正常。那么，為什么自動測試的時候就不能正常建鏈呢?

我們再回過頭來分析了一下自動測試的整個流程。當自動測試啟動之后，消息觸發腳本和發消息工具幾乎是同時開始運行的，而發消息工具運行起來之后，要先讀取配置文件中的測試用例，然后綁定IP和端口號，完成之后再等待和消息觸發腳本建鏈。前期的測試用例比較少，所有當消息觸發腳本監測與發消息工具的鏈路的時候，后者已經成功讀取了配置文件，并綁定了IP和端口號。這樣，后續的流程就能夠正常執行。

但是，隨著測試用例的累積，當消息觸發腳本開始監測與發消息工具的鏈路的時候，后者還在讀取配置文件，并未綁定IP和端口號。這樣，消息觸發腳本發現鏈路還不具備，因此執行就失敗了。這也就是我們看到的現象。之所以手動能夠執行成功，是因為我們點擊消息觸發腳本的時候，發消息工具早就完成了讀配置和綁定IP與端口號的操作(手動操作要比自動操作慢很多)，就不存在建鏈不成功的問題了。

問題解決

根據以上分析，我們只需要給發消息工具足夠的時間，讓消息觸發腳本晚點與發消息工具建鏈就可以了。

我們在消息觸發腳本中添加了如下語句：

ping 127.0.0.1 -n 30 

當消息觸發腳本執行了30次ping操作之后，發消息工具早就做好了準備工作，于是建鏈成功，后續流程順利執行。

總結

本文中提到的建鏈失敗問題的解決辦法雖然簡單，但該問題卻提醒了我們，在兩個模塊需要進行消息交互的時候，發送消息的模塊一定要等到接收消息的模塊“準備好”之后，再發送消息過去。也就說是，軟件模塊的初始化需要時間，在設計軟件的時候，我們一定要將各個模塊的初始化時間考慮進去。

【本文是51CTO專欄作者周兆熊的原創文章，作者微信公眾號：周氏邏輯(logiczhou)】