本文是“松結對程式設計”系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之後文章請見欄目總目錄。）
團隊中常見的一種情況計劃、估算、設計的時候大家還在一起，但程式設計的時候就會分開。分開看似是安全的，但是卻充滿隐患。
2001年，一位招聘考試前三名（一共120員工）的程式員的兩個月的成果被徹底放棄重寫，原因是裡邊包含3000多個常數，而且很難修改（碼流參數），重寫的人座位距離他隻有4米，重寫也隻花費了2周；2002年，一位月薪7000（那時候北京房價才3000多）的程式員編寫了一個月的4000多行代碼，在一個下午被重寫為50多行，座位距離他隻有5米的項目經理疑惑加驚訝地問：“你真的沒學過c++ template？”。
這就是團隊的距離，即使是高薪聘請來的程式員也難免犯錯。難道我們隻能避免下一次問題發生，而不能避免這次問題發生？
-----------------------------------------
前檢查點
前檢查點就是在做某功能的最初一段時間，師傅與徒弟結對程式設計，完成最初最重要的設計。
“開始做X功能的時候叫我一聲，咱們敲定一下具體怎麼做。”這個是師傅的前檢查點标準文法。盡管在共同估算的時候大家還是略有共識，但是限于計劃會的有限時間，徒弟未必真的知道怎麼做。在剛開始的一兩個小時裡邊，師傅帶領徒弟一起把基本的結構理清楚，最好寫上一些基本代碼，讓徒弟有一個直覺的概念。
在上面提到的2周的重寫工作中，重寫者和被重寫者一起工作了1.5天，重新設計了打包類、遞歸函數等最難纏的部分；被重寫者在剩下的兩周裡邊完成了工作，而且很出色。倘若這一切發生在兩個月前該多好。那次事故之後，我們訂立了更嚴格的代碼審查制度，所有代碼均由部門技術最好的人審查後才進代碼庫；之後再來的新人，均指派師傅，并由師傅保證其代碼品質；将人員劃分為需指導的/免于指導的/可指導的/可教育訓練的四級（10年後我在NEC參觀交流時發現了幾乎完全相同的分級制度）。
前檢查點的工作作用是打下設計的基礎，保證工作順利進行。如果一切按照前檢查點的設計進行，徒弟可以繼續獨立工作，如果有偏離，要詢問師傅。
前檢查點的學習作用是顯而易見的，師傅平時工作的精華都展示在徒弟面前。而且這種展示是動态的，在結對程式設計的狀态下，徒弟可以完整地看到師傅是怎樣入手工作，怎樣思考，怎樣解決問題的。
後檢查點
後檢查點就是某事做完後，師傅檢查一下徒弟的結果，保證達到驗收标準。
曾經配置設定給我一個剛畢業半年的組員，剛來沒多久就經常看到他上網玩，過去一問，原來工作做完了（真的非常快），驚奇之餘趕緊看看結果：功能是有了而且實作得也很好，就是總有點瑕疵：要麼按鈕不正，要麼界面上有錯字。後來就改成每次任務完成都趕緊喊我去看看，修正後繼續下一個。他後來能力超群，在此公司作為“台柱子”10年，現在還在。
其實多數新人在大學中都形成了“能運作就行”的概念，并不懂商業軟體開發的标準。本人也一樣，畢業5年還不知道delete記憶體（C++），每次都是多預留點C槽空間，這樣程式就能多運作一段時間，下班之後關機重新開機就可以了……這樣的軟體肯定無法在伺服器上長期運作的。
在後檢查點，師傅可以提出改進要求，也可以當場改動。徒弟在此過程中會發現自己和師傅的差距，并是以而得到改進機會。
後檢查點的工作作用是可用來進行代碼審查，以確定軟體産品的品質，之後會提到。
後檢查點的學習作用是幫助新人學習商業軟體的開發标準，逐漸養成好的習慣。
日常工作
除了在任務前後的時間點外，日常8小時也應該保持良好的溝通。在一次極端的環境中，我們曾經将其發揮到極緻。
當時我們以很高的日薪臨時聘用了兩個不錯的程式員。他們技術雖然很好，但是卻對業務一無所知，也沒有提前看過文檔。因為總共也沒有多少天，當然不能把任何一分鐘花費在熟悉業務上，是以……
1. 每天早上（包括第一天）
整個軟體被大緻分為三類功能區，互相關聯。組長（我）也自己程式設計，負責其中一類功能。
有20分鐘的晨會，組長會把一個簡單的設計文檔的一部分拿出來講解給兩個人，同時指出今天要做的工作要給予其中的哪些内容，他們提問我回答。散會前我們會就每人的工作做一個簡單的估算（當年還不會撲克牌估算，太可惜了），確定當日是可以完成的。
晨會會提到技術問題，而不是每日立會中說的隻說進度。但技術問題一般隻涉及到要求，比如“做分段計價模型的時候，不要在C++裡邊做For循環，看能不能在SQL裡邊解決，如果解決不了來找我”“好，我試試。（或）這可能嗎？”凡是有問題的就會稍微深入一點；凡是“我試試”的，都放過，但如果試驗的結果不通就必須找組長讨論而不能自行解決。
小組加組長隻有3個人，是以所有人都參加這個20分鐘會，包括肯定不做某任務的人，也聽組長和别人的讨論。
2. 每天下午1：30點左右
就是吃飽飯犯困的時候，組長會分别和大家在計算機前碰頭一下，主要是看當日的工作是否可能在下班前完成（堅持不加班）；另外就是看是否和晨會上預想的一樣。
其實就算是短短的半天時間，事情就可能有變。有一次其中一個程式員在一上午寫了大約4螢幕的代碼（一般每天才寫這麼多），而功能卻遙遙無期。原來他不知道有個函數可以快速實作這些功能，正在自己造輪子，他本應該告訴組長所遇到的困難。
程式員很少在這個時候求助，他們總是相信自己能最終解決問題……是以在轉型為自組織團隊的時候，擔心程式員會偷懶的想法整體上是多餘的，更需要預防的是蠻幹/過于樂觀/激進/需求鍍金/消息閉塞/無法互相學習等問題。
3. 每天下午下班前
當時6點鐘有《七龍珠》（工作場所有台電視），兩位對此都很着迷，是以我們基本到點就看片，看完後散夥回家。
因為也不能讓電視台調整播出時間，基本上下午5點就要開始打掃戰場：組長分别找兩位，看最終結果是否完成，并做一下修改。同時還要做代碼審查（請看下一篇詳述）。
由于估算不會太準确，我們專門把所有三不管的小功能梳理出來，誰提前做完了，誰就找其中一個把剩下的閑工夫占上，結果其中一位幾乎包攬了全部。
4. 晚上
對，組長晚上還要工作。在他們走後組長會在晚上做個內建，把幾個人做的功能合成在一起運作。當時也沒有持續內建工具，是以隻能手工。
在正常項目的正常團隊中，這個工作應該在工作時間完成，也就是說或者找專人（或輪流），或者讓組長做，或者讓自動工具做最好。推薦小組内輪流負責此事，是以可以讓大家了解别人的工作、整體的工作，乃至與組外人員的內建工作等内容，為組員成長為組長打下基礎。
5. 随時
可能已經注意到我們沒有“每日立會”，一則當年還不知道Scrum，二則感覺一個3～5人的團隊還要靠開會交流實在迂腐。比如在篇首提到的兩次事故中，團隊都沒有少開會，但都因為缺少随時的溝通而導緻大錯。
其實任何伸伸懶腰的時間都可以進行溝通。不過一般不要“太随時”，應該以師傅的時間為主，也就是如果徒弟遇到了問題，但可以繞過去先走着，就先來一句“我這有問題，有空幫忙看看”+“好，再過15分鐘”。這樣既不會讓徒弟被卡住，也不會讓師傅因為經常被打斷而導緻無法工作。但師傅可以随時發起交流，因為他們是去幫助徒弟的，聊的也是徒弟的事情，不存在打擾的說法。
在多數情況下無論徒弟學得多好，小組的主要産出仍然可能一大半來自師傅。是以不能把師徒團隊變成一個簡單的學習團隊，而要通過保證師傅的時間，來保證其首先是一個工作團隊。
這個工作習慣一直保持到後來我管理一個市場/銷售/支援團隊的時候：我選擇坐在開放空間的最中央的一張大桌上（各部門經理也都在中央桌上而非獨立辦公室裡），如果有人有事來找，都會問：“有空麼？”答案是有空，或者某個時間之後。尤其是每天有10個以上不同的人會找你的時候，時間管理方法是很關鍵的。
注：上述部分内容僅限于特定環境中，但思路很多時候都是可取的。
-------------------------------------------------------
前檢查點的基本作用是保證後續工作有大緻的方向，而且徒弟能從師傅的設計過程中受益。
後檢查點的基本作用是保證完成的工作符合要求，而且徒弟能從師傅做出的改進中受益。
在日常工作中，師傅要經常過問徒弟的工作，但以保證自己的産出為前提。不能因為已經進行了共同設計和估算，或開了例會就放棄日常跟蹤，問題往往出在小處。
下一篇，将就代碼審查做一些探讨，也就是師傅怎麼幫助徒弟改進自己代碼的過程。
點選下載下傳免費的靈活開發教材：《火星人靈活開發手冊》
原文出自： http://blog.csdn.net/cheny_com/article/details/6590360
本文是“松結對程式設計”系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之後文章請見欄目總目錄。）
團隊中常見的一種情況計劃、估算、設計的時候大家還在一起，但程式設計的時候就會分開。分開看似是安全的，但是卻充滿隐患。
2001年，一位招聘考試前三名（一共120員工）的程式員的兩個月的成果被徹底放棄重寫，原因是裡邊包含3000多個常數，而且很難修改（碼流參數），重寫的人座位距離他隻有4米，重寫也隻花費了2周；2002年，一位月薪7000（那時候北京房價才3000多）的程式員編寫了一個月的4000多行代碼，在一個下午被重寫為50多行，座位距離他隻有5米的項目經理疑惑加驚訝地問：“你真的沒學過c++ template？”。
這就是團隊的距離，即使是高薪聘請來的程式員也難免犯錯。難道我們隻能避免下一次問題發生，而不能避免這次問題發生？
-----------------------------------------
前檢查點
前檢查點就是在做某功能的最初一段時間，師傅與徒弟結對程式設計，完成最初最重要的設計。
“開始做X功能的時候叫我一聲，咱們敲定一下具體怎麼做。”這個是師傅的前檢查點标準文法。盡管在共同估算的時候大家還是略有共識，但是限于計劃會的有限時間，徒弟未必真的知道怎麼做。在剛開始的一兩個小時裡邊，師傅帶領徒弟一起把基本的結構理清楚，最好寫上一些基本代碼，讓徒弟有一個直覺的概念。
在上面提到的2周的重寫工作中，重寫者和被重寫者一起工作了1.5天，重新設計了打包類、遞歸函數等最難纏的部分；被重寫者在剩下的兩周裡邊完成了工作，而且很出色。倘若這一切發生在兩個月前該多好。那次事故之後，我們訂立了更嚴格的代碼審查制度，所有代碼均由部門技術最好的人審查後才進代碼庫；之後再來的新人，均指派師傅，并由師傅保證其代碼品質；将人員劃分為需指導的/免于指導的/可指導的/可教育訓練的四級（10年後我在NEC參觀交流時發現了幾乎完全相同的分級制度）。
前檢查點的工作作用是打下設計的基礎，保證工作順利進行。如果一切按照前檢查點的設計進行，徒弟可以繼續獨立工作，如果有偏離，要詢問師傅。
前檢查點的學習作用是顯而易見的，師傅平時工作的精華都展示在徒弟面前。而且這種展示是動态的，在結對程式設計的狀态下，徒弟可以完整地看到師傅是怎樣入手工作，怎樣思考，怎樣解決問題的。
後檢查點
後檢查點就是某事做完後，師傅檢查一下徒弟的結果，保證達到驗收标準。
曾經配置設定給我一個剛畢業半年的組員，剛來沒多久就經常看到他上網玩，過去一問，原來工作做完了（真的非常快），驚奇之餘趕緊看看結果：功能是有了而且實作得也很好，就是總有點瑕疵：要麼按鈕不正，要麼界面上有錯字。後來就改成每次任務完成都趕緊喊我去看看，修正後繼續下一個。他後來能力超群，在此公司作為“台柱子”10年，現在還在。
其實多數新人在大學中都形成了“能運作就行”的概念，并不懂商業軟體開發的标準。本人也一樣，畢業5年還不知道delete記憶體（C++），每次都是多預留點C槽空間，這樣程式就能多運作一段時間，下班之後關機重新開機就可以了……這樣的軟體肯定無法在伺服器上長期運作的。
在後檢查點，師傅可以提出改進要求，也可以當場改動。徒弟在此過程中會發現自己和師傅的差距，并是以而得到改進機會。
後檢查點的工作作用是可用來進行代碼審查，以確定軟體産品的品質，之後會提到。
後檢查點的學習作用是幫助新人學習商業軟體的開發标準，逐漸養成好的習慣。
日常工作
除了在任務前後的時間點外，日常8小時也應該保持良好的溝通。在一次極端的環境中，我們曾經将其發揮到極緻。
當時我們以很高的日薪臨時聘用了兩個不錯的程式員。他們技術雖然很好，但是卻對業務一無所知，也沒有提前看過文檔。因為總共也沒有多少天，當然不能把任何一分鐘花費在熟悉業務上，是以……
1. 每天早上（包括第一天）
整個軟體被大緻分為三類功能區，互相關聯。組長（我）也自己程式設計，負責其中一類功能。
有20分鐘的晨會，組長會把一個簡單的設計文檔的一部分拿出來講解給兩個人，同時指出今天要做的工作要給予其中的哪些内容，他們提問我回答。散會前我們會就每人的工作做一個簡單的估算（當年還不會撲克牌估算，太可惜了），確定當日是可以完成的。
晨會會提到技術問題，而不是每日立會中說的隻說進度。但技術問題一般隻涉及到要求，比如“做分段計價模型的時候，不要在C++裡邊做For循環，看能不能在SQL裡邊解決，如果解決不了來找我”“好，我試試。（或）這可能嗎？”凡是有問題的就會稍微深入一點；凡是“我試試”的，都放過，但如果試驗的結果不通就必須找組長讨論而不能自行解決。
小組加組長隻有3個人，是以所有人都參加這個20分鐘會，包括肯定不做某任務的人，也聽組長和别人的讨論。
2. 每天下午1：30點左右
就是吃飽飯犯困的時候，組長會分别和大家在計算機前碰頭一下，主要是看當日的工作是否可能在下班前完成（堅持不加班）；另外就是看是否和晨會上預想的一樣。
其實就算是短短的半天時間，事情就可能有變。有一次其中一個程式員在一上午寫了大約4螢幕的代碼（一般每天才寫這麼多），而功能卻遙遙無期。原來他不知道有個函數可以快速實作這些功能，正在自己造輪子，他本應該告訴組長所遇到的困難。
程式員很少在這個時候求助，他們總是相信自己能最終解決問題……是以在轉型為自組織團隊的時候，擔心程式員會偷懶的想法整體上是多餘的，更需要預防的是蠻幹/過于樂觀/激進/需求鍍金/消息閉塞/無法互相學習等問題。
3. 每天下午下班前
當時6點鐘有《七龍珠》（工作場所有台電視），兩位對此都很着迷，是以我們基本到點就看片，看完後散夥回家。
因為也不能讓電視台調整播出時間，基本上下午5點就要開始打掃戰場：組長分别找兩位，看最終結果是否完成，并做一下修改。同時還要做代碼審查（請看下一篇詳述）。
由于估算不會太準确，我們專門把所有三不管的小功能梳理出來，誰提前做完了，誰就找其中一個把剩下的閑工夫占上，結果其中一位幾乎包攬了全部。
4. 晚上
對，組長晚上還要工作。在他們走後組長會在晚上做個內建，把幾個人做的功能合成在一起運作。當時也沒有持續內建工具，是以隻能手工。
在正常項目的正常團隊中，這個工作應該在工作時間完成，也就是說或者找專人（或輪流），或者讓組長做，或者讓自動工具做最好。推薦小組内輪流負責此事，是以可以讓大家了解别人的工作、整體的工作，乃至與組外人員的內建工作等内容，為組員成長為組長打下基礎。
5. 随時
可能已經注意到我們沒有“每日立會”，一則當年還不知道Scrum，二則感覺一個3～5人的團隊還要靠開會交流實在迂腐。比如在篇首提到的兩次事故中，團隊都沒有少開會，但都因為缺少随時的溝通而導緻大錯。
其實任何伸伸懶腰的時間都可以進行溝通。不過一般不要“太随時”，應該以師傅的時間為主，也就是如果徒弟遇到了問題，但可以繞過去先走着，就先來一句“我這有問題，有空幫忙看看”+“好，再過15分鐘”。這樣既不會讓徒弟被卡住，也不會讓師傅因為經常被打斷而導緻無法工作。但師傅可以随時發起交流，因為他們是去幫助徒弟的，聊的也是徒弟的事情，不存在打擾的說法。
在多數情況下無論徒弟學得多好，小組的主要産出仍然可能一大半來自師傅。是以不能把師徒團隊變成一個簡單的學習團隊，而要通過保證師傅的時間，來保證其首先是一個工作團隊。
這個工作習慣一直保持到後來我管理一個市場/銷售/支援團隊的時候：我選擇坐在開放空間的最中央的一張大桌上（各部門經理也都在中央桌上而非獨立辦公室裡），如果有人有事來找，都會問：“有空麼？”答案是有空，或者某個時間之後。尤其是每天有10個以上不同的人會找你的時候，時間管理方法是很關鍵的。
注：上述部分内容僅限于特定環境中，但思路很多時候都是可取的。
-------------------------------------------------------
前檢查點的基本作用是保證後續工作有大緻的方向，而且徒弟能從師傅的設計過程中受益。
後檢查點的基本作用是保證完成的工作符合要求，而且徒弟能從師傅做出的改進中受益。
在日常工作中，師傅要經常過問徒弟的工作，但以保證自己的産出為前提。不能因為已經進行了共同設計和估算，或開了例會就放棄日常跟蹤，問題往往出在小處。
下一篇，将就代碼審查做一些探讨，也就是師傅怎麼幫助徒弟改進自己代碼的過程。
點選下載下傳免費的靈活開發教材：《火星人靈活開發手冊》
原文出自： http://blog.csdn.net/cheny_com/article/details/6590360
![python算法之二分查找[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)