至此為止，個人作業階段就結束了，從此便進入團隊合作階段。這次是先從結對編程開始，雖然還沒有進入正式的開發狀態，但也是結對編程的小開端，同時也是一個復習代碼復審這部分內容的過程。

閱讀目錄

1.題目要求

2.結對體驗

3.代碼審查表

4.隊友代碼及優缺點評價

5.個人感想

題目要求

要求：
(1). 首先在同學中找一個同伴，範圍不限，可以在1~5班中隨意組合，建議盡量不要找同組的成員，女同學盡量找男同學結對，但是不做強制要求；
(2). 從以往個人完成的項目中選擇一個作品，例如：以往的數據結構課程設計或者其它具有比較完整功能的小系統，代碼至少要大於100行；
(3). 將代碼上傳至個人GitHub或Coding.net系統中

結對體驗

剛開始聽說有結對編程項目的時候，我其實內心還挺想和班級裏的男生一起組隊的，因為很多男生的編程動手能力確實比大部分女生的動手能力要強（當然這裏排除那些確實很厲害的女生），我想通過這個結對項目向男生吸取一些經驗，多多學習一些他們的優勢。

但是下課後，我的室友，也就是我這次的結對編程小夥伴雷鎵——一個性格豪放樂觀又開朗的女生，向我拋出了橄欖枝，想讓我作為我倆的領航者。其實在這裏我也有考慮多方面因素，包括我們倆人的編程能力（確實還有點擔心如果題目過於難，我們的實力到時候能否撐起這個編程項目，我能否把我們倆人的任務安排好等），但也有一些好處，我們倆是室友，編程時間可以隨時規劃，交流起來毫不費力等等......

所以，最後還是爽快地答應了，或許，兩個女程序員能擦出更好的火花呢？

代碼審查表

雷鎵同學的博客地址

雷鎵同學的代碼地址

代碼審查表如下：

隊友代碼及優缺點評價

這次我就先來評價一下雷鎵同學的代碼吧，她的這次代碼是她數據結構課程設計的代碼，有關於最短路徑的求解。其實我們倆的課程設計題目還是挺像的，我是用普裏姆算法來求出以不同節點為起點構成的最小生成樹，而她是用弗洛伊德算法求出連接兩個城市的最短行走路線。

看她的代碼之前就需要首先了解弗洛伊德算法，感覺又重新回到了大一大二學數據結構與算法的那個時期了，真的是好久都沒有學過算法了，自我感嘆自己根本不像是一個計算機專業的學生了。

其實雷同學的這個代碼使用c語言寫的，所以參照代碼審查表中的一些c++的高級特性就沒有什麽意義了。她的這個小項目優點還是有很多的，比如算法寫的比較完善，部分代碼也還算比較整潔啊之類的，但是我認為還是有一些不可取的地方，在這裏我就毫不客氣地指出來啦。

1.從排版方面來看，
例如下面列舉的她代碼中的一個弗洛伊德函數，這塊代碼首先從排版上，我就看的比較難受，可能並不是只有我一個人強迫癥吧，大括號{}在有的循環中出現了，在有的循環中沒有出現。我個人的習慣是在一個函數中如果循環體中無論是有幾條語句，哪怕只有一句也要加上大括號的這種強迫星人。

說實話為了看懂這段代碼我確實真的是把它重新整理了一遍。

void Floyd(MGraph *L,int n)
{
int i,j,k;
for(i=1;i<=n;i++)
    for(j=1;j<=n;j++){
        if( L->arcs[i][j]!=Maxint)
            p[i][j]=j;
        else
            p[i][j]=0;
        D[i][j]=L->arcs[i][j];
    }
    for(k=1;k<=n;k++){
        for(i=1;i<=n;i++)
            for(j=1;j<=n;j++){
                if(D[i][k]+D[k][j]<D[i][j])  {
                    D[i][j]=D[i][k]+D[k][j];
                    p[i][j]=p[i][k];
                }
            }
    }
}       

或許，改成這樣是不是能看的方便一點呢，當然，這只是我的個人見解。

