你可能覺得折騰這么一套東西動作也挺大的。我得說,“看菜吃飯”。
另一個例子,有一個測試框架,萬事俱備,就是沒法把test case自動傳送到Apple Macintosh的機器上?,F有的代碼可以讓test case在Apple Macintosh上執行,也可以把test case從服務器下載到Windows測試機器上發動執行,但是沒法跟Apple Macintosh交流。
怎么辦?在Apple上開發誰都不懂。在Apple Macintosh上寫一個客戶端跟服務器交流,夠忙半天的了。面對一整套已經完備的測試框架,讓它盡快用于新的環境,比做什么都重要。
別人告訴我,可以Apple Macintosh上開一個共享夾,然后Windows的機器可以用UNC路徑往里面讀寫文件。
OK,這就足夠了。Windows測試機器上發動執行的只是一個腳本,把需要用到的文件往指定Apple機器的共享文件夾上寫。寫完之后再寫一個文件,名字是約定好的,例如“ready”,里面包含啟動test case的命令行。然后不停的隔一段時間檢查共享文件夾里面一個叫做例如“done”的文件,出現之后把它作為結果返回服務器,最后把它和其它文件都刪掉,退出。
Apple Macintosh上面則運行另一個腳本,始終不退出。它不停的隔一段時間檢查其指定的共享文件夾里面一個叫做“ready”的文件,出現之后執行里面的命令并且等待它結束。這個命令必須生成一個叫做“done”的文件,包含執行結果。然后,不停的隔一段時間檢查“done”是不是還在,不在了就回到最初的檢查“ready”的代碼。
這就足夠了。兩個腳本加起來50行不到。
你覺得它太粗糙了吧?這么簡單的協議?
事實上,它并不需要十分健壯。
一、 Windows和Macintosh雙方的網絡文件系統協議解決了很多問題
二、 測試機器是不會有人去用的,你可以安全的假設只有你的程序在執行
三、 服務器和test case都已經測試過,他們應該負擔起若干健壯性的需求。事實上,他們比這兩個腳本更適合做這個,不是嗎?
這就是“看菜吃飯”:不需要的功能,是不需要去實現的,無論它看上去有多么的cool;必需的功能,無論如何都要做到,無論它看上去有多么的boring。
其實,無論開發測試,都是為了讓人們更好的發揮自身的潛力。開發工程師讓人們可以專注于自身的事業而不用過多學習計算機技術;測試工程師讓開發工程師可以發揮自身開發的潛力而不用過多參與質量保證的事務。代碼高下之分,只能通過讓人們發揮了多少潛力來檢驗。
《神雕俠侶》里提到獨孤求敗晚年“飛花摘葉皆可傷人”,皆因“不滯于物”,達到“無劍勝有劍”的境界。
所以,開發和測試工程師寫出來的代碼高下之分,對于這個問題,我會這樣回答:皆可傷人,何須理會是花葉還是刀劍;都能發揮人們的潛力,不必關心來自開發還是測試的手筆;優劣之分,或者只來自于用劍者本身。