第四章做業

1.結對項目的案例和論文。

http://c2.com/cgi/wiki?PairProgrammingCaseStudy

http://dwz.cn/1GOOvc

http://www.cs.utexas.edu/user/mckinley/305/pair-hcs-2006.pdf

2.性格對合做的影響

 

3.是否須要有代碼規範

1. 這些規範都是官僚制度下產生的浪費你們的編程時間、影響人們開發效率, 浪費時間的東西。

反駁。

官僚制度：按照職能和職位分工，分層管理原則創建起來的行政權力體系。

這些規範是前人總結出來的，你們默認的能夠看懂的代碼規範。對於常常編寫代碼的人使用這些代碼規範是方便的。在整個軟件團隊的工做環境中，它可以大幅度節約團隊編程所須要的時間，提升團隊的工做效率。也許代碼規範會讓剛接觸的使用者感到束手束腳，可是熟悉以後，在程序的可理解性上獲得的好處會大大的補償以前的損失。

2.我是個藝術家，手藝人，我有本身的規範和原則。

反駁

特立獨行對於開發者來講也許很合適，可是在軟件團隊的工做中，藝術家的行業道德並不合適。一我的的規範不叫規範，沒有哪一個人的我的規範和原則能夠凌駕於團隊規範與團隊原則之上。若是由於一我的的我的規範和原則致使團隊工做受到了嚴重的影響，那麼這樣的規範和原則不如沒有。

3.規範不能強求一概，應該容許不少例外。

反駁

規範應該儘可能一致，即便有例外，也只能是少數狀況，而不能是不少例外。我我的認爲例外多了，就不能叫作例外了。
4.我擅長制定編碼規範，大家聽個人就行了。

反駁

統一是有價值的，一個程序員永遠不可能獨自工做，在軟件團隊工做時代碼規範是必定要強調的，這是團隊積攢下來的經驗。在團隊工做中，徹底遵照代碼規範的收益是 下降閱讀代碼時候的溝通成本，可是在一個團隊適用的規範和原則在另外一個團隊不必定一樣適用。若是對現有的代碼規範和原則有意見，能夠經過必定方法修訂併發布新的規範。可是在新的規範發佈以前，遵照舊的規範，維護團隊利益。

5 、閱讀別人的代碼有多難

　　關於本身編寫代碼時，如何讓代碼更易於閱讀與維護。

概括：

1）、堅持使用一種命名模式

2）、不要隨意縮寫英文單詞

3）、使用斷言來記錄先決條件和後置條件

4）、C語言標準運行時庫的設計不是很優秀。不要去效仿它

5）、不要寫「聰明」的代碼

6）、按功能單元劃分源碼樹，而不是按組織結構

６、結對編程中很差的習慣——你經歷過麼，如何提醒同伴改進

結對編程歷來不是一我的的事情，所以咱們做爲團隊成員咱們要去遵照一些規範，這樣纔可讓咱們的團隊變得更好，才能讓咱們的編程工做得以進行。首先溝通是必要的，咱們還能夠制定一些行爲規範和工做要求，在溝通時還要注意我的態度和規勸溝通的語氣，儘可能委婉，要求同存異，儘可能達成一致。