過早的優化是萬惡之源

作者：Grey

原文位址： 過早的優化是萬惡之源

這兩天，我做了兩件事：

　　1.重構了系統某個子產品的部分代碼：

　　花了一天時間，一個6k多行的java檔案，搞到4k行加若幹個類檔案，恕我能力有限，後面的實在重構不下去了，那是一種3個domain屬性名幾乎一樣100多個字段但是卻用同一個copy了三遍的方法來處理的欲哭無淚，那是一種使勁滾滑鼠滾輪都滾不到一個方法尾部的絕望（100多個字段的幾個類屬性equals來，equals去，get來，set去的，這樣類型的方法有那麼五六個，你說能不多嗎）......

　　2.做了一個日志處理的小工具：

　　客戶要求把日志裡面記錄的一些東西整理出來發給他們業務人員分析，有若幹個日志檔案，20多m一個，我本來打算一個一個Ctrl＋F，Ctrl＋C，Ctrl＋V的，但是後來想到自己能否更高效去處理這件事，畢竟自己出來工作兩年了，很多時候做一些重複的事情，這樣不會有提高，是以我決定用自己寫個處理日志的小工具

　　把一個log檔案裡面的内容按關鍵字找到然後解析相應字段然後格式化寫到excel裡面去，

　　我把日志簡化一下，其中一個片段樣子大概是這樣的：

　　我們需要取得field1，field3，field4，field5名字以及值， field3-field5很好辦，直接定位"field3:"所在的行，然後把這一行取出解析出來即可

　　但是field1的值不是很好處理，我當時就想了最傻的一個辦法：掃一遍檔案解析出field3-field5，然後用field3的值再掃一遍檔案找到field1的值，速度那個慢呀！後來就想了一個稍微更聰明一點的辦法，把:

　　封裝成一個資料結構, 每一行用一個字元串來裝，在掃描第一遍的時候，就把這個資料結構的用List存起來，假設為TempList，把field3－field5作為一個資料結構存進一個list，這樣的話 我處理之前得到的field3－field5這個List和這個TempList，記憶體操作，速度提升很明顯。

收獲和教訓：

做這兩件事的一個大背景是在版本正在開發的過程中，我寫的版本計劃預留了一部分時間去應對需求變更，但是自己卻花了多餘的時間做了第一件事，吃力不讨好，最後還沒動需求要做的東西，重構了半天，代碼還是如此的讓人絕望，現在才深刻體會到，看别人寫的優秀代碼，是對自己的一種提高，看别人寫的很惡心的代碼，對自己也是一種提高：告訴自己不要這樣寫。

效率這個東西，是很重要的，特别是在做項目的過程中，如果能盡量讓機器幫忙解決的事情，就不要人工去做，而對于程式員來說，盡可能多的寫一些小工具（當然我技術不好，可能寫個工具的時間都要影響進度-_-#）來幫忙解決一些手工問題：比如之前在每個版本打分支的時候都需要建立項目的空目錄，然後申請相應SVN權限，然後把空目錄删除，将上一個版本在svn上copy to 一份出來作為開發，因為工程比較多，這個建立空目錄的過程很繁瑣，是以我就寫了一個cmd腳本來運作建立新目錄，這樣每次打分支之前運作這個腳本即可，省去了一些copy/paste操作。

項目開發的過程中，核心的技能就是盡量精确的評估，如果一件事，你沒有評估就貿然去做，是一件非常可怕的事情，如果讓我重新選擇，我不會拿上班的時間再去重構這部分代碼，我會先把任務完成，完成的基礎上，下班後，在Intern version（for practise）上練習重構。

突然想到自己為什麼要用這個标題。-_-# ，重構的這部分代碼不是我寫的，當我看到這樣的代碼的時候常常會特别憤慨地說當時為什麼寫這樣難維護的代碼出來，後來當我寫這個小工具，回頭看看自己曾經寫過的那些一點都不亞于這種難維護的代碼的時候，我明白了：在做項目的時候，特别是極度緊迫的時間裡，解決問題才是最重要的。如果你效率極高，能力極好，腦海中各種模式爛熟于心，一看到一個場景立馬可以建構出可重用，易擴充的代碼，那無可厚非；但是對于我們這些普通小白碼農來說，首先解決這個問題，有時間多自己再折騰折騰把。