項目 | 內容 |
---|---|
這個做業屬於哪一個課程 | 2021春季計算機學院軟件工程(羅傑 任健) |
這個做業的要求在哪裏 | 案例分析做業要求 |
我在這個課程的目標是 | 進一步提高工程化開發能力,積累團隊協做經驗,熟悉全棧開發流程 |
這個做業在哪一個具體方面幫助我實現目標 | 結合實際的軟件開發案例,瞭解現有軟件功能特性與不足,並對其開發週期進行評估 |
自互聯網誕生之日起,全世界的程序員與編程愛好者們便逐漸聯合起來,自發地造成了一個個的社區和論壇。在搜索引擎尚未充分發展普及起來以前,問答型網站無疑成爲了程序員們解決平常生產的各種bug的一個聖地。面對那些一個個一言難盡的神奇Bug,即使是在互聯網已經充分發達的今天,要想在網上尋找到本身滿意的答案,這些網站也依然是許多資深程序員的第一首選。html
這其中,最具表明性的即是Stack Overflow,這個於2008年就已創立且一直繁榮延續至今的問答平臺。而在國內,目前較爲有名也有CSDN旗下的開發者互助問答社區,以及號稱『中文版 Stack Overflow』的Segment Fault。不過,雖然說是找bug的平臺,但這些問答網站自己是否也存在一些至今還沒有解決的Bug呢?藉着本次案例分析做業的契機,我也對這三個網站展開了時長近1月的深度調研,試圖努力找到這些幾乎立於『Bug之巔』的網站們本身的阿克琉斯之踵。前端
也順便體驗一把你問我答的快感吧vue
做爲一個專門面向程序員的問答網站,其所有的功能也理所固然地應當圍繞問答的整個流程加以展開。而問答的本質其實也是內容,在知識付費、全民閱讀的今天,如何可以精準高效地篩選出用戶想要看到的內容並以其喜聞樂見的形式呈現給用戶也是這些問答網站繞不過去的一道必答題。所以,『功能體驗』這一環節也將主要圍繞提問、回答、討論、評價、查詢與推薦這幾部份內容加以展開。python
首先是Stack Overflow。做爲目前程序員行業內無人不知、無人不曉的問答平臺,Stack Overflow在各方面都幾乎是無可挑剔。後面的全部問答網站也基本上是對它進行的拙劣模仿與本土化改造。進入網站後,其首頁的內容以下:c++
然而這密密麻麻的英文,對於一個非英語母語的人而言,第一眼看過去不說頭大但也多少是有點震撼的。特別是要想從這些信息中篩選出對本身有用的內容,就顯得更爲不易。不過,只要適應了英文的環境,當語言再也不成爲阻礙因素後,應該說Stack Overflow的頁面仍是很是清晰明白的。程序員
那麼,爲何有的問題是黃色背景,有的則是白色背景呢?算法
這確實有些反直覺,答案是:黃色背景的問題包含那些你已經watched
的Tag,而白色背景的則是你Ignore
或者並不關注的Tag。也就是說,經過背景色的設置,Stack Overflow但願你可以把更多的注意力放在你關心的那些tag對應的問題上;但同時,它也但願你可以經過瀏覽那些白色背景的問題瞭解一些你以前可能未曾瞭解過的領域內容。大概,這就是屬於程序員的浪漫了吧。數據庫
對於每一個問題,首頁中都會列出這個問題的得票數,回答數與瀏覽量,同時在右下角標記出它最新的提問/回答動態,能夠說基本上展示了每一個問題最核心的內容。編程
經過首頁的Ask Question
按鈕便可進入提問頁面,頁面內容以下:segmentfault
能夠看到,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專門提供了https://meta.stackoverflow.com/questions/tagged/bug這一頁面供用戶進行反饋,該頁面內容以下:
能夠看到,許多以前用戶反饋的bug如今都已經處於status-completed
的狀態,這就意味着該Bug已經被修復;而剩下,基本上都是一些Stack Overflow認爲無足輕重(鑽牛角尖)的內容了。不得不說,這一點Stack Overflow的的確確作的很好,也是充分發揮了其自身問答網站這必定位的長處。
下面是一些目前仍然存在的,被我發現的但在Stack Overflow方面看來可能『無足輕重』的bug。
可復現性:穩定復現
具體狀況:
如上圖所示,當一個用戶所持有的各種徽章數多到必定程度時,在其每一個回答的右下角的profile部分,最右邊的徽章數目就會溢出,致使沒法看到該用戶銅質徽章的數量,而只能進入該用戶主頁才能看到。
成因分析:
該問題的出現應當是由於Stack Overflow設置的這一窗口的大小是固定的,而且以後再未進行調整。因而當社區中出現大佬級用戶後,原有的窗口大小就容不下了。大概這就是有錢人的煩惱吧。
嚴重性:★★
改進建議:從新設定用戶的窗口大小,或支持自適應大小匹配。
可復現性:穩定復現
具體狀況:
如上圖所示,當搜索問題時輸入的字符數過多時(本此測試達到了2^20量級),查詢結果處就會出現溢出現象,即字符直接越過了頁面右側的廣告欄並超出了邊界。
成因分析:
這一方面說明Stack Overflow沒有像通常的搜索引擎那樣對輸入進行必要的截斷,同時也沒有考慮到會有用戶輸入這麼長的字符串的狀況;但另外一方面,其實這也偏偏證實了Stack Overflow對本身的搜索引擎頗有信心,根本不擔憂因輸入過長致使服務器崩潰的現象出現。
嚴重性:★★
改進建議:直接將容許輸入的字符的最大長度設爲一固定值便可;或者當待查詢內容過長時,對於搜索結果做人爲的換行處理。
可復現性:穩定復現
具體狀況:
如上圖所示,editing-help
頁面下拉至底部時,左側不會覆蓋底部黑色內容,右側則會;兩邊不對稱,顯得不太美觀。
成因分析:
一樣是前端頁面在設計時沒有將右側窗口嵌入白色界面部分所致。
嚴重性:★
改進建議:前端界面進行優化處理便可。
可復現性:穩定復現
具體狀況:
如上圖所示,主頁右上的achievements窗口在沒有achievements時,文字緊貼邊界,絲毫沒有任何頁邊距所言,確實很很差看;但對於程序員而言,或許無礙大局。
成因分析:
一樣是前端頁面在設計時沒有充分細緻地加以考慮所致。
嚴重性:★
改進建議:前端界面進行優化處理便可。
what's this?
靠邊界太近,不太美觀可復現性:穩定復現
具體狀況:
如上圖所示,主頁左側的What's this?
太過靠近頁面邊界,顯得不太美觀。
成因分析:
一樣是前端頁面在設計時沒有充分細緻地加以考慮所致。
嚴重性:★
改進建議:前端界面進行優化處理便可。
定性來講,我對Stack Overflow的評價是 e) 很是推薦
。相比於接下來即將登場的兩大問答網站而言,Stack Overflow不管是從用戶、回答的質量仍是各項功能的設計上都堪稱完美。我在找它的bug上也是花費時間最長,且所獲成果最少的。
定量來講,基於鄒欣老師給出的評分標準給分以下:
描述 | 評分 | |
---|---|---|
核心功能 | 分析三個核心功能,功能設計和質量。 | 10 |
細節 | 有什麼爲用戶考慮的細節? | 10 |
用戶體驗 | 當用戶完成功能時,不干擾用戶 | 10 |
輔助功能 | 一些輔助功能如皮膚等 | 8(聲望、顏色、投票等) |
差別化功能 | 這個軟件獨特的功能. 它對用戶的吸引力有多大? | 9(社羣與高質量的內容是吸引力的核心) |
軟件的效能 | 佔用內存, 啓動速度, 內存泄漏狀況 | 10 |
軟件的適應性 | 在聯網/斷網, 大小屏幕, 沒有鼠標的狀況下均可以順暢操做. 和不一樣平臺的軟件能流暢協做 | 5(畢竟是外網,多少不太方便) |
成長性 | 記住用戶的選擇, 適應用戶的特色,用戶越用越方便 | 8(問題類似度算法有待完善) |
用戶有控制權 | 系統狀態有反饋,等待時間要合適。關鍵操做有確認提示,有明確的錯誤信息。 讓用戶方便地從錯誤中恢復工做, 快捷操做鍵可調整。 | 10 |
內容質量與社區繁榮度 | 問答話題的平均質量,每一個問題的平均響應時間,總的瀏覽量等 | 10 |
總分 | 90 |
與Stack Overflow不一樣,CSDN的問答社區顯然不是CSDN旗下的主打產品。其問答首頁以下圖所示:
能夠看到,頁面的入口首先必需要從上方的『問答』按鈕點擊進入,而『首頁』則幾乎看不到關於問答社區的相關內容。在進入該頁面後,也一樣能夠看到目前最新的問題,但與Stack Overflow相比,首先左側多了『頻道』這一子版塊,其次每個問題缺乏了votes
這一屬性;而且彷佛也不像Stack Overflow那樣利用背景顏色的區別篩選出用戶可能感興趣的問題和可能不感興趣的問題。
那麼CSDN爲何不這麼作呢?
由於沒有這個必要。在這個社區裏,基本上過上幾分鐘纔會冒出一個新的問題,也就是說問題自己產生的密度就不高;那麼若是CSDN再去採用推薦篩選機制的話,可能用戶在較長一段時間看到的都是相同的幾個問題,那麼這樣的效果或許反而還不如直接展現目前『最新』或『最熱』的問題給用戶的體驗更好。
一樣經過問答首頁的『提問題』按鈕便可進入到提問頁面,該頁面的內容以下:
能夠看到,與Stack Overflow的內容板塊相比,CSDN問答社區的內容異常簡單:
不過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:
可復現性:穩定復現
具體狀況:
經過問答首頁右側的『用戶榜』能夠看到當前採納榜排名最高的前幾位用戶的信息:
注意到這裏有一位名叫oyljerry
的用戶,採納榜單顯示他的回答共有1644次被採納。然而在點進這位用戶的主頁後,卻發現:
這位用戶的總的問答數竟然只有2條!而他回答的問題更是一個也沒有!
很難想象排行榜中那麼高的採納數到底是怎麼產生的,至少按照其主頁的回答數來看,這位用戶平均每一個回答的問題被採納次數應該是正無窮纔對。
另外一方面,就我本人而言,首頁信息欄上顯示個人回答數爲4:
點進去以後,主頁裏顯示個人有效回答又只有2條:
這還沒完,以前因爲找bug的須要(詳情可搜索xss攻擊),我在CSDN社區提了一些很奇怪的問題,並在這些問題下面作了不少回答,這些能夠從『個人提問』中看到:
固然,後來由於審覈緣由,這些回答和提問都被斷定爲『無效內容』而被官方屏蔽了(這點CSDN動手得倒挺快)。可是問題來了,首頁信息欄裏的4條回答究竟是怎麼算出來的?不管加不加上這些非法的回答,都不該該是4條啊?
成因分析:
CSDN的後端數據庫應該沒有作到正確的同步,而且對於這些回答數的計算也沒有在官方給出一種有效的斷定方式,所以最終致使了這一現象的產生。
嚴重性:★★★
改進建議:從新設計合理的統計算法,後端數據庫從新設計相應的數據模型,從而確保各處數據一致性。
可復現性:穩定復現
具體狀況:
如上圖所示,當使用CSDN的搜索功能時,首先其默認的搜索範圍是全站,所以要想專門搜索『問答』相關的內容,就必需要到『更多』中加以選擇。
但尷尬之處在於,從『更多』到『問答』,這中間有一段不能忽視的距離。所以,只要用戶試圖直接將鼠標『更多』移動到『問答』上,那麼這個彈出的浮動窗口就會直接中途消失!
所以,用戶的惟一選擇,就是在點擊『更多』後,老老實實地把鼠標垂直向下移動,然後再移到『問答』按鈕的位置上。這極易帶來用戶使用體驗的大幅降低。固然,或許也可從側面證實『問答』版塊是有多麼的不受待見了。
嚴重性:★★
改進建議:增長彈出窗口的停留時間,或者從新調整該窗口的佈局以與用戶的使用習慣兼容。
儘管單就這裏列出來的bug數而言,CSDN問答社區看上去甚至要比Stack Overflow還要少,但這並不表明CSDN就比人家厲害了。畢竟不少功能上的先天性不足沒有被放到這裏的bug列表中,而是直接在以前的功能體驗部分就介紹過了。
這就比如一個天生坐輪椅的人跟一個後天腳踝扭傷的人炫耀他歷來走路都不會扭到腳同樣,毫無心義可言。
定性來講,我對CSDN問答社區的評價是 c) 通常
。也就是除非你無事可作,否則刻意去上面看的話,很難學到什麼東西;但若是你在百度的時候無心中搜到一個排名很高的來自該社區的回答,那麼點進去看看或許對你也是有幫助的。
定量來講,基於鄒欣老師給出的評分標準,給分以下:
描述 | 評分 | |
---|---|---|
核心功能 | 分析三個核心功能,功能設計和質量。 | 6(及格萬歲的可愛麻雀) |
細節 | 有什麼爲用戶考慮的細節? | 7(簡單粗暴就是最好的) |
用戶體驗 | 當用戶完成功能時,不干擾用戶 | 7(廣告可很多) |
輔助功能 | 一些輔助功能如皮膚等 | 7(有樣學樣,但沒學到精髓) |
差別化功能 | 這個軟件獨特的功能. 它對用戶的吸引力有多大? | 7(CSDN是吸引力的源泉) |
軟件的效能 | 佔用內存, 啓動速度, 內存泄漏狀況 | 10 |
軟件的適應性 | 在聯網/斷網, 大小屏幕, 沒有鼠標的狀況下均可以順暢操做. 和不一樣平臺的軟件能流暢協做 | 10 |
成長性 | 記住用戶的選擇, 適應用戶的特色,用戶越用越方便 | 8(中規中矩) |
用戶有控制權 | 系統狀態有反饋,等待時間要合適。關鍵操做有確認提示,有明確的錯誤信息。 讓用戶方便地從錯誤中恢復工做, 快捷操做鍵可調整。 | 10 |
內容質量與社區繁榮度 | 問答話題的平均質量,每一個問題的平均響應時間,總的瀏覽量等 | 7(見上文分析) |
總分 | 79 |
Segment Fault(又稱思否,下文兩詞同義)也是一家國產的小有名氣的問答網站,從它的名字就能夠看出,這家公司創立之時的野心絕對不小:但願打造一家中國的Stack Overflow。那麼時至今日,它是否真的作到了呢?從我目前的調查來看,很遺憾,答案是尚未;但好消息是與CSDN相比,思否作的仍是比較不錯的。
其主頁以下圖所示:
哦不對,這張彷佛不該該做爲一個問答社區的主頁,因而真正的問答主頁以下圖:
因而可知,思否與CSDN同樣,近年來也有逐漸將問答版塊降格,向全平臺內容社區轉型的趨勢。但至少人家骨子裏仍是一個問答社區,因此從這張界面圖上看,能夠發現思否與CSDN、Stack Overflow相比,有以下特色:
tag
,無固定頻道,能夠根據tag
搜索;votes
版塊,這點與CSDN保持一致;仍是經過首頁的『提問題』按鈕,進入提問頁面:
能夠看到,與Stack Overflow和CSDN相比,思否的提問頁面顯然是有優有劣。
先說優勢:
所見即所得
與Markdown
兩種不一樣的寫做方式,兼容性很強;再說缺點:
目前我在思否上提了這樣一個問題:
截至博客發佈,也仍是沒人理我,連個吐槽的都沒有。
不過對於問題,思否支持『關注』、『收藏』、『點贊』這幾個傳統技能,仍是比CSDN作的要完善很多的。
在Segment Fault中,總體上問答內容的質量要介於Stack Overflow與CSDN二者之間,基本上也找不到CSDN中那種過於簡單的新手問題。找了一下子以後,我最終找到了這樣一個與python相關的還算簡單的問題:
能夠看到,與CSDN中相比,提問者的素養明顯高了不少:將其所提問題涉及到的代碼用代碼塊包裹了起來,極大地加強了可讀性;同時問題的內容描述得也很是清楚,讓人一看就能明白他想要問什麼。
事實上,在這以後,這位題主還經過思否中的『評論』功能進行了自問自答:
能夠說,這個答覆基本上算是很詳細地給出了原問題的一個最優解。所以,我後面的回答僅僅只是提供了一個參考文檔,而且結合題主的原模型作了一點針對性的補充。
個人回答以下:
目前,該回答既沒有被採納,也沒有獲得任何反饋;大概是題主本人已經再也不關心這個問題了吧。
據此可知,在思否中,也一樣較完善地支持了問答相關的基本功能,包括提問、回答、評論、點贊/踩、收藏、關注等。此外,與Stack Overflow同樣,思否也容許其餘用戶對現有回答進行編輯,而且在審覈後決定是否修改有效——這也確實是思否的一大亮點。固然,因爲客觀緣由,思否並不支持像Stack Overflow那般把全部的修改記錄都公開給用戶,但可以支持用戶的自由修改,對於問答社區而言,已是很是難能難得的一件事了。
查詢方面,思否也是隻提供了一個統一的面向全平臺的查詢接口,固然這能夠理解爲其想要進一步爲它新增的那些其餘功能作推廣,積累流量。不過好在『問答』版塊在思否這依然佔據着舉足輕重的地位,所以搜索後能夠直接選擇查找問答欄目下的相關話題。
但遺憾之處在於,這裏思否也一樣不支持類似問題推薦系統,即用戶沒法在搜索框中鍵入的同時得到系統自動爲其推薦的最類似問題的信息,這一點可能要稍遜CSDN一籌。
此外,在點擊首頁右方的相應標籤後,便可進入該標籤對應的子問題頁面:
這裏明顯能感受到比首頁的信息密度大了許多,而且得票
信息也可以呈現出來;但話又說回來,既然有這個屬性,爲什麼再也不首頁就展現呢?
評測環境與Bug嚴重性表格可參見Stack Overflow的相關內容。
雖然Segment Fault總體上給人的觀感明顯要好於CSDN,可是它的Bug卻出人意料的多,並且還有很多Bug的重要程度至關之高,說實話這是我一開始沒有料到的。
可復現性:較難復現
具體狀況:
其實xss攻擊是我在拿到本次案例分析做業後第一件想幹的事,這點細心的讀者在我以前的內容中或許就已經能夠窺知一二(提示:Stack Overflow中的提問、CSDN中的非法問題)。但爲何到如今才終於提到它呢?由於以前的兩個網站,我在屢次嘗試後所有都以失敗了結,甚至在CSDN中付出了帳號被凍結一天的代價。而到了Segment Fault這裏,我本人也沒有成功。
但諷刺的是,當我在它的問答中搜索有關內容時,卻找到了這樣一個問題:
而在這個問題的下面,居首的有這樣一條答覆:
再一看日期,竟然就是今年3月份的事!
也就是說,在Segment Fault這裏,xss攻擊是能夠實現的!而一旦能夠實現,就意味着這個網站可能會出現一些很是可怕的漏洞,甚至會出現用戶隱私泄露的狀況(具體內容感興趣的同窗可自行百度xss攻擊),後果將不堪設想。
但遺憾的是,這位答主至今還未回覆個人評論,因此我也不知道具體的實現方式,反正能夠確定不是通常的法子。
成因分析:
多是思否在前端頁面的處理或者是先後端的通訊部分沒有進行很是細緻的處理,以致於出現了xss攻擊的漏洞。
嚴重性:★★★★
改進建議:從新複查先後端代碼,確保覆蓋了全部與xss攻擊有關的漏洞測試。
可復現性:穩定復現
具體狀況:
實驗證實,當在首頁的搜索框內鍵入的字符串長度超過8167時,網頁就會崩潰,顯示的反饋信息以下:
相似的狀況也在Stack Overflow與CSDN中均進行過測試,前者不只不會報錯,並且不會截斷字符,但最後的反饋結果會略顯不美觀;後者則會直接採用截斷的方式進行處理,避免了過長字符串的溢出。
而到了思否這裏,則是什麼都沒有作,只要搜索長度大於8167,頁面就崩潰了。
成因分析:
前端沒有對輸入的長度進行檢查,後端在收到前端傳來的字符串後也沒有及時作出檢驗進行異常的處理,最終致使了網頁的奔潰。
嚴重性:★★★
改進建議:增長對搜索輸入字符串長度的限制——儘管通常不多有用戶會輸入如此長的字符,但對於一家成熟的網站而言,數據溢出仍是一個必需要考慮的問題。
可復現性:穩定復現
具體狀況:
從問答首頁點擊右側標籤窗口中的『管理』按鈕,便可進入標籤頁面;在該頁面的輸入框中輸入超長標籤後,頁面效果以下:
能夠看到,在『建立標籤』提示框中,輸入的字符串直接溢出到窗口以外,覆蓋了原有的一部分已關注標籤,極大地影響了頁面美觀程度,影響力用戶體驗。
成因分析:
前端沒有考慮到標籤長度過長的狀況,既未對此加以限制,也未對此進行渲染效果的優化。
嚴重性:★★
改進建議:可限制標籤的最大長度,從而從根源上杜絕此類現象的發生。
可復現性:穩定復現
具體狀況:
在上文提到的標籤管理頁面,將鼠標移至任意一個已關注標籤上時,便可彈出該標籤的一些基本信息,注意到這裏顯示的vue.js
標籤的關注人數爲136897人。
但同一時刻,當咱們點擊該標籤進入到該標籤對應的問答頁面中,能夠看到vue.js
的實際關注人數爲136938人:兩邊的數據並不一樣步。
成因分析:
不難發現,前者的關注人數小於後者;據此推斷,前者的關注人數應當是用戶在最後一次對該標籤進行更改時(即點擊關注/取消關注)該標籤對應的關注人數,然後者則是該標籤此時的最新關注人數。即,這裏出現了數據一致性異常的問題,推測多是思否爲了實現方便,將關注人數做爲用戶關注標籤的一個屬性加到了用戶這一側的信息列表中,而再也不對其進行實時更新,故而致使了用戶界面查看標籤信息時出現了更新滯後的問題。
嚴重性:★★★★
改進建議:從新設計後端數據模型,將該關注人數設置爲該標籤實時的關注人數;前端在每次查詢時應直接獲取到該標籤相應的最新關注人數屬性,而非直接去用戶的標籤列表中調相關信息。
可復現性:穩定復現
具體狀況:
仍是在上文提到的標籤管理頁面,當向文本框中輸入字符'<'
時,就會自動忽然彈出建立標籤的窗口;特別地,若此時用戶的輸入包含用雙引號""
引出的相關內容,則該部份內容會直接神祕消失。效果以下:
首先輸入hello"world"
:
接下來鍵入'<'
字符,則會馬上彈出建立標籤的窗口:
且彈出窗口中再也不包含"world"
信息。
成因分析:
多是思否在標籤建立這裏設置了一些不爲用戶所知的正則匹配算法,致使了當用戶輸入某些特殊字符時,就會被系統默認爲執行了某種操做,甚至致使數據丟失現象的出現。
嚴重性:★★★★
改進建議:檢查與建立標籤相關的先後端邏輯,看看是否有哪裏的實現存在一些欠考慮的問題;如真是官方有意如此,則應在用戶能夠看到的地方加上必要的說明,以幫助瞭解相關的邏輯和原則。
可復現性:穩定復現
具體狀況:
點擊問答首頁右上角的我的頭像,從彈出的窗口中選擇『個人主頁』,從而進入用戶的我的主頁:
在我的主頁中點擊左側『關注了X人』按鈕,便可彈出上圖中的相關頁面。
在搜索框中鍵入字符,便可匹配到類似用戶的信息。但此時有以下問題:
成因分析:
其餘兩個網站都不支持這裏的搜索式添加關注,顯然是考慮到了搜索效率太低帶來的負面影響,要從技術層面上解決,可能須要優化字符串匹配的底層實現算法等問題;至於大寫字母沒法輸入,推測可能又是系統自行設定的某種不爲用戶所知的約束,但這確實讓人以爲有些莫名其妙。
嚴重性:★★★
改進建議:使用更高效的搜索算法,或者直接把這個功能砍掉——由於看不出在這裏加個搜索框對於一個問答軟件而言的意義何在。
可復現性:穩定復現
具體狀況:
在每一個問題頁面下方,都有一個『撰寫回答』的版塊,用戶能夠在這裏鍵入他們對這一問題的回答。注意到這裏有一個黃色的提示框,告訴用戶也能夠使用評論功能。這個提示框右上角有個'x'
按鈕,彷佛說明這個提示框能夠關閉;但事實上是,不管你怎麼瘋狂地點擊這個'x'
,提示框都沒法關閉——這顯然客觀上會對用戶的回答體驗形成必定程度的干擾。
成因分析:
應該是在前端頁面設計時,沒有與後端作好正確溝通:後端或許本就不但願關閉這個提示框,但前端卻提供了一個看似能夠關閉的組件,進而引起了沒必要要的誤會。
嚴重性:★★
改進建議:從新設計前端頁面便可。
思否雖然bug比較多,但總體的使用體驗上仍是要略勝CSDN一籌的。所以定性來講,我對其的評價是 d) 好,不錯
。對於一箇中文編程開發者而言,若是在語言上存在必定障礙的話,那麼思否或許是Stack Overflow一個不錯的替代品。
定量來講,基於鄒欣老師給出的評分標準,給分以下:
描述 | 評分 | |
---|---|---|
核心功能 | 分析三個核心功能,功能設計和質量。 | 8(中規中矩的簡潔) |
細節 | 有什麼爲用戶考慮的細節? | 7(小問題有點多) |
用戶體驗 | 當用戶完成功能時,不干擾用戶 | 8(廣告有但很少) |
輔助功能 | 一些輔助功能如皮膚等 | 8(簡潔大氣的UI) |
差別化功能 | 這個軟件獨特的功能. 它對用戶的吸引力有多大? | 10 |
軟件的效能 | 佔用內存, 啓動速度, 內存泄漏狀況 | 10 |
軟件的適應性 | 在聯網/斷網, 大小屏幕, 沒有鼠標的狀況下均可以順暢操做. 和不一樣平臺的軟件能流暢協做 | 10 |
成長性 | 記住用戶的選擇, 適應用戶的特色,用戶越用越方便 | 8(中規中矩) |
用戶有控制權 | 系統狀態有反饋,等待時間要合適。關鍵操做有確認提示,有明確的錯誤信息。 讓用戶方便地從錯誤中恢復工做, 快捷操做鍵可調整。 | 10 |
內容質量與社區繁榮度 | 問答話題的平均質量,每一個問題的平均響應時間,總的瀏覽量等 | 8(見上文分析) |
總分 | 87 |
基本信息:
田同窗(非本人),也是1806計算機學院的一員,有着極爲豐富的程序開發經驗。
選擇緣由:
一方面,田同窗的編程開發經驗豐富,在極客問答方面有着較其餘人更爲多樣化的需求;另外一方面,田同窗曾屢次在計算機學院的水羣裏鼓勵你們去Stack Overflow上提問,給我留下了極爲深入的印象。
主要需求:
通常是遇到沒法本身解決的問題纔會上Stack Overflow搜索答案,如今也已不多在上面回答問題。
使用產品:
Stack Overflow爲主,其主要功能包括提問、回答、查詢等均充分體驗過
附採訪文字記錄以下:
問答網站前端的頁面搭起來應該並不難,如今也有了Vue這樣比較簡潔方便的框架,再加上專業UI的支持。所以,我認爲該類型網站的幾大核心難點主要有:
假設目前這些核心功能都須要咱們從零開始實現的話,那我認爲至少須要6個月,也就是24周的時間。其中市場調研+需求設計1個月,這四大類功能的實現和測試各1個月,UI設計這期間同步進行,最後一個月用於產品總體的集成測試與封裝上線。
但這只是一切的開始,要想真正構建一個同Stack Overflow同樣繁榮的問答社區,那我認爲就毫不是一年半載的光景了,也不是一個純技術的問題了。
與CSDN問答社區和Segment fault相比,Stack Overflow在用戶羣體規模、問答內容質量等各方面基本上都處於碾壓的水平。可能惟一美中不足的就是它的UI設計的比較復古,如今來看可能顯得有些過期,致使用戶的閱讀體驗(特別是非英語母語選手)可能會相對低一些。
因爲問答社區的類似產品不少,故這裏僅考慮Stack Overflow(SO)、CSDN問答社區(CSDN)與Segment fault(SF)這三者之間的相對排名,以下表所示(針對國內用戶羣體而言):
功能 | 軟件排名 |
---|---|
問答內容質量 | SO>SF>CSDN |
社區規模 | SO>SF>CSDN |
內容編輯器功能與美觀程度 | SF>SO>CSDN |
軟件響應速度(問題搜索與推薦) | CSDN>SF>SO |
UI界面美觀度 | SF>CSDN>SO |
用戶學習曲線難度 | CSDN>SF>SO |
整體使用體驗 | SO>SF>CSDN |
經過上述分析,我認爲Stack Overflow團隊目前亟需增強的可能正是它的前端UI界面設計方面。相比於其餘後起之秀,Stack Overflow的UI太過簡陋,且文字信息量較高,密度較大,看久了確實容易引發人心理不適,形成過分疲勞。
所以,我但願Stack Overflow可以在這方面做進一步的優化,具體策略以下:
而CSDN的主要問題則在於各方面功能設計的都不太細緻,固然這可能與其用戶的總體質量有關;具體而言,我認爲其最須要增強的應該是提問與問答頁面的佈局設計和功能升級,具體策略以下:
思否的主要問題在於一些細節上的進一步推敲,這些內容能夠參見上文功能評測的相關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
關鍵字,能夠獲得以下地域、年齡與性別分佈:
由此可知,在國內,有相同需求的用戶羣體基本具備以下共同特徵:
進一步的,若考慮Stack Overflow等問答平臺的核心用戶,則其典型用戶畫像以下:
屬性 | 特徵 |
---|---|
年齡 | 18~22歲 |
專業 | IT相關專業 |
學歷 | 大學本科 |
收入 | / |
表面需求 | 解答專業課程學習中遇到的問題 |
潛在需求 | 接觸到相關領域的頂級專家精英、拓寬知識面 |
人均消費水平 | 5-15(美)元/月 |
屬性 | 特徵 |
---|---|
年齡 | 20~28歲 |
專業 | IT相關專業 |
學歷 | 大學本科、研究生、博士 |
收入 | 10w(美金)左右 |
表面需求 | 解答平常生產開發中遇到的工程問題 |
潛在需求 | 接觸到相關領域的頂級專家精英,瞭解潛在個體升值空間 |
人均消費水平 | 15-50(美)元/月 |
屬性 | 特徵 |
---|---|
年齡 | 28~38歲 |
專業 | IT相關專業 |
學歷 | 大學本科、研究生、博士 |
收入 | 30w(美金)左右 |
表面需求 | 回答領域相關各種問題、積累我的聲望 |
潛在需求 | 精準招募行業內相關人才 |
人均消費水平 | 50(美)元/月以上 |
在二次構成用戶生態方面,我的認爲,問答網站們或可考慮提供面向企業的諮詢服務,從而爲相似用戶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、三個月: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周:先後端完善功能一、2,美工進行設計修改。
第11周:先後端完善功能3,測試功能一、二、3,週末開會總結。
第12周:先後端加入功能4,最終完成一、二、3的測試。
第13周:完成功能基本測試,發佈測試版,進行市場調研,蒐集市場反饋。
第14周:整理市場反饋,因爲時間緊張,僅選取重要且實現不太複雜的需求,制定後續項目任務。
第15周:先後端、美工簡單修訂,進行測試和部署。
第16周:完成部署,進行市場發佈。