在我10多年的軟件開發中，經歷過超過200人的軟件開發團隊，也有過兩三個人開發的小團隊，但無論團隊的大小，都是採用一個很簡單的軟件開發方法，就是把項目切分成模塊，然後每個人開發一塊，最後集合起來，調試完成，再經過測試，交給客戶使用，就算項目完成了。在這其間，團隊成員之間，沒有什麼交集，相互的代碼也沒有查看，或者瞭解一下。因此，當某一個成員離職或者病休時，就會帶來很大的問題，因爲其它人員都對他的工作不瞭解，因而不能接手他的工作，導致再開發下一個項目時，就會帶來高漲的成本，項目大大地增加延長開發的時間。另外，由於成員相互之間沒有了解代碼，每個人的編寫代碼的風格也差異比較大，導致代碼比較難重用。這種團隊開發在目前看來，還在很多公司是存在的。那麼怎麼樣纔可以改變這種現狀？也就是說怎麼樣才叫真正的軟件團隊開發呢？
由於軟件開發從個人開發變成團隊開發方式，在中國來說，也近來10多年的事情。在90年代都是個人開發就可以成功了，比如像金山軟件的求伯君，就可單兵一個，就可以完成DOS下面的WPS開發。放在今天這樣的環境裏，軟件的規模已經非常大，一個人完成的軟件，只有在手機領域還有市場，在其它領域已經不太可能了。因此，必須建立團隊開發爲目標了。爲了建立團隊的開發，就需要制定各種標準。比如編碼規範，有了這個標準之後，就可以讓所有團隊成員編寫出同一樣規範的代碼，可以減少相互交流的成本，同時也提高了代碼的質量。同時也可以讓成員看不出來誰寫的代碼，減少心理上抗拒。但是，是否制定了標準之後，就可以萬事大吉了呢？其實不然，由於每個開發人員都是人，是人就有着出錯，有着自己個性表現，以及個人的習慣。因而有了標準之後，就需要想着怎麼樣實踐了，以及讓標準成爲行爲準則。
在以往的團隊，或者說一般的團隊裏，都是制訂標準之後，就發送給大家，就認爲完事了。但在我看來，制訂標準只是軟件團隊開發的第一步，要落實標準還需要很多的工作需要做。那麼在軟件開發團隊裏怎麼樣把這些標準落地，接上地氣呢？關鍵的一環是代碼評審。從我經歷過的團隊，無論大小都沒有去實踐這個環節，但從國外的軟件開發團隊來看，沒有這個環節的，基本沒有。爲什麼這個代碼評審這麼重要呢？首先代碼編寫出來之後，需要團隊查看之後，纔可以認定這種代碼是否符合標準，不是讓開發人員認爲符合了，就是符合了。其次，代碼評審是團隊開發的體現。如果每個人開發完成的代碼，就認爲完成了，其實這份代碼，還是個人之作，不是團隊共同開發的，所以代碼的質量可能是低下的，出錯是難避免的，設計的方法是一般的。如果一個團隊把個人開發的代碼進行評審之後，並作出修改，那麼纔可以說這份代碼是團隊開發的軟件。再次，代碼評審是經驗總結和相互學習提高團隊成員的關鍵。如果這份代碼是老員工開發出來的，意味着代碼是優秀的，那麼新來的成員就可以學習了，從這種例子裏學習到最好的代碼形式。如果這份代碼是新來員工開發的，那麼出錯，或者不符合規範的情況，就會發生，這時經過團隊成員裏優秀開發人員的指出，讓新員工可以認識到錯誤，就可以快速地改正，從而快速地向高水平的開發人員看齊。最後，代碼評審是提高軟件質量，降低開發成本的方法。因爲通過一個團隊的衆多眼睛和多個大腦來看查看代碼之後，代碼質量都會顯著地提高，同時把自己開發沒有發現的錯誤，都會在其它人的眼睛裏一眼就看出來了。這有點像考試時，自己怎麼樣檢查都不會發現有錯誤，在另外一個人裏一查看就看出來了。降低開發成本是關鍵，由於不斷地通過代碼評審，意味着這份代碼不再屬於開發人員一個人了，而屬於整個團隊了，大家都對代碼瞭解，從而都可以對代碼進行開發，避免開發人員離職，或者病假帶來的時間和金錢上損失。另外，在今天這種快速迭代開發的環境之下，保持軟件穩定發佈，只能通過不斷評審代碼來確認軟件不出大BUG了。
總之，一個真正的軟件團隊的開發需要是這樣：團隊評審需求、團隊制訂標準、分別編寫代碼、團隊評審代碼。如果缺少最後這個評審代碼，這樣的開發不叫做團隊開發，還是跟個人開發是一樣的。
