互連網公司如何有效執行流程的心得

互連網公司如何有效執行流程的心得

    職業生涯的前六年都是在軟體公司做的，那時候流程再多，規範再嚴格，都有時間和空間來執行。最近幾年在互連網公司工作也做相應的推行時，對於一些原來在軟體公司一直使用的相對嚴格的規範和流程在執行過程中遇到非常多的問題。
遇到情況基本有幾種：
1、更新比應用軟體頻繁。市場在變，客戶在變，需求自然也在變，如果我們不變，就會被市場淘汰。原來做應用軟體的時候，最多一周甚至一個月更新一次軟體版本，客戶已經很滿意了，現線上上的東西，使用者發現了BUG或體驗不好的地方，一天都等不到，投訴量急劇上升，領導和PD會一直催著你解決問題；

2、線下測試環境往往和線上生產環境很難做到一致。尤其是解決跨域訪問或一些需要和其他網站合作進行使用者驗證的功能，線上下幾乎無法進行測試；

3、一個網站的功能數量往往可以和一個大型的應用軟體相比。每一塊都有相應的產品經理在最佳化推進，每一塊都有多個技術人員進行開發，但是發布時只允許一個包上線。當多個分支同時進行，需要在相同的時間點上線，合并分支分成為開發人員的惡夢；

4、更新過快導致無法保持模型與代碼的統一，代碼缺少清晰的注釋和說明（根本來不急寫），代碼執行效能較差；

5、分工過於細，程式員已經不清楚線上系統部署情況和伺服器負載能力，寫出來的代碼安全性和可擴充性差。

    面對這些問題，如果執行流程會更混亂，只有改造流程才能讓工作更有序。目前對這些問題有一些解決辦法和大家分享一下：
1、控制需求數量。雖然使用者和產品經理（PD）會有很多需求讓技術人員來解決，但並不一定要馬上解決所有的問題。
   首先，要區分事務的優先順序。一般我們現在是以系統異常第一，BUG第二，功能需求第三的順序在執行。
         為什麼系統異常排第一，是因為它會讓應用伺服器的效能急劇下降，甚至在沒有多大流量的情況下直接當機，所以一定要優先解決。而經過測試的代碼，最低要求也是沒有異常才允許上線發布。
   當然，功能也有高優先的，所以必須和客戶、產品經理坐下來討論哪些是第一時間要解決的，哪些是次要的。學習過時間管理的同學應該知道，優先順序的劃分是：緊急，重要，不緊急，不重要這四類。
   緊急的固然是要馬上解決的，但是重要的事務也是需要好好討論的，比如效能最佳化，雖然現在的頁面開啟速度也能接受，但是如果不做更進一步的最佳化而頁面上的功能越來越多，效能問題就會變成緊急的事務。一般來說，如果我們的精力90%放在解決重要的事務上，那麼緊急的事務也就只有10%了。
 
   其次，是控制發布次數。天天發布會讓主分支一片混亂，也會讓測試人員疲於奔命。我們現在一般是周二和周四晚上進行功能發布，這樣其他部門也會做好相應的配合。重要的項目和緊急的事務，可以進入緊急發布流程，但緊急發布流程不能常用，常用會讓業務部門覺得再小的東西也可以緊急發一下。

   再就是要有專業的SCM人員，管理分支和發布包，不要讓測試人員或開發人員兼職，這樣只會更亂。

   解決線上線下環境不一致的問題，除了線下會建立獨立的測試環境外，線上我們現在是用一台使用者無法正常訪問的伺服器進行部署，網域名稱是以.net結尾的（我們正式的網域名稱是.com），這樣也可以訪問進行一些測試，當然，也並不能完全解決問題，如果有更好的經驗，希望能和大家一起分享！：）

   規範是團隊協作的根本，沒有規範的代碼會讓其他同事無法正常理解或花費大量精力去理解你的代碼。再忙再緊，一周也要進行一次代碼檢查，把MODEL補充齊，把注釋和說明補充好。

   安全和效能是互連網公司的程式員必須關注的。團隊中應該有專門研究安全的同事，把安全條例做為天條進行執行。普通的代碼規範執行有問題可能請個下午茶就行了，但安全是不容解釋的，必須嚴格處理。效能也是一樣，不同的公司會有不同的配准。為了讓你的應用伺服器單台支撐百萬以上的流量，.aspx.CS裡的代碼必須在500毫秒內執行完。

以上是一些正在實行的經驗，環境是百人左右的技術團隊，其中還有很多不足，希望能給大家一些借鑒。