【前言】
在蘭亭這段時間裏，做了很多項目，前前後後加起來有10幾個大版本和項目及很多的hotfix，當然每一個項目中都有收穫，都讓我得到一點點的積累和沉澱。但是讓我記憶猶新的還是第一個項目。
【正文】
入職蘭亭時職位是測試工程師，後來聽我老大說一般這個崗位的人都需要在別的小公司有帶過小團隊的經驗，或者是從跟蘭亭一樣或更大規模的公司平移過來的，我屬於前者，在創業型公司摸爬滾打了2年。這麼要求的原因是這個崗位是在測試團隊真正幹活的人，需要帶人做項目，屬於測試團隊的中堅力量。
在蘭亭做過很多的項目，最印象深刻的莫過於當時我以測試項目負責人名義全職做的兩個項目--review改版和MINI首頁改版。之後的很多項目我都算是作爲前端測試團隊的項目負責人來開展的，畢竟並行項目過多，而且都已經指派了項目負責人，我已經沒有那麼多精力E2E的這麼跟過了。
第一次聽說No-SQL
以前在創業型公司其實也用過No-SQL的數據庫，像Tokyo tyrant，只不過不知道No-SQL這個詞。事情的緣由是因爲原來存儲的網絡上抓取的頁面文件是放在磁盤上的，在讀寫時必然會導致磁盤I/O過高，所以後來遷移到TT server上來了。
在蘭亭的review改版項目上，使用到了redis，把所有用戶的評論及QA都存儲到redis，畢竟這些數據不像抓取的網頁那麼佔空間，總共加起來也不超過5G，而且更適合使用in-memory的場景，即加載到內存中可以高效的讀取。蘭亭其他項目也有使用MongoDB的，關於這三個常用No-SQL的差異大家感興趣可以查查資料。
項目週期過長
回過頭來總結當時的項目，的確有很多改進的地方，按理說這麼簡單的項目最多一個月搞完是沒有問題的，但是前前後後做了2個多月。總結起來最重要的一個原因就是流程不夠好，可以總結爲以下重要的兩點：
1）沒有制定測試准入標準，沒有督促開發人員進行自測，如果每一次測試前進行smoke，也就不會導致這麼長的週期，畢竟同樣一個bug經過兩撥人來反覆驗證總會比開發人員自己check耗時的多;
2）測試過程中隨意更新代碼，這個項目有三個測試人員參與，各自負責不同的部分，經常會因爲一個嚴重的bug fix後要更新代碼，但是更新的內容不僅僅包括這部分，還有其他的bug fix，加之第一點的緣故會導致之前測試OK的部分又出現問題，這將引起很多工作的重複。
也許是之前公司很少有多人蔘與的項目，基本都是一個開發對一個測試，或者幾個開發對二個測試，而且每次測試介入前開發都需要開發一個demo版本給老闆演示，這必然需要他們最好自測然後才提交給我們測試。所以第一次做多人蔘與的項目，情況必然不同。後來其他的項目流程被新來的總監進行了優化，做起來就順了很多。
我做的好的部分和壞的部分
對於我來說這也是第一次有這麼多人蔘與的項目，但是還是被老大表揚了:
1）項目跟蹤進行的較好，畢竟每天都有遇到各種問題，我能做的就是每天彙總重要的問題及時跟進讓大家處理，包括與需求不符的部分，需求變更後模糊的內容及重要bug；
2）執行力較強，從不拖延。
當然也有做的不夠好的地方：
1）既然我是項目負責人，我需要做的不只是我自己負責的部分能讓老大覺得靠譜，而且還要讓大家的工作都值得信任，也就是要做好每個人工作的指導和跟蹤，適當的時候彙總大家的進度及遇到的問題，並發現潛在的風險，的確那個時候對風險的把控能力有待提高；
2）大局觀不夠，記得這個項目上線之後遺漏一個bug，原因是在業務上與另一個項目相交叉，但是我和另外一個項目負責人都沒有意識到這一點。雖然我到目前爲止都認爲應該是負責整個前端業務的總負責人的失誤，但是這次的教訓讓我更懂得要從一定的高度來看待目前所有的項目，在以後的工作中給了我很大的啓發。
