你問我答，不亦樂乎——軟工案例分析作業

• 2021 年 4 月 7 日
• 筆記
• 軟工

自互聯網誕生之日起，全世界的程式設計師與編程愛好者們便逐漸聯合起來，自發地形成了一個個的社區和論壇。在搜索引擎還沒有充分發展普及起來之前，問答型網站無疑成為了程式設計師們解決日常生產的各類bug的一個聖地。面對那些一個個一言難盡的神奇Bug，即便是在互聯網已經充分發達的今天，要想在網上尋找到自己滿意的答案，這些網站也依然是許多資深程式設計師的第一首選。

這其中，最具代表性的便是Stack Overflow，這個於2008年就已創立且一直繁榮延續至今的問答平台。而在中國，目前較為有名也有CSDN旗下的開發者互助問答社區，以及號稱『中文版 Stack Overflow』的Segment Fault。不過，雖說是找bug的平台，但這些問答網站本身是否也存在一些至今尚未解決的Bug呢？借著本次案例分析作業的契機，我也對這三個網站展開了時長近1月的深度調研，試圖努力找到這些幾乎立於『Bug之巔』的網站們自己的阿克琉斯之踵。

也順便體驗一把你問我答的快感吧

Stack Overflow

功能體驗

作為一個專門面向程式設計師的問答網站，其全部的功能也理所當然地應當圍繞問答的整個流程加以展開。而問答的本質其實也是內容，在知識付費、全民閱讀的今天，如何能夠精準高效地篩選出用戶想要看到的內容並以其喜聞樂見的形式呈現給用戶也是這些問答網站繞不過去的一道必答題。因此，『功能體驗』這一環節也將主要圍繞提問、回答、討論、評價、查詢與推薦這幾部分內容加以展開。

首先是Stack Overflow。作為目前程式設計師行業內無人不知、無人不曉的問答平台，Stack Overflow在各方面都幾乎是無可挑剔。後面的所有問答網站也基本上是對它進行的拙劣模仿與本土化改造。進入網站後，其首頁的內容如下：

然而這密密麻麻的英文，對於一個非英語母語的人而言，第一眼看過去不說頭大但也多少是有點震撼的。特別是要想從這些資訊中篩選出對自己有用的內容，就顯得更為不易。不過，只要適應了英文的環境，當語言不再成為阻礙因素後，應該說Stack Overflow的頁面還是非常清晰明白的。

那麼，為什麼有的問題是黃色背景，有的則是白色背景呢？

這確實有些反直覺，答案是：黃色背景的問題包含那些你已經watched的Tag，而白色背景的則是你Ignore或者並不關注的Tag。也就是說，通過背景色的設置，Stack Overflow希望你能夠把更多的注意力放在你關心的那些tag對應的問題上；但同時，它也希望你能夠通過瀏覽那些白色背景的問題了解一些你之前可能不曾了解過的領域內容。大概，這就是屬於程式設計師的浪漫了吧。

對於每個問題，首頁中都會列出這個問題的得票數，回答數與瀏覽量，同時在右下角標記出它最新的提問/回答動態，可以說基本上展現了每個問題最核心的內容。

提問

通過首頁的Ask Question按鈕即可進入提問頁面，頁面內容如下：

可以看到，Stack Overflow支援基本的markdown語法，並且提供實時渲染功能和使用教程說明，對新手非常友好；同時Stack Oveflow還支援在提問的同時基於標題自動檢測相似問題是否已存在；若存在的相似問題過多，它會向你發出警告，請你詳細地說明你的問題。

不過，美中不足的地方在於，Stack Overflow對於相似問題的評估似乎很大程度上基於字元串的匹配而非語義或關鍵字層面的理解和對齊。之所以有此猜測，是因為當我將標題起為why do we use virtural function in c++?時，它會對我發出『相似問題過多』的警告，並且第一條推送居然是Why do we use printf() function in C++?這個其實跟我們想問的問題相差甚遠的問題。而當我把標題改為A problem concerning about virtual function in c++時，不僅不報『相似問題過多』的警告，而且推薦的相似問題也隨之大幅改變。但事實上，這兩種文法都比較寬泛，並且其推薦關注的核心應當是virtual function與c++而不是why do we ***或者problem concerning這樣。

回答、討論與評價

為了更好地體驗Stack Overflow，感受其社區的活躍程度，同時也為了方便我調查這個網站的bug，我在該網站上提了這樣一個問題：

結果，沒想到第一時間就有非常活躍的社區大佬給了我回復，這位jonrsharpe用戶不僅幫助我重新修改了問題內容本身，同時也給出了一個鏈接，並且給我的問題投了-1票[捂臉]。

不過其實這幾位用戶都是通過網站的評論功能向我提供了他們的建議，而非真正意義上的回答。

那麼Stack Overflow上一個真正意義上的回答是什麼樣的呢？請看以下案例：

這是一個很久以前提問的一個關於使用python查找所有後綴為.txt的文件的非常簡單的問題(然而現在Stack Overflow上基本沒有這麼簡單的問題了)：

它排名第一的回答長這樣：

從長度上看，這個回答看起來並沒有什麼特別之處，當然Stack Overflow上比它更詳細的回答也是數不勝數。但真正讓筆者感到吃驚的在於這個回答左側投票數下方的那個『鐘形按鈕』。點開之後，內容如下：

這裡居然詳細地記錄了這條回答在給出之後所經歷的所有的評論和修改資訊！並且修改者也並不一定是回答者本人，而是任何其他人都可以(但必須要通過同行評審)。

從這一條非常普通的提問與回答中，其實我們就可以看出Stack Overflow在問答社區領域無可撼動的王者地位：

• 一切都圍繞內容展開
• 鼓勵任何人在社區進行積極互動
• 及時回饋，過濾那些被認為無意義的問題
• 良好的社區環境，一切行為均有記錄可循

