互聯網 - 大數據

　　這幾天，跟旁邊項目組的同事聊天，下班的時候也一起聊些項目上的事。通過他的描述和我看到的一些情況。確實發現不少問題的。首先就是上線成功率不高。很少有一次發布成功的情況。大部分都是發布之后，出現各種問題，又得改bug重發。開發和測試流程不規范，開發人員很隨意。然后就是各種技術風險。

　　發布質量不高每次發布都跟打仗一樣，每次上線發布，都要一兩個小時，作為一個公司內部的web系統，一次小版本的更新，發布時間都要在1個小時以上，就足以說明很多問題。

　　發布質量不高

　　1. 發布的質量不高，沒有進行系統的集成測試，每次都是開發人員測試通過之后，就完事了。沒有集成測試的過程，導致上線之后，本功能沒問題，但是影響到其他的功能。導致上線不成功，重新修改bug ，然后上線。

　　2. 發布人員沒有進行必要的冒煙測試，由于沒有專門的測試人員，發布和測試的人員都是開發人員進行的。所以，發布人員，沒有獲取完最新的代碼之后，沒有進行必要的冒煙測試之后，就直接發布。導致很多時候，發布之后，網站直接不可用。這類問題，應該上線之前的冒煙測試就要測試出來。

　　流程不規范

　　開發流程不規范。開發的時候，有很多隨意性，有些數據庫腳本，沒有在測試環境測試，直接就在生產環境中執行。或者本身腳本沒有問題，但是影響到其他功能。開發人員只關注自己的那一塊，沒注意到修改之后，對其他功能的影響。

　　測試流程部規范。只測試自己的部分功能，沒有經過集成測試，就直接發布，導致系統發布之后，出現各種未知的問題。

　　有些時候竟然出現發布完之后，開發人員還有代碼未遷入或是發布人員未獲取到開發人員所提交的代碼的情況。這類問題，必須要有規范的流程。

　　團隊分工不明確

　　這個項目可以分為api和web網站兩部分。但是開發人員對其定義不明確，職責也不明確。出了問題，所有開發人員都去猜測問題可能會出現在那塊，所有的人都從前端測試到后臺，做了很多無用功。如果分工明確，那么api 的去檢查api是否有問題，web網站的開發人員去檢查網站前端。這樣就能快速定位并解決問題。

　　技術風險

　　由于這個項目用到了mysql，EntityFramework這以前沒用過的東西，導致存在很多技術風險。比如mysql 所有的開發人員都是只知道一般的使用，沒有一個對mysql 了解比較深的人，EntityFramework 也是如此。出現了性能問題，很多時候不知道該如何優化。

　　思考

　　1. 明確分工和職責。項目分塊，專人負責。

　　2. 優化開發流程，倡導代碼規范，修改代碼之前，確保沒有其他地方使用到，團隊對于哪類文件該提交哪類文件不該提交要達成共識。

　　3. 優化測試流程，所有的功能，開發人員測試沒問題之后，才算完成，提交，一定要進行集成測試，發布之前開始要求提交代碼，并進行集成測試。所有的功能要在測試環境測試通過才能發布。測試人員發布的最終發布版本，要進行必要的冒煙測試。

　　4. 消除技術風險，技術問題，交由專門負責人員解決，mysql和EntityFramework 這類交由專人負責并掌握。消除這類技術風險。