第二次正式javaweb開發專案的總結（回收站恢復）

都說網際網路行業加班很是厲害，記得前不久網上還曬出了幾個大城市網際網路行業的加班排名調查，但是我們公司，或者說我們專案組倒是非常的例外，進公司也差不多半年了，才僅僅上個月有一個週六加過一天班而已。

不過好在，雖然不加班，但是事情還是有的，每個月基本上都有任務，一週需求，一週開發，一週聯調，然後再一週測試，可能細節上不完全這樣，但大體上也就這樣吧。因而雖然不怎麼加班，倒也不至於說是什麼事都沒有。

 介於這樣的安排，上上個月完成了我的第一次正式專案，也就是我們專案的迭代八，而上個月一個月的時間，又結束了我的第二次正式專案，也就是我們專案的迭代九。

相對於迭代八我只負責一個功能的實現來說，迭代九的工作就要多很多了。

因為之前兩個來的久一點的同事被調到了其他專案組，所以我不僅要接手其中一個人的模組維護，還要負責新的迭代中兩個統計模組，這樣不僅從量上變多了，邏輯複雜度上也比迭代八要高。

 這一輪的迭代，雖然說不是完全的新模組，只是在舊模組上修改，但是實際上在實現的時候，基本上跟新增沒有多大的區別。

在我們的mongodb資料庫中，統計需要用到的源資料表有四個，在統計的時候，之前的做法是把四張表的資料跑定時器統計出來，然後放到一個新的統計表中，再在專案頁面統計的時候，直接拿出統計表中的資料就夠了。

而新的需求中，要求把定時變成實時，如此一來，每一次的統計都需要根據不同的條件查詢四張表，再把四張表的資料進行一定的處理：合併或者拆分。

同時查詢四張表，如果是關係型資料庫，可能會簡單很多，但是mongodb是非關係型資料庫，又因為自己對mongodb的使用並不是很熟，因此也是繞了相當多的彎子才勉強搞定。

應該是有了上一輪迭代的經驗積累吧，這一次雖說工作比上次多了而且難了，但是我實際用的時間並不比上一次的多，甚至從某種程度上來說所花費的時間還要少一點。

這一輪的迭代，對mongodb的基本操作有了更進一步的掌握，上一輪中，學會了基本的增刪改查語句，這一輪在此基礎上新掌握了不同資料庫間表的匯入和匯出，根據多條件查詢以及排序和分組。

因為統計涉及到的資料很多，在測試除錯的過程中，也要不斷的把頁面上的資料和資料庫中的資料對比，因此也算是更熟練的掌握了調錯、找錯的技能，能更快的找到問題根源。

相對於上一次基本上弄清了springmvc的三層結構，這一次也算是進一步練習了三層結構的使用，除此之外，對於集合、陣列等資料的封裝和拆分也有了更進一步的理解和使用。

 如果說收穫的話，這一次最大的收穫，大概就是關於程式碼優化和重構了。我所負責的兩個模組，實現細節上有很多的不同，但是有一些環節卻是大同小異的，可能是由於經驗方面的不足，或者是知識方面的欠缺，所以在好幾個地方都有看起來似乎一樣的，但仔細看又不一樣的程式碼。

當看到這些程式碼的時候，我想過要提煉出來，但是幾經嘗試後，沒能提煉成功，我以為可能是真的不能提煉了。直到後來專案經理看到後，熱情的幫我弄了一下，我才發現原來並不是不能提煉，而是自己經驗不足，所以思維過於侷限了。

值得一提的是，在專案經理指導我提煉上邊程式碼的時候，順便指出了我另外一個可以優化的地方。

在程式碼中，我有幾個地方需要判斷一個list中的元素是否存在於另一個list中，於是我用了for迴圈，結果專案經理只用了一個contains方法就搞定了我十幾行。由此可見，有的時候多掌握一點知識，可能就能為我們省下很多的工夫了。

書山有路勤為徑，學海無涯苦作舟，這句很早以前的名言早就烙印在我的心中，但是自從進入軟體行業以來，我突然發現雖然要學的東西很多，但其實也是樂趣無窮！