對乙個同事專案的思考和總結

這幾天，跟旁邊專案組的同事聊天，下班的時候也一起聊些專案上的事。通過他的描述和我看到的一些情況。確實發現不少問題的。首先就是上線成功率不高。很少有一次發布成功的情況。大部分都是發布之後，出現各種問題，又得改bug

重發。開發和測試流程不規範，開發人員很隨意。然後就是各種技術風險。

發布質量不高每次發布都跟打仗一樣，每次上線發布，都要一兩個小時，作為乙個公司內部的web

系統，一次小版本的更新，發布時間都要在

1個小時以上，就足以說明很多問題。

發布質量不高

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

，然後上線。

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

流程不規範

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

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

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

團隊分工不明確

這個專案可以分為api

和web

**兩部分。但是開發人員對其定義不明確，職責也不明確。出了問題，所有開發人員都去猜測問題可能會出現在那塊，所有的人都從前端測試到後台，做了很多無用功。如果分工明確，那麼

api

的去檢查

api是否有問題，

web**的開發人員去檢查**前端。這樣就能快速定位並解決問題。

技術風險

由於這個專案用到了mysql

，entityframework這以前沒用過的東西，導致存在很多技術風險。比如mysql

所有的開發人員都是只知道一般的使用，沒有乙個對

mysql

了解比較深的人，entityframework 也是如此。出現了效能問題，很多時候不知道該如何優化。

思考

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

2. 優化開發流程，倡導**規範，修改**之前，確保沒有其他地方使用到，團隊對於哪類檔案該提交哪類檔案不該提交要達成共識。

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

4. 消除技術風險，技術問題，交由專門負責人員解決，mysql

和entityframework 這類交由專人負責並掌握。消除這類技術風險。