======================
實事求是的講，寫《【野生程序員】：優先招聘》的時候，是帶著情緒的。其后也有反思，是不是我杞人憂天了？尤其是下面開始的幾條評論，如“都是混口飯吃的不容易”，“何以內外之分，中華兒女非山傾河泄而不能一氣前指，千年亦是如此”等，讓我感覺可能是我過于敏感了。但隨后一些人長篇大論，讓我明白，這篇博客還是有意義的。
想一想，招聘啟示里，你們要求“計算機專業本科以上學位”，我“無計算機專業相關專業文憑”優先；然后，你們就炸了！我們沒有歧視，你這才是歧視！你自卑你憤青你酸你難成大器……我無力反駁，只是想說，每個人的言行都是他心靈的鏡子。謝謝你們！
其實，我沒有想挑起科班/非科班之爭（雖然可能結果會超出我的預料），我的本意是想給“非科班”的同學鼓氣，緩解他們身上的壓力，讓他們看到希望，給他們力量，讓他們相信，完全可以在更艱苦的環境下自學成才，而且結果不會比“科班”的差！但你一定要委下身段踏踏實實的去學，一步一個腳印的去做，自卑自大爭吵辯駁都無助于你的成長。請牢記：言語沒有力量！
另外，愿意聽一句的“科班”同學，“無計算機專業相關專業文憑”優先，并非完全出于義憤。都是筑基，你是名門大派用資源用丹藥堆出來的，他是一路苦修戰斗領悟突破的，你覺得誰更有潛力？所以啊，放下那些虛榮驕傲，真正的去戰斗吧！畢業三年以后，是沒人再看你的學歷的。
另外聲明一點，對老趙沒有任何意見，除了景仰。他針對的是培訓機構我完全明白，但仍然不能贊同。所以我說，“每一次看到這一段文字，我的心里就會有一種難以言表的復雜情緒”，至于如何復雜，不是說了嗎？難以言表啊。
======================
好，心平氣和之后我們繼續討論技術問題。在帶隊的過程中，性能的問題還比較好解決，最消極的想法，“好啊，多一事不如少一事，你讓我不管還不簡單？”，但要求寫測試代碼，那就炸鍋了！以我的經歷，“測試驅動”是一個最具爭議的話題，沒有之一。吹捧者和反對者涇渭分明，而且都有大量的論據和證明。記得博客園曾經有一篇文章，大意是：“公司付錢給你不是讓你寫測試代碼的”，下面一片狂贊。
在我自己的項目開始的時候，我是放棄了測試驅動的（呵呵，還找到了原文），里面總結得很準確，最大的原因是“懶”。但最后讓我下定決心開始“測試驅動”實踐的，是我一次花了兩天一夜都沒調出一個Bug，垂頭喪氣筋疲力盡之后，無可奈何的接受了這個現實：測試還是很有用的——即使是自己寫的代碼。我之前的系列博客，也已經反復的強調，架構是一種“無奈”，是現實是問題驅使你去做一些其實你本來不想做的事情。你無法理解一些看起來像“脫了褲子放屁”一樣的行為，通常只是因為你沒有遭遇過那些現實那些問題。（看看，大學能教你這些東西么？）
即使你沒有多少開發經驗，你也應該能夠想象，單元測試最大的問題，就是它需要花時間花精力去寫，那么這個花費是否值得呢？這還是由你架構的目標決定的，或者你的需求決定的。如果系統是一次成型交付使用，此后幾乎不會更改的，那么一次性的手工測試就夠了；但如果你的系統是會被“千錘百煉”的不斷折騰修改的，那么這個測試就是很有必要的。最簡單的考慮：每一次更改，我都要手工測試一次；那還不會如我多花點時間，弄個“自動化”的東西出來。單元測試，其實就可以理解為一種自動化的測試工具。
但是“自動化”的理由還遠遠不夠。因為你馬上想到的，每一次需求變更代碼調整，測試代碼也得相應的改呀？沒有測試代碼，我就只需要改開發代碼；現在有了單元測試，我還得再改測試代碼。本來我只維護一套代碼，現在我憑空增加了一套代碼也需要維護，這不是增加了維護成本，不是和你“可維護性”的架構目標背道而馳了么？是一套代碼好維護呢，還是兩套代碼更好維護？
這是一個非常好的問題，適用于很多情景（比如分層架構，你說分層解耦，實際上還不是一改就得從UI層改到數據庫，每一層都得改？）。我能給出的回答大概有：
一、無論有無單元測試，開發代碼進行修改之后，是不是都要進行測試？沒有單元測試，并不代表你的代碼就不需要測試了，只不過是你手工的去測試了一遍而已。切記：你的工作并不只是把代碼寫出來而已！
二、進行手工測試，和更改單元測試，兩者的耗費比，會根據測試重用的次數而變化。一次手工測試可能需要5分鐘跑完，更改單元測試代碼可能需要20分鐘，但如果這測試會跑100遍，單元測試完勝手工測試。
三、你說，哪里喲？什么功能會改100遍？我沒說你的功能會改100遍，我說的是測試會跑100遍。有區別么？你可能還在犯迷糊，是吧？好吧，我們講個故事。
有一個小伙子，他很不情愿寫測試代碼。老板拿他沒轍啊，也沒那么多精力和他磨牙，于是老板自己寫單元測試。這小伙子的代碼提交之前要review，老板總能一次次的找出它代碼的問題。他改的是登錄，老板告訴他積分系統被他改出了問題；他又去改積分，老板又告訴他消息通知系統被他改壞了；他又去改消息系統，老板告訴他登錄還是有問題……于是他崩潰了，“這TM什么一個爛系統”？最終他終于回過神來了，為什么老板總能知道這里的改動會影響那里呢？老板的思維有這么嚴謹？老板躲在一旁偷笑，就不告訴你，“其實我就是跑了一遍單元測試而已”。
這個老板就是我。我故意的，就不一次性的告訴他所有的問題，就要這樣一次次的折磨他，讓他的痛苦能刻入骨子里去。最后，我還要問他：
- 你現在對你的代碼是不是還那么自信？
- 如果沒有我的review（我也是靠單元測試），你能不能發現這些問題？
- 如果我們的項目已經部署到生產環境，而且你的改動帶來的破壞沒有被發現就上線了，會帶來什么樣的后果？
這一次，他服氣了。后來他用NUnit用得麻溜麻溜的。每一次改動，如果有意想不到的未通過test case，他都會很激動的給我張截圖，順便發發牢騷。我微笑不語，那種滿屏綠燈通過的踏實，和意外爆出紅燈之后的驚喜，沒有經歷過的人，是無法體會的。
所以其實當對象間的關系變得越來越錯綜復雜，像一張密密麻麻的網一樣之后，一個局部的改動就很有可能會觸發極其復雜的連鎖反應。所以為了保險起見，所有可能相關的組件都應該進行測試（所謂的“回歸測試”）。這時候如果只有純粹的手工測試，會面臨兩個問題：
- 難以確定測試的邊界（那些部分可能會被影響），這得我們腦袋憑空硬想啊，兄弟！
- 極大的測試耗費。而且這種耗費是相當的無聊繁瑣傷人心的——沒人愿意做這種事。據說所知，現在很多公司測試人員的工資已經比開發人員還高了。為什么？簡單枯燥無聊，沒人愿意做啊！
好的，我假設你已經認識到了單元測試的重要性，并開始摩拳擦掌，躍躍欲試。接下來我得給你潑一大瓢冷水：單元測試不是那么好寫的！從某種程度上講，寫單元測試比寫開發代碼還難。難得我工作的所有公司，沒有一家有過成功的案例。
大概是幾年前，我在公司修bug，老大告訴我，“你這個功能比較核心，跑一下單元測試吧”。
“哇塞！我們有單元測試？”一種高大上的感覺迅速彌漫全身，終于見到傳說中的Unit了！
搗鼓了一會，能跑了，試試看——我的個媽呀？怎么這么多紅燈？我真被嚇住了，這都是我的改動造成的？
老大就是老大，不慌不忙，“數一下有多少個通不過？”
“啊？”我以為我聽錯了，數多少個通不過有什么用？得把他們全部弄通過啊？！
搞了一會兒，才終于弄明白了，把我改動前后的代碼分別跑一遍，對照一下通過失敗是不是一樣的，只要是一樣的，就OK了。比如，以前是8個通不過，現在還是8個通不過，這樣就可以了！
我一直不明白，為什么不把那8個通不過的單元測試給弄成通過呢？這樣擺著究竟算什么？直到我自己開始寫單元測試。坑爹啊！到處都是坑，跳出小坑進大坑，大坑下面還連著小坑，前面是坑后面是坑，一堆一堆的連環坑……
單元測試寫出來容易跑過難！而且跑不過的原因還不是你的開發代碼邏輯錯了，而是測試環境/數據出問題。要測試，一定要有數據，這個數據的構建，完全不是我們所想象的那么簡單。以我們創業家園項目里的積分系統為例，假設一個簡單的需求：博客被點贊，博客的作者應該獲得一定積分，該積分數量是由點贊人目前所有的可用幣轉換而得來的（已簡化，具體可參考文檔：積分）。要準備的數據就有：博客一篇，要有作者，作者已有積分；點贊人一名，有一定數量可用幣。如果只是這樣，還可以接受，但其實下面會有一堆的問題：
- 作者的積分從哪里來？我們的開發代碼，出于封裝的考慮，用戶的積分是只讀的，你單元測試怎么設這個值？
- 要么寫代碼，模擬作者通過其他行為（發布文章回答問題等）獲得積分，這將開啟新一輪噩夢；
- 如果用Mock或者反射強行設置，事實上省略了作者獲得積分的歷史，所以用戶“積分歷史”為null，之后對其“加積分”時，就會報異常。
- 更坑的是，你以為你什么都處理好了的時候，你突然悲哀的發現，這個博客得首先“被發布”，而博客一經發布，其作者就獲得了一定數量的積分，所以你以前設置的積分又變了！
- ……
- 點贊人的可用幣，同樣可能遇到類似的問題。可用幣怎么設置，設置之后會不會在跑測試時被意外更改？
- 點贊的行為，被封裝成一個方法，運行這個方法，會檢查點贊人之前是否已經對該文章點過贊，所以還應該有一個“點贊歷史記錄”，哪怕是空的，都得new一個，否則就空異常
- ……
反正當時是寫得我直接摔了鼠標！寫得憋屈啊！而且我還是完全隔絕了數據庫的，真不知道那些要從數據庫里取數據來跑單元測試的，是怎么做的？這時候我一下子就明白了，實際工作中加班趕進度，一個接一個的填坑，連重構的時間都沒有，怎么可能還擠得出時間來寫單元測試？就算開始雄心勃勃的寫了，隨著系統日益復雜，維護單元測試的成本也與日俱增，甚至復雜度更甚開發，所以放棄也就成了絕大多數項目的唯一選擇。
在公司上班么，大多數人都是這樣的，能推就推。我們開發寫完了代碼，基本上能跑了，就該交給測試人員了呀！天經地義的嘛，是不是？而且測試的時間是不會計算到我的項目開發時間里的，我總算是按時完成了開發任務。累壞了，休息一下，讓測試的忙活去吧，哈哈……
但我是個光桿司令，我沒測試人員啊！曾經有那么一兩個時候，我真準備招一兩個測試人員的。但好在我天生的節儉美德（也就是“摳”啦）讓我冷靜下來。我就想啊：測試只能告訴你出了bug，不能告訴你根源啊。沒有單元測試，我單步調試，不也折騰了兩天了么？這是系統本身的復雜性，或者代碼組織的不合理造成的，不能歸咎于單元測試。不還是有這么多開源代碼都有詳盡的單元測試么？他們是怎么做到的呢？在單元測試上的付出，最終一定會獲得超值回報！想想沒有單元測試的公司，那超級龐大的測試團隊，或者四處冒煙的系統，你愿意走這么一條路么？
所以我不斷的告誡自己，不要著急，冷靜細致。終于一步步抽絲剝繭，把這一團亂麻一點點的歸納整理，最終還真被我找到了一條路子，一個個的單元測試都慢慢完成通過了，開發代碼里潛在的一些問題也浮出水面，被我一個個的消滅。最后再跑一遍單元測試，一路綠燈，哈哈！更奇跡的是，困擾我兩天的bug不知道什么時候消失了？
后來，我看到這樣一種說法：可測試的代碼不一定是好代碼，但壞代碼幾乎是不可能被測試的。深以為然！深度耦合的代碼，寫他們的單元測試，難于上青天；但反過來，我們可以以可測試為標準，不斷的完善重構開發代碼，只要這樣堅持下來，最終代碼的質量怎么都不會差到哪里去。
所以，于我而言，單元測試是否有價值的爭論可以休矣！不如換個角度，想一想，怎樣才能把單元測試堅持下去。
最后，如果有心的同學就會注意到，我一直用的是“單元測試”，而不是“測試驅動”。因為測試驅動是一個更廣闊的概念，是一個更嶄新的天地！單元測試只是其中的一小部分，在下一篇博客，我會講解我是如何試著將測試驅動的概念運用到項目開發管理中去的。這里，需要強調的一點：先寫測試。
一上手就寫開發代碼，寫完了才寫單元測試。這是很多開發人員的習慣，我也經常犯這樣的毛病，一不留神就忘了。這樣做最大的問題就是，沒有真正實現“測試驅動”。你實際上還是由開發在驅動，那么很自然的，測試照著開發的if...else...寫一遍，有什么意義呢？這樣做下去，就會不斷的強化“測試無用累贅”的印象，因為測試就是簡單的把開發代碼重寫一遍而已。我開的藥方是：
- 單元測試代碼和開發代碼由不同的人員編寫
- 如果做不到上面一點，先寫單元測試
- 如果連上面一點也做不到，直到出了bug了再寫單元測試
第三條可能有同學無法理解，不是說單元測試很重要么？為什么要等到出了bug才寫？答案是：偷懶唄！記住，我們程序員是世界上最懶的人，沒意義的事從來不做！你先寫開發代碼再寫測試真的沒意義，沒意義就干脆不要做了。但你可以開啟“樂觀模式”（或者“Lazy模式”？），先樂觀的認為，我的代碼沒問題，或許真的就沒問題呢，是吧？如果真出了問題，做一個補救，這個時候就應該用單元測試把這個問題表現出來，因為他根據墨菲定律，它這里出了問題，以后就很有可能繼續出問題。這個時候，就不要再偷懶了。
（未完待續）
文章列表
留言列表
