記錄一次填坑的通過

若是你寫的代碼不通過正式上線運行的過程，你永遠不知道本身寫得東西有多優秀或者多糟糕。

此次項目本身是從半路參與的，在項目到正式上線前 小組人員被調組或者離職 這個項目只有兩我的了，我是其中之一

近期項目正式大批量客戶切入，與此同時，伴隨着的是各類問題的出現。

首先 

被反應的是性能問題，導入數據上千條特別慢。（從這個時候我就進入了優化別人代碼的痛苦歷程，也就是填坑的過程。）

for 套着 for 多是業務須要，但每個for裏都執行一次數據庫操做 這是大忌 。鏈接一次數據庫耗時，大量的數據很快就會把數據庫鏈接資源耗盡，可能會出現事務套着事務，出不來就會致使數據庫死鎖

解決辦法:在for裏組織數據，出for再去批量執行。若是有不得以的數據庫操做，有一句也是不要緊的。

還有一方面影響速度的就是 數據校驗，與所有的數據進行對比校驗這個不多 通常都是對數據庫中部分符合條件的數據進行對比校驗，咱們這個項目是後者，因此無需查詢所有（隨着數據的不斷增長 這種查詢所有的操做會愈來愈慢），改改改。。

通過測試 剛開始導入21秒 優化後8秒，這個速度比較能接受了，不過還不是很快。由於業務的複雜度很高，校驗的很嚴格，暫且優化爲這樣。

其次

代碼邏輯問題。業務需求不變，能夠有多種方式實現，最終都能達到想要的結果。每一段代碼邏輯也是一我的大腦對業務的分析結果，分析的清晰 寫出來的一目瞭然

在我優化的過程當中 發現不少重複代碼，甚至是重複的保存數據操做，雖然這些不會形成災難，但也是影響性能的一部分。這樣的程序 讀起來很傷腦，若是不徹底的讀懂看明白 那修改的過程也是出bug的過程。當徹底讀完以後 發現不少是不必的，徹底是冗餘  就感受太坑。

最後

代碼規範 駝峯命名就不說了， 註釋聊聊無幾，致使維護起來很吃力

總結：爲何這些問題在項目測試過程當中沒有發現？

1：由於項目特殊 沒法徹底按線上作測試

2：沒有進行嚴格的code review，這個多是項目進度很緊，開發人員又都不是0經驗 

還記得本身第一次參與code review的時候還有點抵觸，由於懼怕犯錯，如今想一想真好笑，不糾正本身的錯誤 那就不會有進步。

總之：

填坑結束！

要對本身寫得每一行代碼負責到底，不給本身挖坑，不給別人留坑，多讀書，不斷提高本身。。。