現代軟件工程第四章【結對編程】練習與討論

本文轉載自查看原文 2014-07-17 22:03 1683 結對編程/ 軟件工程

4.7.0 結對編程的練習題

4.7.1 結對項目的案例和論文

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

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

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

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

4.7.2 性格對合作的影響

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

4.7.3 是否需要有代碼規范

對於是否需要有代碼規范[vi]，請考慮下列論點並反駁/支持:

這些規范都是官僚制度下產生的浪費大家的編程時間、影響人們開發效率, 浪費時間的東西。
我是個藝術家，手藝人，我有自己的規范和原則。
規范不能強求一律，應該允許很多例外。
我擅長制定編碼規范，你們聽我的就好了。

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

4.7.4 代碼復審的討論

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

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

小飛：這么多規范，我不知道怎么寫第一行程序了。

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

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

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

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

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

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

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

別人的代碼：