相關文章

如果要了解交換程式設計，可以先看看下面的幾篇關聯文章，這樣才能更有助於理解本文中的一些內容：

[技術討論]結對程式設計與交換程式設計的對話：http://blog.csdn.net/qingrun/archive/2006/12/07/1433588.aspx

交換程式設計csdn官方blog釋出了網路版本：http://blog.csdn.net/programmer_editor/archive/2006/12/07/1433092.aspx

[技術討論]關於結對程式設計實踐的一段對話：http://blog.csdn.net/qingrun/archive/2006/12/10/1437443.aspx

[團隊管理]結對程式設計引出的話題——企業管理與程式設計師規劃的對話（修改總結稿）：http://blog.csdn.net/qingrun/archive/2006/12/12/1440190.aspx

[技術討論]關於交換程式設計實踐的交換週期問題 ：http://blog.csdn.net/qingrun/archive/2006/12/20/1450091.aspx

老兄弟老問題

昨天在成都見到了以前一起工作的弟兄，他現在還在原來的單位工作，還在做原來的專案，我聽說了原來那個公司的最新情況，感覺：他們終於熬出來了。

期間，他就提到他們目前有一個問題，每個人負責一個大的模組從頭到尾，結果每個人的模組自成體系，在檢查錯誤與測試的時候遇到了很多問題，主要是因為每個人的自查起不到效果，同時由於每個人做自己的模組都已經有四年之久了，這樣的結果使得每個人都對自己開發的程式碼有相當高的認可程度，因此在進行新版本開發的時候，就很難進行調整和人員間的協調，當然還有因此產生的一些關聯問題。

這個專案的背景在交換程式設計那篇文章中作過簡單的介紹，目前這個專案已經進入了第四期，可是同樣這個第四期，還是處在MIS系統階段，始終沒有突破我04年那篇規劃中提到的第二階段：專家系統。

由於最高領導有了變更，所以，我甚至有了想幫助他們完成這個專案後續進展的考慮，當然，這個考慮目前對我來說，還只是一廂情願。

好了，廢話少說，我繼續前面的問題。

當聽到這裡，我就問他，是否還記得當年做完需求後，我給大家提到的要求進行輪流交換開發的事情，他說他有印象，但是，不明白為什麼。

於是，我給他講了一下交換程式設計這樣做的好處，這樣做，正好可以解決他們目前遇到的那個問題。

其他朋友的疑問

說道這裡應該提一下另外有一個朋友的疑問（這個朋友的疑問是寫在程式設計師雜誌blog上的內容，我在這裡做一個回覆）：

“

關於交換程式設計，我也考慮過很多，在很久以前想想結對程式設計的時候，就考慮過，感覺上交換程式設計有一些問題不好解決： 1：每個人都要理解上一個人的思想，思路，這樣的時間應該是比較耗費的， 2：每個人都有一定的思維慣式，交換的時候，缺少一個人在身邊，這樣很有可能這個人把上一個人的思維更改成自己的思維模式（比如文件，程式碼），這樣很有可能給後面的人和原作者帶來一定的困擾。 3：接手的人，是否會為上一人擦屁股，如果上一個人寫的比較差的話，那麼接手之後，如果接手得人沒有責任心的話，那麼可能就會讓差的程式碼越發的差，這樣可能發生程式碼腐爛的問題。我覺得人總是受環境的影響比較大，特別是一些沒有特殊潔癖得人，比如一段程式碼寫了註釋，那麼後來得人，可能接著寫，如果前面的人就馬馬虎虎，湊合的話，那麼後面的人會更湊合，就像Tom Demarco的那本《程式設計師修煉之道》中說得救火隊員去救火的那個故事一樣，如果屋子乾淨的話，隊員都要撲上墊子，才敢進去救火。 當然了，如果上面的全部反過來的話，這個就是一個比較好的實踐了：）

”

這裡我一個一個回答：

1、關於理解前一個人思路的問題，這裡應該根據工程專案情況和團隊組織以及人員變動情況進行綜合考慮，如果一個人在公司的時候，你都無法理解這個人的思路，那麼當這個人因為某種原因離開公司後，你還能讓原來的模組繼續下去麼？

這裡一個潛在的問題就在於這個公司這個團隊在專案開發過程中是否有一個整體的規劃和考慮，如果完全是一盤散沙的合作，那麼，交換程式設計也比單人程式設計更有優勢，畢竟，你進行交換的時候，大家都還在公司內，如果離開了，豈不是更是斷層了？

這個時間的耗費是否值得，我相信每個人都能衡量得出來。而另一方面考慮，如果一個人所寫的東西無法被第二個人所理解，那麼這個人的工作，豈不是沒有任何價值了？那你要這個人來做事，明擺著是把自己放在了即將噴發的火山口上！

2、這個問題同樣也是交接的問題，另外就是整個團隊是否具有整體性，大家做的東西是各自為戰，還是有一個相對統一的規劃考慮。最基本的規劃考慮是必然要存在的，否則，這個團隊也就不是團隊，這個專案也不可能成功。

另外，每一個人給第二個人講解自己想法的時候，其實也是主動地對自己的開發過程和思路進行了一次完整的review（重新評價），講得過程中就會讓他自己想到一些自己沒有考慮成熟的電荷一些還有疑慮的問題，通過這種交流，就可以將這些問題擴大化，擺出來，讓所有的人都看到，這樣才能及時地解決，否則，這些問題就會隱藏起來，直到專案結束的時候再被發現，那時候，就不是坐在火山口上了，而是直接調進了熔岩裡。

3、這個問題我個人認為，是不需要討論的。因為如果經過這樣的交接，專案領導者也會發現第一個人是否是在做事情，是否稱職，如果說第二個人就是在給第一個人擦屁股，那麼，第一個人是否應該存在在這個團隊中，他存在是否有價值，這就是管理者應該考慮的直接問題。

同樣，這種擦屁股，也會把隱藏起來的未知的問題顯性化，讓大家都看到每一個人所做的事情的價值，對於評定程式設計師的工作量和工作質量無疑是有好處的，而且具有現實意義（現實意義就是說不是單純的指導意義，而是可以直接付諸實施的措施）。

我相信經過上面的解釋，應該可以說明交換程式設計的作用了，這其實也是把同行評審工作直接放入到開發過程中來進行，將那些可能流於形式的同行評審變成了現實中的開發實踐。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/257598/viewspace-165680/，如需轉載，請註明出處，否則將追究法律責任。