這些，其他的問答社區能不能做呢？當然能，因為這並沒有什麼技術上的門檻。但它們有沒有必要去做呢？恐怕沒什麼必要，因為它們壓根就不可能有Stack Overflow這樣的會員基數：僅僅一個普普通通的問題的一條回答就被這麼多人評論和修改過，這放在其他的問答網站（包括後面要介紹的兩位）那都是不可想像的。

至於評價功能，Stack Overflow所採用的這種聲望值+投票的策略，客觀上確實成功地篩選出了那些高品質的問題，有效地提高了提問者的檢索效率，避免了同樣的問題被多次提問。但另一方面，我們也需要看到，這其實也同時抬高了回答者的門檻——因為現在已經很難再找到容易被解答的問題了，這對於剛剛加入這一社區的程式設計師菜鳥們恐怕不是一個好消息。

查詢與推薦

在問題檢索部分，Stack Overflow同GitHub一樣，支援一些複雜的基於正則的高級檢索功能，如下圖所示：

這些功能包括根據tag檢索、篩選相應的用戶數、回答數以及問題的分值等等，這也使得Stack Overflow可以根據用戶的具體需求提供更為精準的問題篩選與推薦功能。

但另一方面，這些高級檢索本身的語法相對較為複雜，在客觀上也提高了使用者的門檻。

因此，通過上述分析我們可以看出，Stack Overflow整體面向的還是程式設計師中的資深群體：不僅從頁面設計到內容布局以及功能支援，都透露著一股濃濃的程式設計師風；而且其在使用上也有一定的門檻，剛剛入行的菜鳥級程式設計師可能會望而卻步，而僅僅將其當作Bug界的搜索引擎使用。

軟體評測

評測環境：Windows10.1901系統+Chrome89.0.4389.114瀏覽器(下同)

Bug嚴重性評估表格(下同)：

Stack Overflow的bug確實比較少，這也同樣歸功於其完善的問答機制。正如我之前在其上的提問中所言，對於網站自身的bug，Stack Overflow專門提供了//meta.stackoverflow.com/questions/tagged/bug這一頁面供用戶進行回饋，該頁面內容如下：

可以看到，許多之前用戶回饋的bug現在都已經處於status-completed的狀態，這就意味著該Bug已經被修復；而剩下，基本上都是一些Stack Overflow認為無足輕重(鑽牛角尖)的內容了。不得不說，這一點Stack Overflow的的確確做的很好，也是充分發揮了其自身問答網站這一定位的長處。

下面是一些目前仍然存在的，被我發現的但在Stack Overflow方面看來可能『無足輕重』的bug。

Bug 1 徽章數溢出

• 可復現性：穩定復現

• 具體情況：

如上圖所示，當一個用戶所持有的各類徽章數多到一定程度時，在其每個回答的右下角的profile部分，最右邊的徽章數目就會溢出，導致無法看到該用戶銅質徽章的數量，而只能進入該用戶主頁才能看到。

• 成因分析：

  該問題的出現應當是因為Stack Overflow設置的這一窗口的大小是固定的，並且之後再未進行調整。於是當社區中出現大佬級用戶後，原有的窗口大小就容不下了。大概這就是有錢人的煩惱吧。

• 嚴重性：★★

• 改進建議：重新設定用戶的窗口大小，或支援自適應大小匹配。

Bug 2 輸入過長溢出

• 可復現性：穩定復現

• 具體情況：

如上圖所示，當搜索問題時輸入的字元數過多時(本此測試達到了2^20量級)，查詢結果處就會出現溢出現象，即字元直接越過了頁面右側的廣告欄並超出了邊界。

• 成因分析：

  這一方面說明Stack Overflow沒有像一般的搜索引擎那樣對輸入進行必要的截斷，同時也沒有考慮到會有用戶輸入這麼長的字元串的情況；但另一方面，其實這也恰恰證明了Stack Overflow對自己的搜索引擎很有信心，根本不擔心因輸入過長導致伺服器崩潰的現象出現。

• 嚴重性：★★

• 改進建議：直接將允許輸入的字元的最大長度設為一固定值即可；或者當待查詢內容過長時，對於搜索結果作人為的換行處理。

Bug 3 窗口懸浮

• 可復現性：穩定復現

• 具體情況：

如上圖所示，editing-help頁面下拉至底部時，左側不會覆蓋底部黑色內容，右側則會；兩邊不對稱，顯得不太美觀。

• 成因分析：

  同樣是前端頁面在設計時沒有將右側窗口嵌入白色介面部分所致。

• 嚴重性：★

• 改進建議：前端介面進行優化處理即可。

Bug 4 achievements窗口設計不美觀，文字緊貼邊界

• 可復現性：穩定復現

• 具體情況：

如上圖所示，主頁右上的achievements窗口在沒有achievements時，文字緊貼邊界，絲毫沒有任何頁邊距所言，確實很不好看；但對於程式設計師而言，或許無礙大局。

• 成因分析：

  同樣是前端頁面在設計時沒有充分細緻地加以考慮所致。

• 嚴重性：★

• 改進建議：前端介面進行優化處理即可。

Bug 5 what's this?靠邊界太近，不太美觀

• 可復現性：穩定復現

• 具體情況：

如上圖所示，主頁左側的What's this?太過靠近頁面邊界，顯得不太美觀。

• 成因分析：

  同樣是前端頁面在設計時沒有充分細緻地加以考慮所致。

• 嚴重性：★

• 改進建議：前端介面進行優化處理即可。

總體評分

定性來說，我對Stack Overflow的評價是 e) 非常推薦 。相比於接下來即將登場的兩大問答網站而言，Stack Overflow無論是從用戶、回答的品質還是各項功能的設計上都堪稱完美。我在找它的bug上也是花費時間最長，且所獲成果最少的。

定量來說，基於鄒欣老師給出的評分標準給分如下：

CSDN問答社區

功能體驗

