軟體工程pair work之感想 by 張婷

曆時兩個星期的pair work總算告一段落，在最後presentation結束之際，回顧之前經曆的種種困難以及克服後的喜悅，想跟大家分享我們的成果與收穫。

Pair work的項目是對academic map進行一些補充和修改，項目的分配原則是大家玩一個number game，按贏者的先後順序選題目。我很慶幸自己猜中了，首先選了一個覺得很有意義的項目，就是對機構下的author進行多種排序。原始碼對作者是按其論文的citation count來排序的，然後把作者呈螺旋形展示。我們的目的是不僅按citation count ，還要按publication count來排序，並且能給使用者一個選擇的空間，能夠自由選擇按哪一種排序。這是原來的介面。

首先，我們對這個問題進行了討論和分析，然後得到它的WBS：

1． Sort: 要對publication 排序

2． UI：設計介面使使用者能方便地選擇排序

接下來，我們開始鑽研原始碼，瞭解大致架構，並對我們問題的相關部分代碼進行了深入探討。在原始碼中找到了這樣一句話String u=string.Format(…&EndIdx={3}&OrderBy=CitationCount…)。原來原始碼是用academic search API直接得到前50 個 citation count 最高的作者，那麼我們能不能也用API 得到前50個publication count的作者呢？於是，我們查看了API使用手冊，發現上面提供的排序只有三種：Citationcount ，Year ，Rank。並沒有提供publication的排序，這就意味著我們得自己進行排序，難道要把所有的作者都從API上獲得然後進行排序嗎？演算法時間和資料大小都是個限制，這時，我們做了個假 設，即大部分情況下，如果一個作者其論文的citation較高，那麼他的publication也相應較高。所以，最終的解決辦法是得到前100個citation高的作者，再按publication排序得到前50個，我們認為這是比較合理的。

然後，UI的介面設計也曆經曲折，先放一個我們最初的一個雛形。

紅框裡圈著的就是我們的介面按鈕，第一次做出來時挺高興的，結果大家反映實在太難看，其實現在自己看著也覺得實在是不美觀。於是，我們就想辦法去改進，既要美觀，又要方便，還要觸發事件能夠較好調用，經過我們科代表唐傲的建議，便是最終的介面。右面的紅框裡是我們的菜單，並且可以隨著展開作者自動彈出。

最後，花的時間遠比我們預計的要長，這是為什麼 呢？可能是我們對問題的認識不足，以為排序就是很簡單的把citationcount改成publicationcount，以為介面就是在原來的基礎上增加兩個按鈕並添加觸發事件。可是，真正做起來時，更多的問題才浮現出來，這時也更能體現合作的力量，互相鼓勵，互相督促。下表是我們對各項工作的預計時間以及真正花費時間。

合作關係是一個磨合的過程，也許有人會覺得自己一個人說不定更高效，有時的確是這樣。比如，我倆最開始是一起看代碼，發現進度實在太慢了，然後決定分開看。但是，合作的優點在於你不光一個頭腦在想事情，倆人或多人在一起更能產生好的想法，所謂三個臭皮匠，頂個諸葛亮嘛。所以雖然我們是分開看代碼，但最終是一起討論，分享心得。其實最重要的一點是我從對方身上學到很多東西，我的同伴錢一鳴是一個非常優秀的人，程式寫得和思維一樣快，通過這兩周的結隊編程，增進了友誼也提高了自身。

pair: 張婷 & 錢一鳴