個人2013年

不知不覺已經工做4年了，博客也荒廢了多年，今年對於我來講是個難以想象的一年，項目也已經成功上線收尾了，是時候給本身總結一下這一年的得失，也但願這篇博文能給你們帶來一些新的想法與方向。

生活上
　　從國內來到了國外，想念家人、朋友、食物，但並不想念霧霾、地溝油、三聚氰胺、瘦肉精、擠公交...
　　國外確實是藍天白雲，空氣很清新，大部分人都頗有禮貌、頗有秩序，公交師傅會和每一個上車的乘客問好，馬路上的車輛會停下讓你先過，可能與生活節奏有關吧，國外的生活節奏沒有國內那麼快，也沒有國人那麼勤勞。感受國人天天都很着急，公交師傅會着急讓你上車下車，快遞員會着急讓你立刻簽單，聽到最多的一句就是「趕忙啦」。

工做上 （感觸）
　　感觸一：專一眼前，跌代更新
　　　　當什麼都想作的時候，團隊會很容易失去重心，不少事情會作的很差。
　　　　Scrum: 不要同時忙於多個user stories，請先專一於把當前user story完成後再去觀注下一個user story，一條小河兩條船並進比四條船擠來擠去要快。
　　　　Agile: 先專一眼前，沒有關係的，產品是跌代出來的，固然架構仍是要有的。

　　感觸二：持續學習，持續進步
　　　　客戶公司開發組小於30歲的應該少於1%，在國內應該會不多見，但他們始終保持着對新技術的關注，跌代升級開發框架。

　　感觸三：文檔化
　　　　對於公司來講，一個文檔化的平臺能夠減小人員變更帶來的風險，好比討論issue相關問題，那就在issue頁面上討論，這樣會給後面維護的人員帶來很大的便利，Email/MSN/Skype/QQ隨着人員變更容易丟失。
　　　　知識積累也相似，通常公司會有一些技術分享會或者新技術的探討，若是均可以文檔化那會對新進員工或者缺席員工帶來很大的幫助。

　　感觸四：多陪陪家人
　　　　要有本身的私人空間與時間，不要把本身的全部時間都放在工做與代碼上，多陪陪家人，放假就好好放假，把工做郵箱設置成自動回覆。
　　　　應該把加班當成不正常現象，而不是正常現象，加班應該是很糟糕的事情，但感受不少博友把這個當成是正面的東西，讓我很難以想象，固然你下班回家去學習一些新技術那是另一回事，慶幸咱們公司這個問題比較小。

工做上（新名詞）
　　這一年接觸的新東西太多了，下面總結下我以爲比較有價值的東西，可能對於一些朋友來講已經不新了

　　Scrum, Agile
　　　　天天早上的站立會（15分鐘左右，回顧昨天，打算今天）
　　　　　　站立會讓團隊成員工做更緊密，可讓項目經理了解團隊進度及時調整工做安排。

　　　　每週一關於這個禮拜的規劃會議（1到2小時，討論user story與估分，最終的分值其實並無那麼重要，重要的是讓團隊成員間打成共識，更加了解user story）

　　　　每週五的回顧會議（1個小時）
　　　　　　回顧過去才能更好的展望將來，這個禮拜作的不足的地方，團隊成員達成共識，選取最多人提到的兩點不足來改進，由於人的精力有限，當什麼都想改進的時候可能就會什麼都沒改爲功。

　　　　Team Board
　　　　　　爲了讓任務清晰可見，咱們引入了Team Board（白板）
　　　　　　1. TD (Technical Design)
　　　　　　2. TEST BASE (開發人員與QA對user story達成共識，QA輸出測試用例) 
　　　　　　3. DEV（開發中） 
　　　　　　4. CODE REVIEW（開發人員之間互相review代碼，結對編程可省去code Review）
　　　　　　5. TESTING (測試中) 
　　　　　　6. PO REVIEW （產品經理review） 　　
　　　　　　7. SHIP TO TRUNK (合併到主分支) 
　　　　　　8. ACCEPTANCE
　　　　　　9. DONE

　　　　　　（在博友曹宗穎《敏捷中的溝通與故事點》的文章中我有更詳細的評論，若是有興趣的朋友能夠看看 http://www.cnblogs.com/czy/p/agile_communication_story.html）

　　TDD，jMeter, Selenium, TFS
　　　　之前作的項目週期通常較短，因此不多會去寫單元測試，這一年都專一在 API 開發上，因此就須要單元測試來保證原有功能在持續跌迭的開發過程當中始終保持正常，若是多團隊基於同一個代碼庫單元測試的做用就更加明顯，由於會常常出現其它團隊修改了相關代碼，影響了你的功能，單元測試是第一道防線。雖然尚未真正測試先行，但這一年也一直保持着測試後行，項目單元測試覆蓋率也始終保持在90%以上，對待單元測試的觀念也發生了微妙的變化。

　　　　單元測試始終是代碼級別的，jMeter是一個很好的API測試工具，由於它關注在API request 與 API response，能夠靈活的Follow request，構成了咱們的第二道防線。
　　　　Selenium專一於UI層面的測試，也就構成了咱們的第三道防線。

　　　　單元測試 + jMeter + Selenium都經過 > TFS build綠了，那恭喜你了，發佈到LIVE吧。

　　DDD
　　　　項目業務邏輯複雜，須要不少領域知識，多虧了DDD，domain看起來很直觀，不過IRootAggregate<>在後期的維護中容易被濫用，好比碰到要查詢非RootAggregate實體的時候有時會出現直接給domain加個IRootAggregate<>接口而後用上repository。

