那還是2004年底，他剛開始在一家小公司工作：一份不錯的薪水，使用的是他最愛的程式語言，能接觸到各種疑難雜症，還可以做建模架構的工作。
對於這位年輕的開發人員，這並不是第一次工作經驗。但是他的第一個專案卻被證明是有問題的。那時候，他認為功能是不需要變的。但是他錯了，於是乎，每個功能的改變都需要全部重構，從而導致bug橫行以及時間的巨大浪費。他甚至嘗試了一些良性的方法，如編寫測試。但是他的測試需要維護，需要編寫時間，以及更多的時間才能被執行。
和每一個年輕的開發人員一樣，他的成長道路上都是那些經驗豐富的開發人員的聲音，“過早的優化是罪惡的根源！”，以及“寫測試！測試！測試！”。也許他只是在重構一個小型的實用方法，但這個時候經驗豐富的開發人員過來了，鄭重其事嚴肅地警告他，“不是告訴過你不能過早的優化嗎？”，或者“你這是在寫測試麼？”。
但往往，年輕的開發人員直接就左耳朵進右耳朵就出了。因為他們不明白為什麼過早的優化應該是罪惡的根源，以及為什麼要寫好測試。從他以往有限的經驗來看，他認為接下來的技術指標並不能長效工作（因為它們往往會改變），以及寫測試純粹是浪費時間。
“到底是為什麼我每次都需要重寫程式碼？究竟又是為什麼現在我寫的程式碼之後還需要重構？還有就是到底是為什麼我得花這麼多的時間用來寫那些沒用的測試？“年輕的開發人員心裡在咆哮。
於是乎，終於有一天，年輕的開發人員又開工了一個新專案。這一次，他決定無視那些經驗豐富的開發人員的警告：他相信他寫的每一個程式碼片段都會既快捷、可配置，又強大，並且可以承受每一次引數規格的改變。在他絞盡腦汁地搞定專案的核心之後，年輕的開發人員忍不住得瑟起來：“哈哈，我就說那些‘老傢伙’的話是錯的！”彷彿凱旋在望，年輕的開發人員眼中已經出現了勝利的光芒。
然而，釋出一段時間之後……
突然有一天，客戶告知他們程式發現了bug。經驗豐富的開發人員看了這個bug，找到問題的所在，就要求年輕的開發人員去修復他自己造成的bug。
聽到自己的程式碼被嫌棄了，年輕的開發人員第一感覺是生氣。但是當看了專案之後……卻發現，他居然無法理解自己寫的程式碼了！他已經完全看不懂這些程式碼的含義！天哪，嗚呼哀哉！
但是沒辦法，這是他的問題，他也只能硬著頭皮上，好了，終於修復好了這個bug——但是過幾天又出現了新的bug。bug——補丁，bug——補丁，焦頭爛額。
年輕的開發人員簡直要崩潰了，“也許我並不適合這種工作，不然我的程式碼怎麼總也寫不好？”在各種質疑自己的聲音中，年輕的開發人員半信半疑地開啟了經驗豐富的開發人員的專案。他震驚了！
程式碼是如此簡單易懂——有註釋、有測試。這跟他寫的程式碼完全有著本質的不同。特別明顯的區別就是：沒有額外的配置，對每一行程式碼都進行了測試，每一個方法都有一個有意義的名字，並且方法非常短（最長的也只有幾十行程式碼），程式碼只做了客戶要求做的事情。
在那一刻，年輕的開發人員是非常沮喪的，但是經驗豐富的開發人員來了，他走到年輕的開發人員的身邊，一邊走他其實一邊已經在開始考慮如何重構這些錯誤的程式碼。
在一起合作解決問題的時間裡，年輕的開發人員目睹了經驗豐富的開發人員一步步解決問題的過程；有時候經驗豐富的開發人員還會監督年輕的開發人員編寫程式碼。
幾天以後，又一次釋出標誌著bug已經被修復了。造成bug的那部分程式碼片段現在已經進行了測試，不但易於閱讀，並且非常穩定。經驗豐富的開發人員看著年輕的開發人員，問：“你現在應該明白了吧？”
年輕的開發人員點點頭。現在他確實明白了。想要完美，其關鍵並不是能夠預測未來，而是編寫易於改變並經過測試的程式碼（這樣，如果要改變程式碼的話才不會造成bug），而且只需要滿足當前的需求。而當他意識到這一點的時候，他在無形之中，已經蛻變成為了“差不多”經驗豐富的開發人員。
“我們現在要重構整個專案嗎？”年輕的開發人員問。
“當然不！這又沒有預算的。”經驗豐富的開發人員斬釘截鐵地回答。
“但是，要是出現其他bug怎麼辦？”年輕的開發人員問。
“可以讓自由職業者來解決那些問題。”經驗豐富的開發人員答覆。
然後，“差不多”經驗豐富的開發人員開始能寫出優良的程式碼，漸漸地向更高層次的水平靠近。當然，這是另一個故事了。
對於年輕的開發人員的建議：請回過頭去看看你曾經寫的程式碼，如果你的程式碼現在看上去沒有以前感覺的那麼漂亮，那麼說明你在進步。
對於經驗豐富的開發人員的建議：當你的身邊出現了一個年輕的開發人員，或許你需要不時地替他們收拾爛攤子。如果你想擺脫這樣的處境，那麼就讓他們儘快學會編寫得體的程式碼。
對於自由職業者的建議：你或許應該提高你的酬勞了：-P
來自：PHP100
評論(2)