與Stack Overflow不同，CSDN的問答社區顯然不是CSDN旗下的主打產品。其問答首頁如下圖所示：

可以看到，頁面的入口首先必須要從上方的『問答』按鈕點擊進入，而『首頁』則幾乎看不到關於問答社區的相關內容。在進入該頁面後，也同樣可以看到目前最新的問題，但與Stack Overflow相比，首先左側多了『頻道』這一子版塊，其次每一個問題缺少了votes這一屬性；並且似乎也不像Stack Overflow那樣利用背景顏色的區別篩選出用戶可能感興趣的問題和可能不感興趣的問題。

那麼CSDN為什麼不這麼做呢？

因為沒有這個必要。在這個社區里，基本上過上幾分鐘才會冒出一個新的問題，也就是說問題本身產生的密度就不高；那麼如果CSDN再去採用推薦篩選機制的話，可能用戶在較長一段時間看到的都是相同的幾個問題，那麼這樣的效果或許反而還不如直接展示目前『最新』或『最熱』的問題給用戶的體驗更好。

提問

同樣通過問答首頁的『提問題』按鈕即可進入到提問頁面，該頁面的內容如下：

可以看到，與Stack Overflow的內容板塊相比，CSDN問答社區的內容異常簡單：

• 不支援Markdown語法，因此也就不需要實時預覽窗口；
• 對於進一步的各個子工具也沒有相應的使用教程；
• 標籤的添加也是通過選擇已有的各個頻道對應的標籤來實現，而不是基於字元串的自動檢索功能。

不過CSDN有一點與Stack Overflow類似，那就是都支援相似問題的搜索：

但是CSDN的相似問題是以浮動彈窗的形式展現，因此會遮蓋住『內容』中的上半部分，這會對用戶體驗帶來一定的不利影響；而另一方面，CSDN的相似問題匹配演算法做的要比Stack Overflow更好。無論是如何理解C++中的虛函數？還是關於C++中虛函數的問題，CSDN匹配的相似問題都基本相同，且顯然是基於關鍵詞等語義資訊而非如何、為什麼這些無關的語法資訊。

最終我提了這樣一個簡單的有效問題：

截至部落格發布之時，還沒有得到任何人的回復，連個吐槽的都沒有。

回答、討論與評價

在CSDN社區中我主要體驗的是其回答功能，提問的功能接下來我還會在後文的軟體評測部分有所提及。與Stack Overflow相比，CSDN里的新手問題明顯要多的多，比如下面的這個問題：

可以看到，這個問題應該是任何一個經過大一程設課程訓練的人都能夠解答的關於c語言基礎的問題。這樣的問題基本上現在已經不可能在Stack Overflow上出現了。因為後者並不鼓勵這種完全可以自己解決的問題被提到網站上，這被認為是一種公共注意資源的浪費。

此外，我們還可以看到，這位題主甚至都沒有使用『程式碼塊』將他想問的程式碼給包裹起來，而是直接將其複製粘貼到內容區中；並且答主所提的問題與其相應的程式碼行為有較大偏差，讓人不明所以。

對此，這是我的回答：

題主本人倒是在我的回答後很快地給予了回復。但顯然按照題主的意思，這裡的scanf並不能滿足他的需求（而且還寫錯了）；此時由於已經有官方的技術專家團給予了解答，因此我最後只是簡單地加以評論，指明了正確的解決方案，就幸運地被題主標記為了『已採納』，甚至還獲得了點小收益。那麼專家團究竟回答了什麼呢？下面就是這位『專家』的回答：

那麼，這位CSDN社區的所謂『技術專家團』成員所給的答案真的解決了題主的問題了嗎？大家可以仔細地看一下，我認為顯然是沒有的，他只是糾正了題主scanf的錯誤用法而已。之後這位專家也就再也沒有出現過了。

通過這一案例，我們可以發現，CSDN問答社區的整體品質和用戶水平要遠遠低於Stack Overflow；即便是它所謂的專家團親自下場，也依然無濟於事，只是丟臉丟得更大了而已。

此外，CSDN社區不支援其他人對原有的回答進行編輯和修改，此外也不支援對原問題的評論功能，因此也就沒有Stack Overflow相應的日誌記錄等頁面了。

至於評價功能，首先在首頁介面，我們就可以看到CSDN並沒有votes這一資訊，其次它的作者的聲望值、榮譽、徽章等資訊也都無法在首頁看見，唯一可以獲取用戶對問答的回饋的渠道就是每個問題下的那個小小的點贊按鈕。這也在客觀上決定了CSDN社區里的各種問答呈現出一種泥沙俱下的局面。

查詢與推薦

在查詢和推薦部分，CSDN問答社區的功能就更顯貧乏了。

首先，CSDN不支援對問答板塊單獨的搜索內容，其搜索引擎直接面向全站。於是，就會出現以下神奇的現象：

看到這個推薦結果，我不禁懷疑這真的是一個面向程式設計師的問答網站嗎？為什麼這麼又紅又專？

其次，CSDN也不支援按照tag進行針對性過濾。要想針對性地查詢某個方向的問題，CSDN只能在其首頁左側的『頻道』中進行選擇。也就是說，之前在提問頁面所出現的tag唯一的作用就是告訴你這個問題可能涉及到哪些內容；但如果你想知道某個內容都有哪些問題的話，那對不起，你只能通過這幾個固定的頻道進行選擇了。

軟體評測

評測環境與Bug嚴重性表格可參見Stack Overflow的相關內容。

許多在功能性設計上存在的問題可參見上文功能體驗中的相關部分，這裡就不再作為bug一一列出了。

除了先天在功能設計上的缺陷外，CSDN社區還存在著以下bug：

Bug 1 回答數資訊不匹配

• 可復現性：穩定復現

• 具體情況：

  通過問答首頁右側的『用戶榜』可以看到當前採納榜排名最高的前幾位用戶的資訊：

