怎麼樣才叫軟體團隊開發

標籤：http   os   使用   2014   問題   代碼   ad   時間   工作   

在我10多年的軟體開發中，經曆過超過200人的軟體Team Dev，也有過兩三個人開發的小團隊，但無論團隊的大小，都是採用一個很簡單的軟體開發方法：就是把項目切分成模組，然後每個人開發一塊，最後集合起來，調試完成，再經過測試，交給客戶使用，就算項目完成了。

在這期間，團隊成員之間沒有什麼交集，相互的代碼也沒有查看或者瞭解一下。因此，當某一個成員離職或者病休時，就會帶來很大的問題。因為其它人員都對他的工作不瞭解，不能接手他的工作，導致再開發下一個項目時，就會帶來高漲的成本，項目大大地增加延長開發的時間。

另外，由於成員相互之間沒有瞭解代碼，每個人的編寫代碼的風格也差異比較大，導致代碼比較難重用。這種團隊開發在目前看來，還在很多公司是存在的。那麼怎麼樣才可以改變這種現狀？也就是說怎麼樣才叫真正的軟體團隊開發呢？

由於軟體開發從個人開發變成團隊開發方式，在中國來說，也近來10多年的事情。在90年代都是個人開發就可以成功了，比如像金山軟體的求伯君，就可單兵一個，就可以完成DOS下面的WPS開發。

放在今天這樣的環境裡，軟體的規模已經非常大，一個人完成的軟體，只有在手機領域還有市場，在其它領域已經不太可能了。

因此，必須建立團隊開發為目標。

為了建立團隊的開發，就需要制定各種標準。比如編碼規範，有了這個標準之後，就可以讓所有團隊成員編寫出同一樣規範的代碼，可以減少相互交流的成本，同時也提高了代碼的品質。同時也可以讓成員看不出來誰寫的代碼，減少心理上抗拒。但是，是否制定了標準之後，就可以萬事大吉了呢？其實不然，由於每個開發人員都是人，是人就有著出錯，有著自己個性表現，以及個人的習慣。因而有了標準之後，就需要想著怎麼樣實踐了，以及讓標準成為管理辦法。

在以往的團隊，或者說一般的團隊裡，都是制訂標準之後，就發送給大家，就認為完事了。但在我看來，制訂標準只是軟體團隊開發的第一步，要落實標準還需要很多的工作需要做。

那麼在軟體Team Dev裡怎麼樣把這些標準落地，接上地氣呢？關鍵的一環是程式碼檢閱。從我經曆過的團隊，無論大小都沒有去實踐這個環節，但從國外的軟體Team Dev來看，沒有這個環節的，基本不存在。為什麼這個程式碼檢閱這麼重要呢？

首先代碼編寫出來之後，需要團隊查看之後，才可以認定這種代碼是否符合標準，不是讓開發人員認為符合了，就是符合了。

其次，程式碼檢閱是團隊開發的體現。如果每個人開發完成的代碼，就認為完成了，其實這份代碼，還是個人之作，不是團隊共同開發的，所以代碼的品質可能是低下的，出錯是難避免的，設計的方法是一般的。如果一個團隊把個人開發的代碼進行評審之後，並作出修改，那麼才可以說這份代碼是團隊開發的軟體。

再次，程式碼檢閱是經驗總結和相互學習提高團隊成員的關鍵。如果這份代碼是老員工開發出來的，意味著代碼是優秀的，那麼新來的成員就可以學習了，從這種例子裡學習到最好的代碼形式。如果這份代碼是新來員工開發的，那麼出錯，或者不符合規範的情況，就會發生，這時經過團隊成員裡優秀開發人員的指出，讓新員工可以認識到錯誤，就可以快速地改正，從而快速地向高水平的開發人員看齊。

最後，程式碼檢閱是提高軟體品質，降低開發成本的方法。因為通過一個團隊的眾多眼睛和多個大腦來看查看代碼之後，代碼品質都會顯著地提高，同時把自己開發沒有發現的錯誤，都會在其它人的眼睛裡一眼就看出來了。這有點像考試時，自己怎麼樣檢查都不會發現有錯誤，在另外一個人裡一查看就看出來了。降低開發成本是關鍵，由於不斷地通過程式碼檢閱，意味著這份代碼不再屬於開發人員一個人了，而屬於整個團隊了，大家都對代碼瞭解，從而都可以對代碼進行開發，避免開發人員離職，或者病假帶來的時間和金錢上損失。另外，在今天這種快速反覆式開發法的環境之下，保持軟體穩定發布，只能通過不斷評審代碼來確認軟體不出大BUG了。

總之，一個真正的軟體團隊的開發需要是這樣：團隊評審需求、團隊制訂標準、分別編寫代碼、團隊評審代碼。如果缺少最後這個評審代碼，這樣的開發不叫做團隊開發，還是跟個人開發是一樣的。

怎麼樣才叫軟體團隊開發