現代軟體工程 第四章 【結對程式設計】練習與讨論

         地鐵導航和周遊

在現代軟體工程教學的過程中，同學們已經總結了不少切身體會。例如:

總結1[i]：

那是project到了比較關鍵的創造階段，整整一天，我們倆椅子靠椅子的坐在電腦前，一邊讨論一般coding，那次才真正的體會到結對真的能夠帶來效率。一整天的coding是容易走神的事，還好有pair在旁邊指導，總是不斷在我敲某某變量之前提前告訴我成員變量的名字，資料修改時幫忙檢查是否有漏掉的，變量和函數定義的時候一起為其取名字，感覺有點眼花了，就換了個角色，我也開始對他“指指點點”了，一個人coding，一個人review，确實能減少一些不必要的錯誤，減少一些漏洞，算法實作後一起做些簡單的測試，看到bug了再一起分析，我能明顯的感覺到與以前的個人程式設計不一樣，我們能比較快的找到bug初始點，并能提出比較的修改方法。特别是當看到功能進一步實作時，心裡确實挺happy，更重要的這份感受有同伴與你一起分享。

總結2[ii]：

于是我們進行了項目中最關鍵的一次Pair Programming，我們利用編譯課上機時間，在機房裡Pair完成了整個項目的類的設計與程式結構的設計。我們一起分析出類，然後找屬性，寫方法頭，開始是WG用鍵盤，後來我用。一個明顯的好處是，寫完一條自己不确定的語句，馬上可以跟Pair一起縷一縷思路。一下午下來，感覺甚為清爽，因為終于清楚這個項目的做法了。

學術界、工業界對結對程式設計已經有不少研究，請閱讀至少兩篇相關論文或論文[iii]。

人和人不一樣，在和别人合作的時候，要注意各人表達觀點的方式和思考的方式不盡相同。請看網上關于MBTI的文章[iv]，測試并分享各自的MBTI類型，讨論不同性格類型對合作有多大的影響， 在合作的各個階段應該如何應對[v]。

對于是否需要有代碼規範[vi]，請考慮下列論點并反駁/支援:

這些規範都是官僚制度下産生的浪費大家的程式設計時間、影響人們開發效率, 浪費時間的東西。

我是個藝術家，手藝人，我有自己的規範和原則。

規範不能強求一律，應該允許很多例外。

我擅長制定編碼規範，你們聽我的就好了。

代碼複審檢查表： http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/ 

小飛： 哇，這麼多酷的C++ 功能都不能用，那我們還學什麼C++，為了迎接考試，我都把Operator Overload、Polymorphism背得滾瓜爛熟了，為什麼不讓我用？

阿超： 我們寫程式是為了解決問題，不是“為賦新詞強說愁”，這些進階的語言特性，不是不讓用，而是要用得慎重，不要動不動就寫三五個類，一個套一個，要把注意力集中在能否用簡潔的方法解決問題上來。

小飛： 這麼多規範，我不知道怎麼寫第一行程式了。

阿超： 自我複審也很重要——把代碼擺在面前，當作是别的菜鳥寫的。把你通常問别人的，以及别人會問你的問題都自己問一遍。這樣就能發現不少問題。

小飛： 如果開發者很厲害，那麼複審者就沒有什麼作用，也許這些複審都是走過場？

阿超： 同理可以推論，如果開發者很厲害，那麼測試人員也沒什麼作用，也是走過場，幹脆把他們送回家得了。我們敢這樣做麼?

小飛： 這些規範啊, 建議啊, 都是細枝末節的東西, 我們要做世界級的軟體，搞這些東西是不是太小家子氣了?

阿超： 首先世界級的軟體也會因為小小的纰漏而導緻世界級的問題。例如我們常常聽到的安全漏洞和緊急更新檔。其次，軟體的開發是一個社會性的活動, 有它的規律。其中一個規律就是“破窗效應”（broken windows theory）[vii] ，如果團隊成員看到同伴們連一些細小的規範都不遵守，那自己還要嚴格執行單元測試麼？另一個成員看到這個子產品連單元測試都沒有，那他自己也随意修改算了。這樣下去，整個軟體的量可想而知。

4.7.5 閱讀别人的代碼有多難?

    我們經常抱怨閱讀别人的代碼很難， 我們自己在寫代碼的時候，是否考慮到如何讓代碼更易于閱讀和維護呢?

别人的代碼：

來源: http://dhruba.name/2012/08/21/do-you-hate-reading-other-peoples-code/ 

http://kb.cnblogs.com/page/192086/

4.7.6  結對程式設計中不好的習慣 - 你經曆過麼?

　　喜歡發号施令的人總是對敲鍵盤的人說：“到末行，加個反括号，然後…”。他不去關注解決方法和下一步該怎麼做，而過度關注一些程式設計細節。

　　拼寫糾錯者坐在你旁邊，糾正你輸入的每個錯誤字元。當然，他沒有時間來真正的進行導航。

　　深藏不露者僅僅自己敲着代碼而不告訴别人他在做什麼。領航員不得不靠自己去弄懂代碼。關于該用什麼方法，該選擇哪種設計，領航員和實施者之間完全沒有交流。

　　跳躍很大的人喜歡在代碼中進行大範圍的跳躍，這樣領航員不知道進行到哪裡了。

4.7.7  對合作夥伴的評價

（這個作業在學期結束的時候做）

經過一個學期的各種項目，你（一個學生）和至少6-7 個同學深入地合作過。  你一定會對大家的合作精神有切身體會。 我們來做一個統計：

每個學生在期末填寫一個一維的表格 （沒有并列），  像下面這樣， 把你的小夥伴的合作精神由高到底列出來：

學生甲

學生乙

。。。

你自己（标明自己的名字）

學生丙

學生丁

最後老師會統計出來，整個學生集合中，誰的合作精神比較好，誰比較不好 （在同伴的眼裡）。 計分方法是：“你自己” 得 0 分；  在 “你自己” 之上一格的同學得一分； 在“你自己” 之上兩格的同學得兩分，以此類推。。。  在“你自己” 之下的同學依次得 -1，-2， -3， ... 分。

[i]      參見：http://www.cnblogs.com/ustc_msra_ase/archive/2010/11/28/1890424.html

[ii]      參見：http://www.cnblogs.com/xinz/archive/2010/11/27/1889978.html

[iii]     參見：http://c2.com/cgi/wiki?PairProgrammingCaseStudy 以及 http://www.thefreelibrary.com/Case+study%3a+using+pair+programming+in+development+of+a+complex+module.-a0246014267 以及 http://www.cs.utexas.edu/users/mckinley/305j/pair-hcs-2006.pdf

其它論文：

    Williams, Laurie, Robert Kessler, Ward Cunningham, and Ron Jeffries. 2000. “Strengthening the Case for Pair Programming.” IEEE Software 17, no. 4.

[iv]     請看： http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator

[v]     另外請參見 《對性格内向者的10個誤解》: http://blog.jobbole.com/12488/

[vi]     參見：http://www.vaikan.com/the-conventions-we-follow/   

http://www.aqee.net/things-everyone-should-do-code-review/

http://scientopia.org/blogs/goodmath/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/ 

[vii]     參見：http://en.wikipedia.org/wiki/Broken_windows_theory