注意到這裡有一位名叫oyljerry的用戶，採納榜單顯示他的回答共有1644次被採納。然而在點進這位用戶的主頁後，卻發現：

這位用戶的總的問答數居然只有2條！而他回答的問題更是一個也沒有！

很難想像排行榜中那麼高的採納數究竟是怎麼產生的，至少按照其主頁的回答數來看，這位用戶平均每個回答的問題被採納次數應該是正無窮才對。

另一方面，就我本人而言，首頁資訊欄上顯示我的回答數為4：

點進去之後，主頁里顯示我的有效回答又只有2條：

這還沒完，之前由於找bug的需要(詳情可搜索xss攻擊)，我在CSDN社區提了一些很奇怪的問題，並在這些問題下面做了很多回答，這些可以從『我的提問』中看到：

當然，後來因為審核原因，這些回答和提問都被判定為『無效內容』而被官方屏蔽了(這點CSDN動手得倒挺快)。但是問題來了，首頁資訊欄里的4條回答到底是怎麼算出來的？無論加不加上這些非法的回答，都不應該是4條啊？

• 成因分析：

  CSDN的後端資料庫應該沒有做到正確的同步，並且對於這些回答數的計算也沒有在官方給出一種有效的判定方式，因此最終導致了這一現象的產生。

• 嚴重性：★★★

• 改進建議：重新設計合理的統計演算法，後端資料庫重新設計相應的數據模型，從而確保各處數據一致性。

Bug 2 搜索框消失

• 可復現性：穩定復現

• 具體情況：

如上圖所示，當使用CSDN的搜索功能時，首先其默認的搜索範圍是全站，因此要想專門搜索『問答』相關的內容，就必須要到『更多』中加以選擇。

但尷尬之處在於，從『更多』到『問答』，這中間有一段不能忽視的距離。因此，只要用戶試圖直接將滑鼠『更多』移動到『問答』上，那麼這個彈出的浮動窗口就會直接中途消失！

因此，用戶的唯一選擇，就是在點擊『更多』後，老老實實地把滑鼠垂直向下移動，而後再移到『問答』按鈕的位置上。這極易帶來用戶使用體驗的大幅下降。當然，或許也可從側面證明『問答』版塊是有多麼的不受待見了。

• 嚴重性：★★

• 改進建議：增加彈出窗口的停留時間，或者重新調整該窗口的布局以與用戶的使用習慣兼容。

總體評分

儘管單就這裡列出來的bug數而言，CSDN問答社區看上去甚至要比Stack Overflow還要少，但這並不代表CSDN就比人家厲害了。畢竟很多功能上的先天性不足沒有被放到這裡的bug列表中，而是直接在之前的功能體驗部分就介紹過了。

這就好比一個天生坐輪椅的人跟一個後天腳踝扭傷的人炫耀他從來走路都不會扭到腳一樣，毫無意義可言。

定性來說，我對CSDN問答社區的評價是 c) 一般 。也就是除非你無事可做，不然刻意去上面看的話，很難學到什麼東西；但如果你在百度的時候無意中搜到一個排名很高的來自該社區的回答，那麼點進去看看或許對你也是有幫助的。

定量來說，基於鄒欣老師給出的評分標準，給分如下：

Segment Fault（思否）

功能體驗

Segment Fault(又稱思否，下文兩詞同義)也是一家國產的小有名氣的問答網站，從它的名字就可以看出，這家公司創立之時的野心絕對不小：希望打造一家中國的Stack Overflow。那麼時至今日，它是否真的做到了呢？從我目前的調查來看，很遺憾，答案是還沒有；但好消息是與CSDN相比，思否做的還是比較不錯的。

其主頁如下圖所示：

哦不對，這張似乎不應該作為一個問答社區的主頁，於是真正的問答主頁如下圖：

由此可見，思否與CSDN一樣，近年來也有逐漸將問答版塊降格，向全平台內容社區轉型的趨勢。但至少人家骨子裡還是一個問答社區，所以從這張介面圖上看，可以發現思否與CSDN、Stack Overflow相比，有如下特點：

• 有tag，無固定頻道，可以根據tag搜索；
• 推薦問題區分背景色，即既有用戶關心的話題，也有用戶可能不太關心的話題，這點與Stack Overflow看齊。但與後者相比，思否明顯黃色背景的話題占的比例要少很多，這也從側面體現了思否的用戶基數還是要遜Stack Overflow一籌；
• 每個問題無votes版塊，這點與CSDN保持一致；
• 主頁整體上要比CSDN清爽，沒有那麼多花花綠綠的無關資訊；也比Stack Overflow簡潔，沒有那麼多密密麻麻的文字，整體上的觀感相對最佳。

提問

還是通過首頁的『提問題』按鈕，進入提問頁面：

可以看到，與Stack Overflow和CSDN相比，思否的提問頁面顯然是有優有劣。

先說優點：

• 支援Markdown語法，對於開發者而言更友好；且支援所見即所得與Markdown兩種不同的寫作方式，兼容性很強；
• 頁面非常簡潔清爽，這也是思否整體的最大亮點；使得用戶在創作/提問過程中可以做到沉浸式投入而不受干擾；
• 支援非常豐富的組件，比CSDN豐富太多，甚至支援上傳影片，這連Stack Overflow都沒能做到；
• 支援搜索添加標籤，支援自定義標籤。

再說缺點：

• 完全不支援相似問題匹配；
• 『添加標籤』按鈕點開還是會覆蓋內容；
• 頁面放大後，沒有將預覽部分移到下方，這對於手機用戶並不友好，整體會顯得非常擁擠。

目前我在思否上提了這樣一個問題：

截至部落格發布，也還是沒人理我，連個吐槽的都沒有。

不過對於問題，思否支援『關注』、『收藏』、『點贊』這幾個傳統技能，還是比CSDN做的要完善不少的。

回答、討論與評價

