一晃眼，有兩年沒有寫博客了，回顧前兩年，各種奔波，各種忙碌，也有不少的收獲。從今天開始，我要把這些收獲都分享在這里。
其實這兩年，對我影響最大的是開發流程。總所周知，一個好的開發流程，對於項目的進行，更新和維護都起着至關重要的作用。Scrum適用於一些開發周期長，需求不明確，或者隨時間漸進明確，頻繁更新的項目。然而，現在國內的一些公司，甚至一些大公司，都對這塊不太重視，或者做得不夠透徹。從而程序猿們天天加班，苦不堪言。
我們先來看張我通過實際經驗畫的圖流程圖，紅色圈圈出來的是我認為比較容易忽略的部分，接下來一一說明。
1/2、項目決定啟動后，第一步就是產品組准備需求，整理出需求文檔。這個需求文檔是需要多次會議協商總結出的。在需求前期，產品組可以自由發揮，把對產品的任何要求盡量詳細地列出來，細節方面列不完整也沒關系，但是對於產品的最終呈現出的效果，大的方向，要有一個徹底明確的說明，因為這個可能直接關系到產品架構的設計；然后進入需求中期，這個時候一定要引入技術經理以及技術主力，需要從技術角度去評估需求的可行性以及性價比，這讓技術部門能夠基本了解大的架構方向，（我曾經就有碰到過一個項目，由於產品組在美國，開發組在國內，產品組在沒有和開發組徹底溝通的情況下，就把需求和客戶達成共識，這之后使得我們技術部門十分被動，結果就是無法在規定時間上線，損失是小，在客戶面前失信是大！）；最后在需求后期，就可以出具項目需求初稿，這個初稿需要產品組根據時間要求以及客戶要求，進行優先級划分，並將其划分為多個模塊，分配給各個開發經理，制定Story或者backlog，再讓開發經理細分task，分配給各個程序猿，從時間的角度，需要設定Sprint，並將各個story分配到各個Sprint中，一個Sprint的周期一般是2個星期（10個工作日），遇特殊情況可延長到3個星期。這個過程中，最關鍵的是怎么規划Sprint，這個時候，對story時間的估算是非常關鍵的。我們以前都是程序猿們和產品經理坐在一起，為每個story一一估算時間。比如說一個story由2個人完成，2個人當然需要在事先了解需求，然后在對方不知道的情況下，分別估算對這個2個人完成的story需要花費多少天/人次，如果兩個人時間接近，就去較大的那個天數作為估算的時間，比如一個人估3天，一個人估2天，那么這個story估算的總時間就是3天/人*2人=6天；如果兩個人的差距相當大，比如一個人估了2天，另外個人估了10天，那就有需要讓兩個人說明原因，在排除了干擾因素后，再次估算，最后得出一個合理的時間。項目經理需要根據估算的總時間來安排Sprint里的story。
這些都准備完成后，就可以進行項目開發階段了。
3、因為我是微軟平台的苦B程序猿，所以我接下來用到的都是微軟的工具。首先要有一個代碼版本控制軟件，我要在這里說的是TFS。微軟的TFS有兩個版本，一個叫Team Foundation Server，一個叫Team Foundation Service，小弟都用過，所以來說明下兩者的區別：Server版需要公司用自己的服務器部署，比較適合局域網內開發的項目，當然也可以部署在公網，優點是可以最大程度的customize；Service版是部署在微軟雲上，由微軟托管的，比較適合跨區域中小型公司（缺少硬件支持的），優點是方便，和office365賬號綁定，公網也可以訪問，缺點是無法自定義流程模板。其他功能都是一樣的。其實無論那個版本的TFS，功能都是非常強大的，完全可以滿足敏捷開發項目需要。我曾聽有人抱怨TFS只能給程序猿用，項目組又不裝VS，不用用它來開task啊，開bug什么的，然后又去買了JIRA什么的專門給項目組用的流程控制工具，其實沒必要，TFS有個service portal，類似於sharepoint的站點，可以用它來給項目組用，兩個版本都有，非常好用。當然JIRA也是非常不錯的，我們當時也是兩個一起用，JIRA在自定義流程上面還是相當不錯的，我們用JIRA來做部署流程控制以及運維流程控制等與代碼本身關聯不深的流程控制。
TFS在對代碼版本及質量管理方面是很有優勢的，我們會把sprint，story，task等等統統在開發階段開始前錄入TFS，這些都是TFS默認的模板，我們也可以自己更換或者修改模板，遺憾的是service版沒法改。具體怎么修改可以參考MSDN。
然后我們可以通過規則，強制在check in代碼的時候綁定task/bug/issue，以及強制寫comment以及check in notes，這些都相當重要。當然，代碼不能隨隨便便就能check in啊，最好需要有個人review，這個時候，我們可以先Shelve代碼，然后可以指定一個人來給你review代碼，review代碼的人可以通過TFS自帶的比較工具，比較shelve的代碼和最新的代碼間的區別，也可以給代碼片段寫comment，最后決定是否可以提交和需要打回去，重新shelve。有人會覺得，這個好麻煩啊，不是會影響進度。我要說的是，如果沒有這個環節，或許你可以很快速的完成開發，但別忘了，代碼不是寫完就算了的，代碼的質量也是相當重要的，誰都不想，項目進入測試環節因為某個不該發生的問題而影響一輪測試，也不想在項目上線之后，因為性能問題，再來review所有代碼，找到性能瓶頸......
順便說下測試，測試不比開發輕松，一般測試分為smoke test，regression test，fuzz test，load test/performance test，security test。前兩個不多說了，很熟悉了，后面三個很容易被忽視，但是卻非常重要。有一句真理：任何一個軟件，永遠都存在bug，任何一種測試都無法把所有bug都找出來！因此，我們需要在測試階段盡可能地將簡單明顯的bug統統找出來，這樣剩下的只是在特定情況下才會特別發生的bug。smoke test和regression test是為了找簡單明顯的bug，而fuzz，load，security等等測試是用來找出特定情況下的bug。fuzz能夠很好地驗證軟件的健壯成都，它通過隨機無序的任意輸入，測試系統的內部應對及輸出；load能夠讓系統在某個壓力下測試系統的穩定性能，從而評估該系統/軟件可以給多少人用，需要多少服務器，以及找出性能瓶頸，從而優化代碼；安全測試可以測試系統的安全性，關於安全微軟還有一套完整的流程叫SDL，就不詳述了。我們以前公司一直想做自動化測試，fuzz和load是可以自動化的，但是功能性測試做自動化比較困難，VS自身有針對web服務的自動化測試項目模板，有興趣可以了解下。但個人覺得還不算理想中那種自動化。反正有大批測試妹子，全自動化了，公司里不就少了很多妹子，哈哈，扯遠了。。。
再說下發布，在分布式的發布體系下，比較頭疼的是，從QA到UAT，在到Staging和Production，各個環境可能需要不同的配置參數，尤其是SOA的系統，在分布式部署的時候，服務地址的配置通常非常頭疼，最簡單的方法是用配置文件的自動轉換功能，也有公司自己做配置管理工具的，也有把配置移到數據庫的。個人覺得，有條件的可以自己開發套適合自己的配置工具，但是我作為一個從簡主義者，我針對SOA系統，我的方法是這樣的：首先，在每個環境的服務器集群之中，搞一台機器專門做內部的DNS服務器，我們在dns服務器上為每一個需要分布式部署的service定義一個內部域名，然后在配置文件中，都用這些預先定義好的內部域名，如果需要本地測試，可以修改自己機器的host文件，map到127.0.0.1或者具體的局域網IP地址，包括數據庫地址也是可以這么做（這種方法對Azure SQL無效），然后發布到任何一個環境都不需要改跟地址有關的配置；對於一些跟環境相關的其他應用程序配置，本人建議存儲到數據庫或者做一個專門的配置服務。當在Staging上發布並測試完成后，Production就不要再發布了，通過交換綁定的IP地址來實現切換，具體如何實現是IT的事情，這里不說了。
4、終於一個階段開發完成，可以順利進入測試階段了，這個時候，下個階段的新需求就又來了，然后又是重復的步驟，估時間，sprint，story，寫代碼，測試，發布。
5、當產品上線后，肯定會遇到不少特定情況出現的bug，為了發現bug，要有監控系統，這又是一個大話題，暫時略過，然后發現問題后，要能夠重現，然后需要評估問題的嚴重程度，然后根據協商結果，決定是否需要立馬修復，還是進入下個發布周期修復，如果是需要立馬修復的就要做hotfix，開maintainence window，走一邊UAT-〉Staging-〉Production的過程，QA可以不走，因為有可能下個階段的開發已經在QA上測試，如果下個階段的開發已經在UAT上了，那么這么急的hotfix也沒有意義了，如果下個階段已在UAT，prod又出現無法運行的后果，那么把production再切會之前的在staging上的版本吧。關於數據庫，staging和prod應該是需要工具來同步的。
先說那么多，很多細節還是需要不同的團隊不同的人員做一些調整。總結的不對之處，還望指正！