第二次结对编程 微软学术搜索
殷鵬程 10061130
姚銘 10061204
選題：微軟學術搜索
第一部分——關于微軟學術搜索網站的Functional Bugs
1.?Academic Map?鼠標滾輪縮放失效問題
Symptom：正常使用Academic Map的縮放功能時，縮放操作可以同時通過拖動頁面右上角滑塊與滾動鼠標滾輪實現（后者符合大多數用戶習慣），但在Academic Map上點擊一個學術機構之后，系統提示加載，拖動滑塊依舊可以執行地圖縮放，而此時鼠標滾輪失效。
2.?Academic Map?載入學術機構后用戶當前縮放失效問題
Symptom：當點擊一個學術機構時，地圖返回一個固定的縮放比例，用戶當前縮放比例失效，這不利于用戶查看地理位置臨近的學術機構的相關信息（用戶需再次執行縮放操作），比如北航與北科。
3.?Academic Map?雙擊學術機構后無法返回地圖模式問題
Symptom：正常情況下，單擊學術機構，程序載入正確的機構相關信息，此時地圖做陰影化處理，用戶可通過單擊任意非連接區域回到地圖模式。而雙擊某一學術機構（特別是多次雙擊）時，程序載入機構相關信息后，此時單擊任意區域都無法回到地圖模式，同時，此時地圖未作陰影化處理。程序核心功能無法繼續使用。
本Bug在Chrome 23及IE 8下均出現：
Probable cause：在多次雙擊某一節點的情況下，程序可能會多次異步載入學術機構信息，由于未能夠正確的處理鼠標雙擊節點的事件，程序對“當有信息后臺載入時鼠標雙擊節點”的情況處理有問題，或未作處理。
4. 搜索部分中文關鍵詞出現不相關結果
?Symptom：嘗試搜索“數據挖掘”，得到如下所示結果，初步判斷兩篇文章與“數據挖掘”此中文關鍵詞不相關（雖然正文內容可能為數據挖掘），在兩篇論文的題目、摘要中都未出現“數據挖掘”，且由于原文鏈接失效，無法驗證正文中是否出現相關詞匯。
注：搜索結果中未給出“數據挖掘”在正文中出現的位置信息。
5. 強制停止搜索操作時UI仍顯示‘載入’狀態問題
?Symptom：在首頁執行搜索操作后，強制停止新頁面的載入，此時最右側‘載入’圖案仍舊顯示
?
?補充：一個可能的功能性bug：鍵入某個keywords，無法自動導航至關鍵詞頁面，如information retrieval，而鍵入social network則可以，雖然用戶的query string同關鍵詞是完全match的。希望能夠修復這個bug(我發現當keyword與某個期刊或會議的關鍵詞重疊后，系統會自動給出提示，讓用戶選擇進入哪個頁面，那么為何keyword不會與其發生重疊時自動進入keyword頁面，而不是讓用戶選擇是否由結果頁面跳轉到keyword頁面？應該統計當用戶搜索某個keyword時的意向頁面來決定哪個優先展示)（來自采訪后的用戶反饋）
?
?
6. 非功能性：UI問題
Subdomains下的下劃線過長問題，如圖所示，subdomains下發的下劃線右端過長，影響了頁面的整體視覺效果
7. 非功能性：數據問題 ‘color image processing?與 colour image processing’被作為不同關鍵詞處理
這是我本人在日常使用微軟學術搜索時發現的一個Bug，關鍵詞庫中很多包含color或colour的關鍵詞被視為不同的關鍵詞處理，如‘color image processing?與?colour image processing’，兩者的關鍵詞id分別為6646與6502，除此之外，還有很多類似情況。
?
第二部分——關于微軟學術搜索網站項目開發的不足
我作為微軟學術搜索長時間來的用戶，雖然使用頻率不高，但學術搜索確實幫我解決了很多問題。在閱讀了鄒老師關于微軟學術搜索項目的歷程介紹之后，我綜合分析得到以下幾點問題：
1. 前臺代碼規范問題
根據鄒欣老師教程，結合本人日常開發的總結，我認為微軟學術搜索在前臺開發上存在如下幾個問題：
1.1 JQuery代碼與前臺代碼混用問題
查看首頁（http://academic.research.microsoft.com/）的源代碼，我們可以在<head></head>標簽內發現對JQuery的引用。
JQuery是一個十分流行的Javascript框架，那么，既然使用了JQuery，根據使用JQuery的習慣與業界普遍贊同的編碼規范，頁面內所有對DOM元素的操作都應該通過JQuery實現，而不應該再使用丑陋的getElementById方法（否則就失去了使用JQuery的意義~）。但是，我們卻赫然發現了下面的代碼：
如上圖所示，頁面中同時使用了JS原生的getElementById()方法，以及JQuery的$(selector)方法，雖然兩者的功能是一致的，但考慮到后期的可維護性已經對編碼規范的遵守，應該統一使用JQuery風格的DOM操作方式。
1.2 HTML頁面標簽內嵌CSS樣式的問題
下圖截取的代碼為網頁底部欄目的html代碼。
可以看到，這個div引用了footer class，而讓人費解的是，div標簽中卻仍舊有內聯的CSS樣式屬性（style="height: 30px;"），對于前端開發而言，這是一種很不好的習慣，因為對同一個標簽的控制分散到了不同的地方，很不利于代碼的維護，即使在學霸的UI中，我們的前臺DEV也不會做這樣的事情。
從標簽風格來看，這個div應該不是asp.net自動生成的，那么前臺開發人員在書寫其css樣式時，應該將其所有樣式放到footer class里。
1.3 HTML標簽內嵌JavaScript函數問題
從下圖可以看出，頁面的標簽元素中內聯了很多javascript函數，而根據一般的js編碼規范，js函數應該單獨放到<script></script>標簽內，html的事件（如onClick）應該直接飲用js函數名，而非直接在onClick事件中定義。
這樣做，會有以下幾個問題：
1. 不同的事件，其處理函數可能相近，內聯定義會造成代碼冗余
2. Html代碼與js代碼高度耦合，當代碼量達到一定量級后，可維護性會很差
在學霸UI中，所有的js代碼均位于Header標簽內的<script></script>標簽中，方便了引用與維護。
從以上幾點可以看出，beta版本的微軟學術搜索在前臺代碼的代碼質量控制上可能有所疏忽，希望能夠引起重視。
2. 關于開發技術手段的問題：對與合理使用asp.net服務器控件的探討
僅從微軟學術搜索的首頁來看，可以發現，頁面大量使用了asp.net技術，具體表現在幾乎所有的div的id都由ct100打頭。
使用asp.net的服務器控件可以簡化UI的開發流程，但是，從我個人的觀點，不恰當的使用反而會帶來以下幾個問題：
3. ?關于項目開發流程的問題
鄒老師的博客上有這樣一句話：
由于項目的絕大部分模塊都進行了大規模的工程性重構，重寫。有些問題太難, 研究員們逐步撤出了項目。
根據博文，可以發現，在M1階段，研究員與工程師共同參與，我雖然不清楚他們是否共同參與編碼，但從上文可以看出，M1階段可能沒有采取比較好的架構，或者比較好的設計模式，導致項目在迭代過程中需要進行大規模的工程性重構，但代碼重構對于一個項目來說，是很可怕的（我曾經看到過一篇博文，講的是代碼重構（重寫）標志著項目的失敗，具體鏈接無從找尋）。
因此，我猜測，M1階段的研究員與工程師可能共同參與了編碼，但很可能由于研究員的編碼風格可能不是面向工程的，導致M1階段的代碼存在架構上的問題，否則為何要大規模重構？之前不是根據MS Agile，進行了2周的計劃了么？懇請鄒老師解答~
?
第三部分——使用Academic Search進行學習領域的選擇：記黃同學使用Academic Search 的心得
編者按：
最近我的哥們黃同學需要進行CS專業領域的選擇，面對CS領域下形形色色的Subdomain，該選擇什么方向為好？在某日跟我提到此事后，我便推薦他使用微軟學術搜索。以下是黃同學使用微軟學術搜索完成專業領域選擇的過程記錄。
?
用戶背景：
黃同學，我航高工大三本科生，計算機科學與技術專業。
使用Academic Search的目的：發掘CS下的熱門領域，進行專業選擇
感興趣方向：Social Network，Machine Translation，Peer to Peer，Information Retrieval
?
用戶使用過程：
1. 學習階段與功能選擇
由于黃同學之前沒有使用過Academic Search，筆者首先向其大致介紹了AS的主要功能，并建議他通過兩個途徑進行熱門領域的比較：
1 查看相應Keywords（見上）的論文發表與引用數目圖
2 使用AS的Domain Trend功能，橫向比較CS下各個subdomain的論文發表情況。
?
黃同學希望通過衡量某個領域的熱度（主要還是看論文發表數目），并結合自我的個人興趣，來確定今后的研究方向。因此，以上兩種手段是比較有效的。
?
2. 具體使用階段
2.1 Domain Trend功能
在大致熟悉了AS的主要功能后，黃同學便開始了具體工作J，首先使用Domain Trend, 但打開Domain Trend的主界面后，小黃在左側的subdomain中找了又找，只找到了Information Retrieval……
“咋沒有其他的關鍵詞呢？！”
我向他解釋：AS中的Domain Trend只列出了AS中定義的subdomain的論文數目信息，其他的關鍵詞不在subdomain范圍之內。它們可能屬于某個subdomain。
那么，該如何找到上述關鍵詞所在的subdomain呢，我跟小黃犯了愁，Social Network屬于啥？Network & communication還是World Wide Web？Academic Search貌似沒有給出Domain與Keywords的對應關系哎…..
2.2 直接搜索Keywords得到相應圖表
比起第一種方法，這招來的更實在~
但是，我們在檢索各個關鍵詞結果后發現，對于上述所有KeyWords，2011年與2012年的論文publication數目都少于2010年，導致我們無法根據圖表判斷上述領域在11年與12年是否熱門（見下圖）。
其中，12年的數據只有兩位數，但為什么11年的也相對較少？估計是AS對近兩年的數據收錄不全。
但讓小黃沒有想到的是，keywords頁面還給出了領域大牛們對keyword的定義，方便了用戶對領域進行初步的認識與了解。
?
經過一番搜索之后，小黃認為Academic Search提供的近兩年的論文發表數目不太準確，不能很好的反映某一領域的發展趨勢，只能夠通過橫向比較各個領域間的論文發表數目來判斷熱門領域。最后，小黃選定了Machine Translation（興趣是第一位的J）。
最后，根據小黃同學的反饋，我們一起總結了AS的各個方面的優缺點~
?
| 項目 | 優點 | 缺點 |
| 數據量 | 橫向來看，CS各個subdomain的論文收錄頗全，足夠支撐日常論文檢索需求 | 對近兩年，特別是2012年的論文收入很少 |
| 界面 | 界面設計很人性化，特別是各項Visualization功能，將數據可視化，特別有利于向黃同學這類需要進行領域分析與研究的用戶 | “怎么沒有中文界面？！”（用戶語），Google學術至少還有個中文版，PS：本人常用國產萬方（wangfangdata.com.cn） |
| 功能 | 對比Google學術搜索與國內的萬方（wanfangdata.com）、中國知網等，微軟學術搜索的功能明顯更多，而且數據的可視化程度更高 | 部分功能在細節上仍需要完善，比如Domain Trend無法添加Custom Domain（比如比較用戶指定個N個關鍵詞） |
| 準確度 | 對大部分KeyWords的搜索比較精準 | 搜索結果排名上存在一些問題 對于部分keyword，如social network，題名social and biological networks的文章竟然排在第一頁第三位，遠高于題名包含social network的文章 搜索information retrieval，無法自動進入關鍵詞頁面（雖然關鍵詞同用戶鍵入文本一致） |
?
用戶對產品的改進意見：
?第四部分——移動設備上的微軟學術搜索
市場情況
目前學術搜索產品基本都是以網頁為載體，除了微軟，規模最大的學術搜索是谷歌學術搜索，其余的還有CNKI和Heliloid等搜索產品。但針對移動的客戶端尚未成熟，微軟學術搜索推出的WP7客戶端，其余的沒發現。
?
功能
關于要設計什么樣的功能以及為什么用戶會用該產品，我們使用NABC模型來分析的學術搜索的功能需求及改進方法以及這樣做的優點。
1)????? N (Need 需求)
現在的學術搜索產品功能大都僅限于學術論文資源的搜索，加以學科領域分類。而對于文獻之間的關系，學者之間的關系，還有研究機構之間的信息比較很少有體現。微軟學術搜索的幾個模塊功能實現了上述關系的深入分析，為學者提供了對學術資源的分析與整理。除此之外，我們還應該為用戶提供個性化的信息定制，給用戶感興趣的領域等信息給予更新。針對在移動設備上使用的用戶，我們應考慮到移動設備的使用特點，設計適合移動設備特點的功能。
2) A (Approach 做法)
考慮到為用戶提供在移動設備上快捷簡便的使用體驗，設計以下功能：
3) B (Benefit? 好處)
實現了上述功能，使得該學術搜索客戶端不再是用戶單方面向程序發出請求并獲得結果的平臺，而是用戶與學術資源互動的平臺。客戶端可以根據客戶的喜好，有針對性的提供給用戶最需要的資源，節約了用戶搜索相關信息的時間，方便了使用過程。另一方面，我們針對移動平臺，特別是手機，考慮到屏幕大小有限，提供簡潔和常規兩種閱讀模式是有必要的。
4) C (Competitors 競爭)
目前對于學生機研究人員，在網絡上搜索大量的學術資源是必要而又比較繁瑣的工作。一個易操作，功能強大的學術搜索平臺是有很大市場價值的。而目前的相關產品功能大都僅限于論文資源的搜索，加以學科領域分類，很少對資源的相互關系加以梳理，針對用戶的個性化信息支持更是幾乎沒有。所以經過分析，完成這個學術搜索移動客戶端的市場價值巨大，而且目前階段市場競爭還不是特別強烈，但面對其他相關學術搜索產品的不斷升級，競爭壓力在后期應該會有所上升。
?
角色配置
項目初期階段，測試量較少，設置開發人員2名，美工2名，測試人員1名；
項目中后期，設置開發人員2名，測試人員2名，美工1名。
?
12周計劃
項目采用迭代式開發過程。每周都必須召開例會分析項目的進度與當前難點，并且分析怎樣做確保進度的正常進行，每個小階段結束后進行一定的總結。而其中重要的一點，項目文檔是貫穿整個12周必須要做的事情，完整的文檔是保證項目順利進行的前提。
| 第1-2周 | 進行需求分析，并向公眾征求功能需要，綜合各方面的需求，最終確定項目的整體定位，細化并確定所有功能需求，形成需求報告。 |
| 第3周 | 軟件的架構設計，據需求分析所得結果完成軟件架構的詳細設計，為正式開發做準備。 |
| 第4-7周 | 第一輪開發，根據之前的詳細設計進行項目開發。 |
| 第8周 | 測試版發布，收集軟件的bug和其他不足之處，制定改進計劃。 |
| 第9-10周 | 第二輪開發，主要是完善之前的測試版本，并修改bug |
| 第11周 | 項目穩定階段，進一步完善項目，做項目的收尾工作。 |
| 第12周 | 結束項目的開發，制作說明文檔，幫助文檔等，完成發布。 |
轉載于:https://www.cnblogs.com/yinpc/archive/2012/12/28/2837390.html
總結
以上是生活随笔為你收集整理的第二次结对编程 微软学术搜索的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 计算机管理 看内存个数,如何知道/查看内
- 下一篇： 【2022年度书法鉴赏网课答案】