在Segment Fault中，整體上問答內容的品質要介於Stack Overflow與CSDN兩者之間，基本上也找不到CSDN中那種過於簡單的新手問題。找了一會兒之後，我最終找到了這樣一個與python相關的還算簡單的問題：

可以看到，與CSDN中相比，提問者的素養明顯高了很多：將其所提問題涉及到的程式碼用程式碼塊包裹了起來，極大地增強了可讀性；同時問題的內容描述得也非常清楚，讓人一看就能明白他想要問什麼。

事實上，在這之後，這位題主還通過思否中的『評論』功能進行了自問自答：

可以說，這個答覆基本上算是很詳細地給出了原問題的一個最優解。因此，我後面的回答僅僅只是提供了一個參考文檔，並且結合題主的原模型做了一點針對性的補充。

我的回答如下：

目前，該回答既沒有被採納，也沒有得到任何回饋；大概是題主本人已經不再關心這個問題了吧。

據此可知，在思否中，也同樣較完善地支援了問答相關的基本功能，包括提問、回答、評論、點贊／踩、收藏、關注等。此外，與Stack Overflow一樣，思否也允許其他用戶對現有回答進行編輯，並且在審核後決定是否修改有效——這也確實是思否的一大亮點。當然，由於客觀原因，思否並不支援像Stack Overflow那般把所有的修改記錄都公開給用戶，但能夠支援用戶的自由修改，對於問答社區而言，已經是非常難能可貴的一件事了。

查詢與推薦

查詢方面，思否也是只提供了一個統一的面向全平台的查詢介面，當然這可以理解為其想要進一步為它新增的那些其他功能做推廣，積累流量。不過好在『問答』版塊在思否這依然佔據著舉足輕重的地位，因此搜索後可以直接選擇查找問答欄目下的相關話題。

但遺憾之處在於，這裡思否也同樣不支援相似問題推薦系統，即用戶無法在搜索框中鍵入的同時獲得系統自動為其推薦的最相似問題的資訊，這一點可能要稍遜CSDN一籌。

此外，在點擊首頁右方的相應標籤後，即可進入該標籤對應的子問題頁面：

這裡明顯能感覺到比首頁的資訊密度大了許多，並且得票資訊也能夠呈現出來；但話又說回來，既然有這個屬性，為何不再首頁就展示呢？

軟體評測

評測環境與Bug嚴重性表格可參見Stack Overflow的相關內容。

雖然Segment Fault整體上給人的觀感明顯要好於CSDN，但是它的Bug卻出人意料的多，而且還有不少Bug的重要程度相當之高，說實話這是我一開始沒有料到的。

Bug 1 xss攻擊有效

• 可復現性：較難復現

• 具體情況：

  其實xss攻擊是我在拿到本次案例分析作業後第一件想乾的事，這點細心的讀者在我之前的內容中或許就已經可以窺知一二(提示：Stack Overflow中的提問、CSDN中的非法問題)。但為什麼到現在才終於提到它呢？因為之前的兩個網站，我在多次嘗試後全部都以失敗告終，甚至在CSDN中付出了帳號被凍結一天的代價。而到了Segment Fault這裡，我本人也沒有成功。

  但諷刺的是，當我在它的問答中搜索有關內容時，卻找到了這樣一個問題：

而在這個問題的下面，居首的有這樣一條答覆：

再一看日期，居然就是今年３月份的事！

也就是說，在Segment Fault這裡，xss攻擊是可以實現的！而一旦可以實現，就意味著這個網站可能會出現一些非常可怕的漏洞，甚至會出現用戶隱私泄露的情況（具體內容感興趣的同學可自行百度xss攻擊），後果將不堪設想。

但遺憾的是，這位答主至今還未回復我的評論，所以我也不知道具體的實現方式，反正可以肯定不是一般的法子。

• 成因分析：

  可能是思否在前端頁面的處理或者是前後端的通訊部分沒有進行非常細緻的處理，以至於出現了xss攻擊的漏洞。

• 嚴重性：★★★★

• 改進建議：重新複查前後端程式碼，確保覆蓋了所有與xss攻擊有關的漏洞測試。

Bug 2 搜索長度溢出

• 可復現性：穩定復現

• 具體情況：

  實驗證明，當在首頁的搜索框內鍵入的字元串長度超過8167時，網頁就會崩潰，顯示的回饋資訊如下：

類似的情況也在Stack Overflow與CSDN中均進行過測試，前者不僅不會報錯，而且不會截斷字元，但最後的回饋結果會略顯不美觀；後者則會直接採用截斷的方式進行處理，避免了過長字元串的溢出。

而到了思否這裡，則是什麼都沒有做，只要搜索長度大於8167，頁面就崩潰了。

• 成因分析：

  前端沒有對輸入的長度進行檢查，後端在收到前端傳來的字元串後也沒有及時做出檢驗進行異常的處理，最終導致了網頁的奔潰。

• 嚴重性：★★★

• 改進建議：增加對搜索輸入字元串長度的限制——儘管一般很少有用戶會輸入如此長的字元，但對於一家成熟的網站而言，數據溢出還是一個必須要考慮的問題。

Bug 3 標籤創建長度溢出

• 可復現性：穩定復現

• 具體情況：

  從問答首頁點擊右側標籤窗口中的『管理』按鈕，即可進入標籤頁面；在該頁面的輸入框中輸入超長標籤後，頁面效果如下：

可以看到，在『創建標籤』提示框中，輸入的字元串直接溢出到窗口之外，覆蓋了原有的一部分已關註標簽，極大地影響了頁面美觀程度，影響力用戶體驗。

• 成因分析：

  前端沒有考慮到標籤長度過長的情況，既未對此加以限制，也未對此進行渲染效果的優化。

• 嚴重性：★★

• 改進建議：可限制標籤的最大長度，從而從根源上杜絕此類現象的發生。

Bug 4 標籤關注人數不同步

• 可復現性：穩定復現

