>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

這是一個真實的故事，故事的主角是一位雖然年輕卻充滿了激情的程序員。那還是2004年底，他剛開始在一家小公司工作：一份不錯的薪水，使用的是他最愛的編程語言，能接觸到各種疑難雜癥，還可以做建模架構的工作。

對于這位年輕的開發人員，這并不是第一次工作經驗。但是他的第一個項目卻被證明是有問題的。那時候，他認為功能是不需要變的。但是他錯了，于是乎，每個功能的改變都需要全部重構，從而導致bug橫行以及時間的巨大浪費。他甚至嘗試了一些良性的方法，如編寫測試。但是他的測試需要維護，需要編寫時間，以及更多的時間才能被執行。

和每一個年輕的開發人員一樣，他的成長道路上都是那些經驗豐富的開發人員的聲音，“過早的優化是罪惡的根源！”，以及“寫測試！測試！測試！”。也許他只是在重構一個小型的實用方法，但這個時候經驗豐富的開發人員過來了，鄭重其事嚴肅地警告他，“不是告訴過你不能過早的優化嗎？”，或者“你這是在寫測試么？”。

但往往，年輕的開發人員直接就左耳朵進右耳朵就出了。因為他們不明白為什么過早的優化應該是罪惡的根源，以及為什么要寫好測試。從他以往有限的經驗來看，他認為接下來的技術指標并不能長效工作（因為它們往往會改變），以及寫測試純粹是浪費時間。

“到底是為什么我每次都需要重寫代碼？究竟又是為什么現在我寫的代碼之后還需要重構？還有就是到底是為什么我得花這么多的時間用來寫那些沒用的測試？“年輕的開發人員心里在咆哮。

于是乎，終于有一天，年輕的開發人員又開工了一個新項目。這一次，他決定無視那些經驗豐富的開發人員的警告：他相信他寫的每一個代碼片段都會既快捷、可配置，又強大，并且可以承受每一次參數規格的改變。

在他絞盡腦汁地搞定項目的核心之后，年輕的開發人員忍不住得瑟起來：“哈哈，我就說那些‘老家伙’的話是錯的！”仿佛凱旋在望，年輕的開發人員眼中已經出現了勝利的光芒。

然而，發布一段時間之后……

突然有一天，客戶告知他們程序發現了bug。經驗豐富的開發人員看了這個bug，找到問題的所在，就要求年輕的開發人員去修復他自己造成的bug。

聽到自己的代碼被嫌棄了，年輕的開發人員第一感覺是生氣。但是當看了項目之后……卻發現，他居然無法理解自己寫的代碼了！他已經完全看不懂這些代碼的含義！天哪，嗚呼哀哉！

但是沒辦法，這是他的問題，他也只能硬著頭皮上，好了，終于修復好了這個bug——但是過幾天又出現了新的bug。bug——補丁，bug——補丁，焦頭爛額。

年輕的開發人員簡直要崩潰了，“也許我并不適合這種工作，不然我的代碼怎么總也寫不好？”在各種質疑自己的聲音中，年輕的開發人員半信半疑地打開了經驗豐富的開發人員的項目。

他震驚了！代碼是如此簡單易懂——有注釋、有測試。這跟他寫的代碼完全有著本質的不同。特別明顯的區別就是：沒有額外的配置，對每一行代碼都進行了測試，每一個方法都有一個有意義的名字，并且方法非常短（最長的也只有幾十行代碼），代碼只做了客戶要求做的事情。

在那一刻，年輕的開發人員是非常沮喪的，但是經驗豐富的開發人員來了，他走到年輕的開發人員的身邊，一邊走他其實一邊已經在開始考慮如何重構這些錯誤的代碼。

在一起合作解決問題的時間里，年輕的開發人員目睹了經驗豐富的開發人員一步步解決問題的過程；有時候經驗豐富的開發人員還會監督年輕的開發人員編寫代碼。

幾天以后，又一次發布標志著bug已經被修復了。造成bug的那部分代碼片段現在已經進行了測試，不但易于閱讀，并且非常穩定。經驗豐富的開發人員看著年輕的開發人員，問：“你現在應該明白了吧？”

年輕的開發人員點點頭。現在他確實明白了。想要完美，其關鍵并不是能夠預測未來，而是編寫易于改變并經過測試的代碼（這樣，如果要改變代碼的話才不會造成bug），而且只需要滿足當前的需求。而當他意識到這一點的時候，他在無形之中，已經蛻變成為了“差不多”經驗豐富的開發人員。

“我們現在要重構整個項目嗎？”年輕的開發人員問。

“當然不！這又沒有預算的。”經驗豐富的開發人員斬釘截鐵地回答。

“但是，要是出現其他bug怎么辦？”年輕的開發人員問。

“可以讓自由職業者來解決那些問題。”經驗豐富的開發人員答復。

然后，“差不多”經驗豐富的開發人員開始能寫出優良的代碼，漸漸地向更高層次的水平靠近。當然，這是另一個故事了。

對于年輕的開發人員的建議：請回過頭去看看你曾經寫的代碼，如果你的代碼現在看上去沒有以前感覺的那么漂亮，那么說明你在進步。

對于經驗豐富的開發人員的建議：當你的身邊出現了一個年輕的開發人員，或許你需要不時地替他們收拾爛攤子。如果你想擺脫這樣的處境，那么就讓他們盡快學會編寫得體的代碼。

對于自由職業者的建議：你或許應該提高你的酬勞了：-P

(來源:碼農網)

CocoaChina 2015-08-23 08:46:34