　　 TFS, GIT
　　　　 Trunk branch (主分支)
　 　　　　   Team1 Main branch (Automated build-deploy to Team1 DEV server)
　　　　　　　　 Team1 Feature1 branch (Local)
　　　　　　　　　 Team1 Feature2 branch (Local)
　　　　　　 Team2 Main branch (Automated build-deploy to Team2 DEV server)
　　　　　　　　　 Team2 Feature1 branch (Local)
　　　　　　　　　 Team2 Feature2 branch (Local)

　　　　這是咱們使用的TFS分支結構，有個缺點就是QA想要測試Team1 Feature1，他必須切換到Team1 Feature1 branch而後本地運行程序，給QA帶來了很大的困擾。若是合併到Team1 Main branch部署到DEV server測試，那若是發現BUG就會Block其它Feature合併到主分支。
　　　　GIT的分支結構與TFS不一樣，並不是樹狀結構，因此能夠很靈活的繞過這個問題，咱們已經在其它項目中使用了 :)

　　Visual Studio database project, Liquibase
　　　　多人協做開發基於同一個數據庫衝突在所不免，好比開發人員A 在 Team1 Feature1 branch上修改了數據庫結構和代碼，開發人員B 在 Team1 Feature2 branch上開發其它功能時就會容易碰到異常。
　　　　如何避免這種問題呢？咱們可使用 Visual Studio database project 來維護數據庫結構的變動，而後開發人員可使用 local database 進行開發，若是你須要一些更高級的功能，好比Tag, Version，Rollback那你能夠考慮使用Liquibase但須要學習Liquibase的語法。

　　Web API + HAL JSON
　　　　發現園中大佬 Artech (http://www.cnblogs.com/artech) 在寫相關的技術文章，博友有福了 :)

　　　　應該說Web API的使用上咱們並無碰到比較麻煩的事情，但在跨域問題上咱們仍是發了一些力氣，IE, Chrome, Firefox, iPhone (xx), iPad (xx), iPad mimi (xx), Android (xx) 更種行爲你懂的。
　　　　好比：IE在跨域的狀況下沒法獲取4xx, 5xx狀態下的response，Android 和 IOS 5在跨域的狀況下沒法支持 302 / 301 重定向。

　　　　HAL JSON標準的理解與實現上咱們也發了一些力氣，但實現出來的API對前臺開發人員更友好易用，適合複雜度較高的API，API間互相聯繫而再也不是孤立的個體，API已經能夠自描述了。

　　Logging
　　　　之前經歷過的項目複雜度較低，只是log程序異常而已，也沒有碰到什麼大問題。
　　　　但當業務邏輯複雜度較高時沒有詳細的log信息，debug難度可想而知，每次都須要翻閱代碼才能定位問題可不是好主意。

　　　　你能夠想象下：
　　　　　　當用戶在LIVE上作了一系列操做，而後打電話過來告訴你，爲何個人支付頁面打不開，而後你和QA努力嘗試重現，但每次均可以正常打開支付頁面是件多麼鬱悶的事情。
　　　　　　你會開始懷疑用戶，懷疑人生，而後用戶爲了證實本身的清白，截圖給你看，確實是個自定義錯誤頁面，裏面顯示你的頁面出錯了，而後你翻遍log去尋找異常信息，卻得不到足夠的信息重現問題，詢問用戶如何重現，最後用戶本身也重現不出來了，說本身可能點了這個，而後填寫了那個，blabla 而後就掛了。而後就不了了之了，等待下次再被投訴或者流失用戶。

　　　　當你遇到過以上情形時，那恭喜你，你碰到了一個好用戶，正常狀況下是運維人員在LIVE上看到了異常，直接讓你研究去，若是你能夠在異常log記錄中找到用戶惟一識別，而後關聯出該用戶的全部操做記錄，這是一件多麼酷的事情，那運維人員也能夠從log中看出一點端倪。

　　BI
　　　　若是你有了以上完善的log，你會發現，你能夠識別出用戶了，你記錄了用戶的各類操做，是否是能夠分析一下用戶行爲了呢？作些統計分析了呢？
　　　　若是你對新開發的功能或者頁面在生產環境上的表現狀況一無所知，那這是一件多麼沮喪的事情。

　　Settings
　　　　若是你的公司擁有多個子公司，或者你的公司擁有多國站點，而後你的程序中遍及if else，或者大家能夠考慮獨立的配置系統，你能夠設置默認值，而後在子公司級別或者其它語言級別去覆蓋默認值。
　　　　配置系統在不一樣項目間的複用度仍是很是高的。

　　Rules
　　　　我見過不少電子商務系統一直努力的往他們已經很複雜的產品編輯頁面繼續添加新的checkbox，是否顯示A，是否顯示B，是否顯示C，而後點開一個checkbox又會展開一堆的textbox或者dropdown讓你填，我只是想加個簡單的產品而已，不要這麼折磨我吧。
這些checkbox能夠獨立出去嗎，由於我商店的1000個產品中只有10個產品會碰到這種需求，若是這些checkbox看起來更像規則，而不像產品自己的通用功能，那咱們是否能夠獨立出去不放在產品編輯頁面？


2014年我會繼續努力，2014年你呢？加入咱們吧 http://www.kooboo.com/ 咱們有阿不，咱們有JS神人ppchen，咱們有各路英雄好傑，咱們在美麗的廈門 :)