• 具體情況：

  在上文提到的標籤管理頁面，將滑鼠移至任意一個已關註標簽上時，即可彈出該標籤的一些基本資訊，注意到這裡顯示的vue.js標籤的關注人數為136897人。

但同一時刻，當我們點擊該標籤進入到該標籤對應的問答頁面中，可以看到vue.js的實際關注人數為136938人：兩邊的數據並不同步。

• 成因分析：

  不難發現，前者的關注人數小於後者；據此推斷，前者的關注人數應當是用戶在最後一次對該標籤進行更改時(即點擊關注/取消關注)該標籤對應的關注人數，而後者則是該標籤此時的最新關注人數。即，這裡出現了數據一致性異常的問題，推測可能是思否為了實現方便，將關注人數作為用戶關註標簽的一個屬性加到了用戶這一側的資訊列表中，而不再對其進行實時更新，故而導致了用戶介面查看標籤資訊時出現了更新滯後的問題。

• 嚴重性：★★★★

• 改進建議：重新設計後端數據模型，將該關注人數設置為該標籤實時的關注人數；前端在每次查詢時應直接獲取到該標籤相應的最新關注人數屬性，而非直接去用戶的標籤列表中調相關資訊。

Bug 5 標籤創建異常

• 可復現性：穩定復現

• 具體情況：

  還是在上文提到的標籤管理頁面，當向文本框中輸入字元'<'時，就會自動突然彈出創建標籤的窗口；特別地，若此時用戶的輸入包含用雙引號""引出的相關內容，則該部分內容會直接神秘消失。效果如下：

  首先輸入hello"world"：

接下來鍵入'<'字元，則會立刻彈出創建標籤的窗口：

且彈出窗口中不再包含"world"資訊。

• 成因分析：

  可能是思否在標籤創建這裡設置了一些不為用戶所知的正則匹配演算法，導致了當用戶輸入某些特殊字元時，就會被系統默認為執行了某種操作，甚至導致數據丟失現象的出現。

• 嚴重性：★★★★

• 改進建議：檢查與創建標籤相關的前後端邏輯，看看是否有哪裡的實現存在一些欠考慮的問題；如真是官方有意如此，則應在用戶可以看到的地方加上必要的說明，以幫助了解相關的邏輯和原則。

Bug 6 『關注的人』搜索異常

• 可復現性：穩定復現

• 具體情況：

  點擊問答首頁右上角的個人頭像，從彈出的窗口中選擇『我的主頁』，從而進入用戶的個人主頁：

在個人主頁中點擊左側『關注了X人』按鈕，即可彈出上圖中的相關頁面。

在搜索框中鍵入字元，即可匹配到相似用戶的資訊。但此時有如下問題：

1. 搜索框神奇地不支援輸入大寫字母，所有大寫字元全部被默認轉為小寫；但顯然有不少用戶用戶名是大寫的，不知官方這樣強行轉換的意圖何在；
2. 搜索框的搜索時間開銷隨著鍵入的字元長度基本呈線性增長，常常出現輸入了一段文字後等了好久才會彈出下文的相似用戶列表；而此時用戶往往會誤以為沒找到目標用戶，故將原始輸入清空並重新輸入新的內容了——極大地影響了用戶體驗。

• 成因分析：

  其他兩個網站都不支援這裡的搜索式添加關注，顯然是考慮到了搜索效率過低帶來的負面影響，要從技術層面上解決，可能需要優化字元串匹配的底層實現演算法等問題；至於大寫字母無法輸入，推測可能又是系統自行設定的某種不為用戶所知的約束，但這確實讓人覺得有些莫名其妙。

• 嚴重性：★★★

• 改進建議：使用更高效的搜索演算法，或者直接把這個功能砍掉——因為看不出在這裡加個搜索框對於一個問答軟體而言的意義何在。

Bug 7 黃色提示框無法關閉

• 可復現性：穩定復現

• 具體情況：

  在每個問題頁面下方，都有一個『撰寫回答』的版塊，用戶可以在這裡鍵入他們對這一問題的回答。注意到這裡有一個黃色的提示框，告訴用戶也可以使用評論功能。這個提示框右上角有個'x'按鈕，似乎說明這個提示框可以關閉；但事實上是，無論你怎麼瘋狂地點擊這個'x'，提示框都無法關閉——這顯然客觀上會對用戶的回答體驗造成一定程度的干擾。

• 成因分析：

  應該是在前端頁面設計時，沒有與後端做好正確溝通：後端或許本就不希望關閉這個提示框，但前端卻提供了一個看似可以關閉的組件，進而引發了不必要的誤會。

• 嚴重性：★★

• 改進建議：重新設計前端頁面即可。

總體評分

思否雖然bug比較多，但整體的使用體驗上還是要略勝CSDN一籌的。因此定性來說，我對其的評價是 d) 好，不錯 。對於一個中文編程開發者而言，如果在語言上存在一定障礙的話，那麼思否或許是Stack Overflow一個不錯的替代品。

定量來說，基於鄒欣老師給出的評分標準，給分如下：

綜合分析

採訪

採訪對象背景介紹

• 基本資訊：

  田同學(非本人)，也是1806電腦學院的一員，有著極為豐富的程式開發經驗。

• 選擇原因：

  一方面，田同學的編程開發經驗豐富，在極客問答方面有著較其他人更為多樣化的需求；另一方面，田同學曾多次在電腦學院的水群里鼓勵大家去Stack Overflow上提問，給我留下了極為深刻的印象。

• 主要需求：

  一般是遇到無法自己解決的問題才會上Stack Overflow搜索答案，現在也已很少在上面回答問題。

• 使用產品：

  Stack Overflow為主，其主要功能包括提問、回答、查詢等均充分體驗過

體驗回饋

附採訪文字記錄如下：

設計與評估

