聯調的方式，形式上有點象結對程式設計，我是那個坐著旁邊「只說不作」的人，真正寫**的仍然是客戶端的人員，我主要負責幫客戶端人員理清他們的邏輯和思路，對現有的架構和**提出修改建議，同時「監督」客戶端人員的編碼過程，幫助其及時糾正由於思維「盲角」導致的小錯誤。這一兩個星期下來，感覺頗好，同事之間的合作既輕鬆也愉快，在效率上感覺要明顯比以前更快了。
在xp程式設計的相互協作中，有幾點感觸想說出來：
1. 不管是說的那個人，還是作的那個人，兩者都得要習慣這種程式設計方式，雖然從形式上看是兩個人用一台電腦在寫程式可能會造成公司的人力資源成本耗費，但從產品質量和工作效率上來看，這樣子寫出來的**在安全性和易維護性上都要比乙個人寫的要強得多。公司的開發成本，並不會因此而大大增加，相反，而是減少。有條件的專案組，可以試試。
3. 平等交流的原則。作為有時間積極思考的一方「坐在旁邊的那個人」，由於他並不擔負具體的編碼工作，所以他的思路可能相對於實施具體編碼的那個人要更為清晰一些，看的層面也要更深、更廣一些。當你的設計思路與編碼人員有衝突時，要本著互相尊重的原則平等交流，把你的設計思路盡可能地解釋清楚，盡可能客觀地分析彼此設計方案的優缺點，作出正常的評估。不要在思想上先入為主，片面否定對方，胸襟要開闊。
4. 知錯便改的良好修養。作為實施編碼的人員，從勞動量上來看，或許你的勞動量要比只說不作的那個人勞動量更大一點，或許你會時不時的抱怨對方提出的方案是「說起來輕巧，作起來難」，但只要對方說的是合理的，就要盡可能地去完善和修正，將來有一天你手頭上的事比較少時，你也同樣可以參與對方那個模組的結對程式設計，那時你也可以作乙個「只說不作的人」，所以，不必心理不平衡。^&^ 當對方對你的設計方案提出質疑時，你要客觀地想一想對方說得對不對，出於本能，你可能總是試圖說服對方自己的方案是對的，儘管你心裡可能已經在悄悄否定自己的設計方案了。如果你的內心有這種傾向，強烈建議你不要再死撐了，你應該及時糾正自己的缺點，將方案變得更完善和合理。有錯本身，並不是什麼大不了的，關鍵的是，知錯要改。最重要的是，同樣的錯誤，不要屢錯屢犯。
5. 設計風格是各人自己的事，不必強求。也許很多公司都有自己的所謂的編碼規範，但寫**的老鳥，基本上都會沿襲自己長久以來的編碼習慣，很少有人專門為了迎合公司的編碼規範而刻意去寫。只要**是易讀的，結構是清晰的，邏輯是正確的，我覺得各種設計風格是大家每個人自己的事，不必去強求。如果在這一點上都一定要釘是釘，鉚是鉚的話，可能會讓彼此都鬱悶得很。因為，你不能說哪種風格就是錯的，最多，你只能說哪種風格是更為易讀的和易維護的。結對程式設計的雙方，在編碼風格上，如果比較相近更好，如果相差比較大，那要看是不是滿足我上面說的三點「**是易讀的，結構是清晰的，邏輯是正確的」，如果滿足，就各安天命，你走你的陽光道，我過我的獨木橋，你不必強求我，我也不必強求於你。
總而言之，結對程式設計，在水平相差不是太大的二者之間進行實施的話，工作起來我覺得還是很快樂的，呵呵。願大家每個人每天都能以快樂的心情寫**！
初嚐結對程式設計的甜頭
聯調的方式，形式上有點象結對程式設計，我是那個坐著旁邊 只說不作 的人，真正寫 的仍然是客戶端的人員，我主要負責幫客戶端人員理清他們的邏輯和思路，對現有的架構和 提出修改建議，同時 監督 客戶端人員的編碼過程，幫助其及時糾正由於思維 盲角 導致的小錯誤。這一兩個星期下來，感覺頗好，同事之間的合作既輕...
結對程式設計的合作情況，以及結對程式設計的優缺點
我們合作的過程照 結對程式設計的優缺點 1 首先應該是結對程式設計的高效率了，結對程式設計的時候，兩個人可以分開做不同的unit，也可以同時做相同的unit。在專案的一些簡單的unit，乙個人能夠很簡單的unit就可以分給不同的人去做 對於核心的unit，比如說此次專案電梯排程的演算法部分，這是乙個...
結對程式設計，很好的程式設計方式
結對程式設計就是指兩位程式設計師使用同一臺電腦，進行程式設計。我認為這是乙個很好形式，這樣找兩個實力水平差不多的人在一起工作，稍差的人可以向優秀的人學習得以成長 而優秀的人會在不斷的表達中，形成自己的程式設計風格和思想 這樣都會得到成長，並且使得 質量得到大大的提高。結對程式設計，並且使得我們工作效...