平凡人的不平凡故事，平凡的故事：年輕開發者的那些傷心事-變量-匯編語言學習筆記

這并不是該年輕開發者的首次工作經歷。但是他的第一個項目已經被證明是有問題的。當時，他認為功能從來不會改變。但是他錯了，每次修改功能都需要一次徹底的重構，引發了bug以及大量時間的浪費。他甚至嘗試過編寫測試之類的、有效的方式。不過他的測試需要維護、編寫所需時間、甚至更多執行的時間。

平凡的故事：年輕開發者的那些傷心事

對于每個年輕的開發者，他在成長過程中總是聽到有經驗的開發者說到的“當心!過早優化是萬惡之源!”、“編寫測試!測試!測試!”。或許他只是在重構一個微小的實用程序方法，而這時有經驗的開發者將走過來、以嚴厲的表情警告說“你沒有做過早優化，對吧?”、或“你在寫測試，是嗎?”。

但是所有這些警告都被忽視了。因為年輕開發者不理解過早優化為什么是萬惡之源、也不理解測試應該是正確的。根據他自己的經驗，他知道下面的需求從長期看是不合理的(因為它們可能有修改)，編寫測試就是在浪費時間。

“我究竟為什么每次都必須重寫我的代碼?我究竟為什么必須在當下編寫代碼、隨后再重構，我什么時候能夠編寫世界上最好的代碼?還有，我究竟為什么不得不用我所有的時間來編寫沒用的測試?”這就是年輕開發者的疑惑。

平凡人的不平凡故事，一天，年輕開發者開始著手一個新項目。他決定無視有經驗開發者的警告;為了應對每次需求變化，他期望每塊代碼是快速的、可配置的和健壯的。需求清晰了，不過他要做得更好。比如，當有個功能，生成以大寫‘S’結尾的產品代碼時，他創建一個配置對象，這樣結尾的字母就可以通過配置來修改，通過配置還可以決定這個字母應該是大寫還是小寫。當需求說明需要一些校驗時，他就創建一個龐大的校驗器，不僅包含需求要求的，還有很多沒要求的。

在編寫了項目的核心之后，一種完美的感覺充滿了年輕開發者的全身。“那個有經驗的開發者是錯誤的!”年輕開發者看著自己的杰作得意地說。他夜以繼日地工作，認為數周后就可以發布產品了。

光陰荏苒……

一天，客戶告知他們一個bug。有經驗的開發者看到這個bug，對顯示器上出現的情況保留著厭惡：年輕開發者看到了大教堂，而有經驗開發者看到的是貧民窟;年輕開發者看到了模式，而有經驗開發者看到的是一個充斥著class的復雜網絡;年輕開發者看到了比光速還快的代碼，而有經驗開發者看到的是不必要的復雜算法。他不想碰這些代碼，因此他讓這個年輕的開發者去修復自己的bug。

其他人不認為年輕開發者的代碼是優美的，只有這個想法讓他感到失望。他充滿憤怒地打開了項目……才發現代碼對于他來說，也是費解的!代碼背后沒有清晰的意義。“這就是我不打算再使用這門語言的原因，語法太糟糕了”，往往是年輕開發者的第一反應。但是他在內心深處知道，這不是真正的問題。真正的問題是他。

關于平凡的故事，一天結束的時候，bug修復好了，卻產生了另一個bug，這是那一天之后發現的。每次修復都在影響著項目內部的瘦弱的平衡，就像亮白色衣服上的一小塊黑色補丁。

此時這個年輕的開發者絕望了，他的大教堂開始搖晃，他感到離崩塌不遠了。年輕開發者自問，“或許我不是這份工作的合適人選。為什么我不能編寫恰當的代碼呢?”帶著沮喪和憤怒的交織心情，年輕的開發者打開了有經驗開發者維護的項目。

他看到的代碼讓他感到吃驚：代碼有注釋和測試，易于閱讀。和他最初開始寫的代碼沒有太多區別，有一些清晰的例外：沒有可擴展的配置，每行代碼都被測試了，每個方法都取著有意義的名字、且簡短(最多10行代碼)，只做必要的，每個文件只包含了能夠嚴格做本質工作的方法。

在這個憂郁的時刻，有經驗開發者來到了年輕開發者身邊，和他挨得很近，開始重構引起所有bug的代碼。

他們一起工作了數天，有時候，有經驗開發者寫代碼，而年輕開發者觀看有經驗開發者如何解決問題;另些場合，年輕開發者寫代碼，而有經驗開發者在旁邊監督。

生活中的平凡小故事、數天后，一次新的部署標志著bug已被修復。引起bug的小部分代碼，現在可以被測試了、易于閱讀了，也很穩定。有經驗開發者看著年輕開發者說：“你現在明白了嗎?”

年輕開發者點了點頭，他現在明白了。完美的關鍵不是預測將來，而是編寫容易修改、測試(這樣修改就不會引發其它bug了)以及只需滿足當前需求的代碼。當他意識到這一點時，他注意到他正在變化，正在變成差不多有經驗的開發者。

年輕開發者問，“我們現在能夠重構整個項目嗎?”

有經驗開發者干脆地答道，“當然不可以!沒有預算”

年輕開發者問，“但是，如果其它bug出現了，該怎么辦?”

平凡又感人的故事。有經驗開發者答道，“我們將找個自由職業者(freelancer)來修復”