Q1：使用此服務的所有功能，估計這個軟體/網站/服務做到這個程度大約需要多少時間(團隊人數6人左右，電腦大學畢業生，並有專業UI支援)

問答網站前端的頁面搭起來應該並不難，現在也有了Vue這樣比較簡潔方便的框架，再加上專業UI的支援。因此，我認為該類型網站的幾大核心難點主要有：

1. 高級搜索引擎(正則匹配、推薦演算法等，實現準確性與性能的平衡)
2. 富文本編輯器(支援Markdown與多種組件)
3. 完善的數據模型(即不同實體和實體的屬性都有哪些，如何降低數據冗餘且保證性能)
4. 豐富的功能細節(評論、編輯、回答、投票、勳章榮譽等等)

假設目前這些核心功能都需要我們從零開始實現的話，那我認為至少需要6個月，也就是24周的時間。其中市場調研+需求設計1個月，這四大類功能的實現和測試各1個月，UI設計這期間同步進行，最後一個月用於產品整體的集成測試與封裝上線。

但這只是一切的開始，要想真正構建一個同Stack Overflow一樣繁榮的問答社區，那我認為就絕不是一年半載的光景了，也不是一個純技術的問題了。

Q2：分析這個軟體目前的優劣(和類似軟體相比)，這個產品的品質在同類產品中估計名列第幾？

與CSDN問答社區和Segment fault相比，Stack Overflow在用戶群體規模、問答內容品質等各方面基本上都處於碾壓的水平。可能唯一美中不足的就是它的UI設計的比較復古，現在來看可能顯得有些過時，導致用戶的閱讀體驗（特別是非英語母語選手）可能會相對低一些。

由於問答社區的相似產品很多，故這裡僅考慮Stack Overflow(SO)、CSDN問答社區(CSDN)與Segment fault(SF)這三者之間的相對排名，如下表所示(針對中國用戶群體而言)：

Q3：從各方面的問題，推理出這個軟體團隊在軟體工程方面可以提高的一個重要方面(具體建議)

通過上述分析，我認為Stack Overflow團隊目前亟需加強的可能正是它的前端UI介面設計方面。相比於其他後起之秀，Stack Overflow的UI太過簡陋，且文字資訊量較高，密度較大，看久了確實容易引起人心理不適，造成過度疲勞。

因此，我希望Stack Overflow能夠在這方面作進一步的優化，具體策略如下:

1. 放大字型大小、增加頁邊距
2. 修改頁面整體配色方案，支援暗夜模式等
3. 在文字之外，可適當多一些配圖等元素；而不是完全依靠文字作為各個圖標或窗口介面。

而CSDN的主要問題則在於各方面功能設計的都不太細緻，當然這可能與其用戶的整體品質有關；具體而言，我認為其最需要加強的應該是提問與問答頁面的布局設計和功能升級，具體策略如下：

1. 增加一些更豐富的組件功能，添加對markdown語法的支援；
2. 修改程式碼塊的配色以使得其與背景更好兼容
3. 調整頁面整體布局，突出重要部分如問題和回答
4. 增加評論和修改功能

思否的主要問題在於一些細節上的進一步推敲，這些內容可以參見上文功能評測的相關bug部分。從整體上講，思否對於中國用戶而言的使用體驗應該是相當不錯的。

Q4：你在第一部分發現的bug，為何軟體團隊不能在發布前修復？他們是不知道，還是有意不修復？你覺得是什麼原因？

對Stack Overflow而言，UI相關的Bug我覺得軟體團隊應該是知道了也不修復，因為這應當是屬於設計風格的問題。畢竟Stack Overflow關注的是內容本身，對於介面這種細枝末節的東西，它似乎並不在意。

至於徽章數溢出，顯然一開始軟體團隊並沒有料到會有這麼一天；而輸入溢出，則是因為正常用戶往往不會做出這樣的舉動，Stack Overflow也就不會收到這樣的回饋，於是這一Bug也就被擱置了。

至於中國的兩家網站，我認為這些bug他們並不知道，甚至到現在都不知道；或者知道了，但因為缺少人手故而始終未能修復。因為歸根結底，這兩位都缺少有效公開的用戶使用回饋機制，無法像Stack Overflow及時收集平台本身存在的問題並進行有效處理。

市場調研

市場概況

目前整個IT問答領域的市場空間基本可以認為是現有的程式設計師的數量，即IT從業者的數量。下圖展示了中國從事軟體和資訊技術服務業的從業人數2011-2018年的變化趨勢。由此可見，其近幾年的增速似乎有放緩的趨勢，但總的規模依然保持在600萬這一量級之上。據此推斷，則全球的IT從業者人數應當在2000萬人左右，這即是問答領域的潛在用戶數量。

另一方面，假設一家正常的從事問答網站軟體開發的公司其市場佔有率為30%，那麼也就基本可以擁有500萬左右的用戶數，假設這些用戶每日平均產生5w個問題，那麼一年下來社區僅新增問題數就將達到千萬以上的規模。然而截至目前，Stack Overflow上總的問題數也才不過21,052,841個，相當於理想情況下2年的新增問題數。而Stack Overflow自08年創立之日起，距今已有13年之久，理論上的問題數至少也應該達到6千萬個。因此，綜上所述，目前就連Stack Overflow總的市場佔有率也最多不可能超過15%，這就意味著其將來還有著極大的發展空間。

至於中國的這兩家網站，發展空間就更大了。但問題在於中國的開發者是否普遍具有這樣進行公開有深度的交流的意願，以及是否願意通過問答而非論壇或其他形式進行，則依賴於兩家公司的推廣宣傳策略與營銷手段是否到位了。

市場現狀

目前市面上的問答社區產品可謂是魚龍混雜，產品品質參差不齊。既有像Stack Overflow這樣的超級巨頭，也有一些名不見經傳的創業型問答平台，還有一些像CSDN問答社區這樣依託於其部落格等內容平台搭建而成的附屬問答子平台。