void Floyd(MGraph *L,int n)
{
int i,j,k;
for(i=1;i<=n;i++)
{
    for(j=1;j<=n;j++)
        {
            if( L->arcs[i][j]!=Maxint)
                p[i][j]=j;
            else
                p[i][j]=0;
        }
    D[i][j]=L->arcs[i][j];
}
for(k=1;k<=n;k++)
{
    for(i=1;i<=n;i++)
    {
        for(j=1;j<=n;j++)
        {
            if(D[i][k]+D[k][j]<D[i][j])  
            {
                D[i][j]=D[i][k]+D[k][j];
                p[i][j]=p[i][k];
            }
        }
    }

}
}

2.關於變量的定義
雷同學的部分代碼變量定義的太過於簡單，簡單到我一眼看不出這是哪個變量...恩，其實我也是花費了一些時間來找。
比如說下面這兩句

MGraph *L;
    int n,e,v,w,k;

不誇張地說，結合了後面的代碼我也是看了好久才懂，我覺得我以前也是這樣的，從大一開始學習c語言開始就一直用一些a、b、i、j、k、n之類的名字來定義變量。這其中有很多原因，其一是因為這些變量名字短，寫起來方便，其二是自己寫的程序都很短很簡潔，哪怕定義10個20個這種變量自己也還是能記住每個字母都對應著什麽意思，但是這就給別的閱讀代碼的人造成了困擾，如果是別人第一次閱讀你的代碼的話，我覺得他可能會崩潰。

我也是從大二開始寫代碼才想要用一些英文單詞來命名變量，有些不會的就上網查英文意思，選一個比較符合函數意義的單詞來命名。

在這裏她定義的n為頂點個數，e為邊數，v為起點，w為終點。如果我修改的話，可能會改為:

    int vertex ,edges ,start_point ,end_point ;

3.關於malloc
代碼中使用了malloc來動態申請內存，以前我們編程的時候也沒有註意到這樣幾個問題。
內存真的申請成功了嗎？如果所申請的內存塊大於目前堆上剩余內存塊，則內存分配會失敗，函數返回NULL。那我們在使用指向這塊內存的指針時，必須用if（NULL！=p）語句來驗證內存確實分配成功了。

申請成功之後，既然有分配，那就必須有釋放。不然的話，有限的內存總會用光，而沒有釋放的內存卻在空閑。與malloc對應的就是free函數了。free函數只有一個參數，就是所要釋放的內存塊的首地址。在這裏雷鎵同學並沒有寫相應的釋放代碼。

而既然使用free函數之後，指針變量本身保存的地址並沒有改變，那我們就需要重新把p的值變為NULL。如果沒有把指針置NULL，這個指針就成為了“野指針”，這是很危險的，而且也是經常出錯的地方。所以free完之後，也一定要給指針置NULL。

這其實是一系列的內容，每次使用動態申請內存的時候都要考慮一些這些問題，這些也同樣是我以前沒有考慮到的。

4.有關註釋
雷鎵同學的代碼沒有註釋，幸好她的代碼不長，一百行多一點，而且函數只有三個，還都是無返回值的void函數，能從她的菜單中看出她的意圖，還是挺好的，但是希望以後稍微寫一些註釋，有助於別人閱讀她的代碼。

個人感想

??首次結對編程體驗雖然只是一個互相復審代碼的過程，但還是讓我有了很深刻的體會。結對編程？構建之法一書中說到結對編程是極限編程的一種，是比單人編程有很多可取之處的，其中一些優點就是兩個人能夠互相審查、共同進步。而我們寫代碼不能只自己看，自己偷偷藏著掖著自己隨便寫，以後也絕對是不可能的事情，一己之力做不成什麽大項目。為了讓別人能夠容易閱讀你的代碼，首先代碼所需要的就是簡明，易讀。代碼復審的過程中才知道原來小夥伴的代碼有很多優點，同時也暴露了很多缺點，而自己反觀自己的代碼，同樣慘不忍睹，年輕啊，以為寫代碼是多麽容易的事情，動動腦子，仔細研究研究算法就行了，事實根本不是這樣，如果真正落實到實際項目之中，那要考慮的太多了。

??還想了想，以後如果在公司實習或者工作，遇到的同事和夥伴看不懂你的代碼，那會是多麽尷尬的一件事情，這首先就證明了你寫的並不是很盡如人意，不是那麽通俗易懂。缺點在代碼復審中暴露出來了，下次真正做項目的時候要好好註意了。

結對編程初涉獵——結對夥伴的代碼復審