從產品定位的角度來看，Stack Overflow以問答社區為核心，面向資深的IT從業人員群體，其核心盈利方式主要依靠廣告投放與企業招聘合作等形式；CSDN問答社區依託CSDN部落格發展，面向中國的IT從業人員(包括小白)，其核心盈利方式為廣告投放；Segment Fault以問答社區起家，但現在也有向全平台轉型的趨勢，似乎有打造體系化的知識內容分享平台的意願，其核心盈利方式除廣告外，還有精品課程、付費專欄等形式，相對而言要更為多元。

相較而言，Stack Overflow的主要優勢在於其自身問答內容的高品質與高用戶規模，但其劣勢主要體現在可能缺乏比較合理的變現渠道，因此其盈利能力應該較弱，而更加側重於公共服務屬性。CSDN的主要優勢在於其依託CSDN部落格平台實現用戶和內容的聚合，且大量投放廣告，故而無需擔心盈利的問題；但其劣勢在於本身內容的品質堪憂，且用戶規模相對而言並不是特別大。Segment Fault位於二者之間，一方面它的內容品質要好於CSDN，但不如Stack Overflow，用戶基數也同樣；但另一方面它沒有CSDN那樣的部落格平台作為依託，相對而言在中國的名氣不如CSDN那麼大，故而盈利能力應該也與之大體持平或是等而下之。

總的來說，這些問答平台互為競爭關係，目前Stack Overflow在競爭中處於領頭羊地位；其餘平台則互相不相上下，且主要針對中國市場。

市場與產品生態

在百度指數上搜索CSDN關鍵字，可以得到如下地域、年齡與性別分布：

由此可知，在中國，有相同需求的用戶群體基本具有如下共同特徵：

• 男性為主
• 年齡在20~29歲
• 主要分布在北上廣等發達城市或地區

進一步的，若考慮Stack Overflow等問答平台的核心用戶，則其典型用戶畫像如下：

• 用戶a

• 用戶b

• 用戶c

在二次構成用戶生態方面，個人認為，問答網站們或可考慮提供面向企業的諮詢服務，從而為類似用戶b、用戶c這樣的有一定經濟能力的子群體搭建專門的資訊交流平台，幫助系統性解決企業生產開發過程中可能遇到的各類問題，並從中收取一定量的中間費用。

產品規劃

新功能設計

對於Stack Overflow而言，希望能夠提供一個類似部落格分享的內容平台，進一步整合現有的問答平台中的各類資訊，從而為開發者提供一個系統化的學習交流環境，進一步促進社區的繁榮。

• Need需求

  現有的Stack Overflow各個問題彼此獨立，內容相對零散；用戶很難通過一個問題了解其背後設計的技術本質。

• Approach做法

  提供一個系統的部落格內容分享平台，幫助整合現有的問答平台中的各類資訊。

• Benefit好處

  滿足用戶需求，豐富相關功能，進一步提高競爭力。

• Competitor競爭

  與各類內容分享平台展開競爭，利用自身龐大專業的程式設計師用戶群體可對其實現降維式打擊。

• Delivery推廣

  可與Google等搜索引擎合作，提供相關部落格的查詢介面；同時在初期也可像知乎一樣，採用邀請制的方式保證內容的品質，確保核心用戶不因此流失。

對於CSDN和思否而言，兩者均已像這樣的全內容平台邁進，因此部落格分享或許不再是下一階段的功能重點。不過考慮到中國用戶的一些特徵，二者可以考慮實現一個在線IDE的編程體驗平台，對於某些提問中的場景進行簡單的在線模擬演示。

• Need需求

  CSDN和思否上存在一些相對容易的問題，這些問題可以藉助在線編程平台更好地加以演示。

• Approach做法

  模仿Leetcode、洛谷等，搭建這樣一個在線評測實驗平台即可。

• Benefit好處

  滿足用戶需求，豐富相關功能，進一步提高競爭力。

• Competitor競爭

  提供全新的特色功能，進一步彰顯自身的獨特性與權威性，吸引更多的新用戶。

• Delivery推廣

  可與Leetcode、洛谷等編程平台合作，也可與知乎等內容平台合作，在其上進行合理引流推廣。

團隊角色配置

第一個月：4人負責後端開發，2人負責後端測試，力求搭建完善的後端內容數據系統。

第二、三個月：2人負責前端UI介面設計，2人負責前後端API交互，2人負責前後端測試，確保前後端通訊無誤。

第四個月：1人負責部署，2人負責集成測試，1人負責市場推廣，1人負責介面美化，還有1人靈活調度，以備不虞。

開發周期規劃

第1周：進行市場調研，確定各部分功能與設計的風格、學習相應技術棧知識。

第2周：市場部門進行總體的需求彙報、確定目標用戶群體；技術部門集體學習完畢，完成開發環境的搭建和配置。

第3周：各組開始細化分工，前端整理設計所需素材，搭建基本布局；後端設計各類數據模型，繪製數據流圖。

第4周：開始前期框架搭建，美工完成主要UI設計；後端同步開發。

第5周：前後端實現功能1，周末開會總結。

第6周：前後端實現功能2，測試功能1，周末開會總結。

第7周：前後端實現功能3，測試功能2，周末開會總結。

第8周：完成功能基本測試，發布測試版，進行市場調研，搜集市場回饋。

第9周：整理市場回饋，進行項目目標和設計調整。

第10周：前後端完善功能1、2，美工進行設計修改。

第11周：前後端完善功能3，測試功能1、2、3，周末開會總結。

第12周：前後端加入功能4，最終完成1、2、3的測試。

第13周：完成功能基本測試，發布測試版，進行市場調研，搜集市場回饋。

第14周：整理市場回饋，由於時間緊張，僅選取重要且實現不太複雜的需求，制定後續項目任務。

第15周：前後端、美工簡單修訂，進行測試和部署。

第16周：完成部署，進行市場發布。