BugPhobia展現篇章：學霸在線系統Alpha階段展現

0x00：序言

1 universe, 9 planets,

204 countries,809 islands, 7 seas,

and i had the privilege to meet you.

BugPhobia，我所言，均是心之所向。

 

0x01 ：團隊成員簡介

To the world, you maybe a person.

But to a person, you maybe the world.

         To the searching tags, you may well fall in love with http:// 10.2.26.67

　　

　　

　　

　　

　　

　　

　　 

 

0x02 ：團隊項目願景

Search With Tags~，或許做爲軟件工程的開發者，你會將學霸在線網站視爲「爬蟲組」和「數據組」等前端外殼；或許做爲用戶，你會將學霸在線網站視爲一處搭建的問答平臺，但事實，咱們不侷限於一個最簡單的外殼，用戶（User）、問答（Question）、課程（Course）、資源（Resource）、豐富的神祕功能（Secret）均是咱們的工做，咱們致力於打造面向CS/EE領域的垂直搜索引擎，且不忘初心。

網站基本定位	面向CS/EE領域的垂直搜索引擎
網站創新形式	首先，按照《構建之法》中創新類型的劃分，在創新的類型上，咱們的產品是改良型的創新，而非顛覆性的創新
用戶基本定位	計算機及相關專業學生，其中以大學生羣體爲最主要的用戶羣
用戶的知識層次	用戶具有基本的編程基礎，並具有使用通用搜索引擎（百度、谷歌等）的能力
網站的基本功能	網站可以採集專業化社區中的問答數據、高質量課程資源、專業技術文檔中的內容，爲使用者提供一體化的、精準的、高質量的搜索內容 同時，用戶可以經過網站直接參與到上游社區的討論中

所以，根據Alpha階段的基本功能：完善的用戶個性化管理、完備的問答資源爬取、完善的搜索引擎架構，咱們將用戶精肯定位於計算機系的「對專業課程、概念和軟件使用有着大量需求」的學生羣體，和非計算機專業的「對計算機相關概念和理解有着問答需求」的學生羣體。

名字	王曉文	李茹欣
用戶身份	某校計算機系學生，在專業課的大海中是一條淡水魚	某校經管學院學生
年齡	21歲	20
用戶所佔市場比例	45%	10%
用戶重要性	很是重要，標註5顆星，可謂是咱們的主體用戶。	比較重要，在問題的貢獻領域有不容忽視的做用。
使用此軟件的典型場景	查找各類計算機專業相關的資料，完成相應的做業任務；翻閱各類技術文檔完成學業相關的研究任務；查閱課業以及研究任務以外的行業相關的知識	須要在計算機等級考試中查詢計算機相關的基本概念和基本工具的用法。
使用此軟件的環境	主要環境是教室，宿舍，實驗室。家中，地鐵以及其餘地方也能夠成爲使用該軟件的次要環境。	主要環境是教室，宿舍，實驗室，家中。
生活工做狀況	常常爲了完成做業或實驗室的任務而做息不規律，而且在此過程當中須要查閱大量的相關技術和概念。	茹欣學習認真，可是做爲文科生，在計算機等級考試備考時，面對大量的計算機相關的概念知識以及從未接觸過的工具軟件，茹欣感受到有比較大的壓力。
只是層次和能力	瞭解計算機的專業知識，具備比較熟練的編程技能和應用專業軟件的能力。	茹欣對計算機相關概念沒有深刻接觸過，平時使用計算機更多的是上淘寶，蘑菇街等購物網站購物。
用戶的動機	曉文常常會遺忘一些已經學習過的專業知識，但由於須要的相關知識太多且沒法在有限的書籍中快速找到答案，他更傾向於求助網絡，尋求答案。	茹欣但願可以在網上快速查找到計算機相關的概念，對於基礎的編程語言的語法和基本的計算機軟件的使用有比較簡短和易於理解的介紹，從而能夠應對計算機等級考試的試題。
用戶的困難	現有網絡的內容龐雜而繁複，很難在有針對性地找到滿意的答案，曉文的大量的時間就在甄別與篩選過程當中浪費掉。	計算機相關的概念和知識很是龐雜，如欣對基本工具軟件的使用也不是很熟，茹欣感受到有比較大的壓力，網絡資源的繁雜，概念的不統一，說法的不一致也讓茹欣感到比較頭疼。
用戶的偏好	傾向於使用網絡做爲獲取答案的途徑，但願快速定位到與本身的問題相關的內容。	茹欣喜歡深刻淺出的使用教程和介紹，但願常見的問題能夠獲得快速的解答。

 

0x03 ：團隊項目基礎架構

前端頁面	直接與用戶打交道，與用戶進行交互
後端系統	負責處理用戶的請求，並銜接搜索系統，爲用戶提供其想要的數據
搜索系統	負責蒐集、整合數據，並響應網站後端的搜索請求，提供搜索結果

 

 

 

0x04 ：團隊項目協做分工和基本反思

0x0400：項目基本的用戶反饋

首先，請容許bugphobia團隊對您的訪問給予感謝以及誠懇的致歉。受服務器端的硬件限制，原始的學霸在線系統網頁訪問困難，常常出現點擊圖標無響應，或註冊、登錄等基礎功能沒法訪問的狀況，給您形成了極其不良的第一印象，bugphobia團隊必須對您致以誠懇的歉意。在舊版服務器基礎上搭建的網站，在上線後收到了大量用戶的第一時間的投訴和反饋

 

所以，在性能嚴重影響應用的服務器上，團隊項目自己未能表現原有的大量功能，形成了極其嚴重的「發佈」事故，但也同時很是感謝用戶的快速體驗，可以使得團隊在第一時間終止了其餘媒體的發佈，避免影響進一步擴大，而團隊在11月16日第二次發佈前嚴格依據標準對服務器和網站自己進行了大量而全面的的響應式、壓力等方面測試：

測試人員	服務器壓力測試基本經過，服務器可以承受必定規模的響應，並能完整模擬用戶的所有功能體驗
前端人員	Secret功能從新遷移部署到服務器端，同期更新Semantic UI框架和Django框架至最新版本
後端人員	緊急修復在此期間測試人員提交的BUG，並從新配置服務器端的基礎環境和嚴格版本控制的文件傳輸

【備註： 服務器爲北航內網服務器，外網訪問時極易出現ERR_CONNECTION_TIMED_OUT的響應問題，請您在確認網絡的鏈接情況】

 

0x0404：項目基本的協做關係

在此前的Django-Semantic UI框架的先後端對接中，架構成員已經對網頁自己的架構有着清晰的解釋，所以，在項目中團隊基本處於「主導者-協同者」的關係模式進行小範圍的交流和討論工做。

之前後端的對接爲例，在第一輪迭代中，爲充分確保開發效率

ü  先後端首先協商制定「由前端人員整理頁面的基本需求，以頁面維護文檔的方式首先將必要數據源展現給後端，後端人員負責調研相關數據的實現可行性」

ü  前端人員依據本身整理的「數據源」（此處暫時忽略設計人員和前端人員的交互過程，爲提升效率均以文檔方式給出），設計合理的佈局方案並經過Semantic UI儘量模塊化的實現

ü  後端人員須要對前端人員整理的「數據源」給出合理的建議，同時調研可行性後完成Django框架和Semantic UI框架的總體對接

 

0x0408：軟件工程質量評估

        先後端調查問卷質量評估，預計將在網站第二次發佈後的2~3天內完成，並依據此階段的調查問卷進行需求變動的敏捷開發。在需求反饋上，將在發佈近期完成用戶羣組的搭建和反饋的實時接收機制，保證第二輪迭代過程當中能優先挖掘用戶所注重的功能，這裏先給出第一輪迭代結束前的調查問卷結果彙總，將優先針對第2~3類用戶羣體進行相關資源的優化和推薦：

計算機應用能力-常常搜索問題的自變量-因變量交叉分析條形圖

        測試評估，測試人員將測試評估主要集中於服務器自己性能和白盒測試樣例，並盡力在服務器端完成自動化壓力、安全測試腳本以充分保證每一輪迭代後服務器自己資源知足開發需求。測試代碼上，BugPhobia團隊設置爲閉源管理，不將測試代碼開源，但會給出必定的後續的測試報告

        文檔資源評估，這次開發文檔管理自己資料齊全，儘量保證單頁面對應單維護文檔的一一對應關係。同時文檔的版本管理也幫助項目經理去動態的制訂進度，總體評估效果優良。

 

0x040c：團隊項目實際進展

 

燃盡圖具體數聽說明

系列1：預約目標（藍色直線），是指代預期目標 系列2：實際日均（橙色直線），按照團隊自己的實際開發天數，天天應該作到的量 系列3：實際完成（灰色直線），實際完成的工做量

燃盡圖基本符合項目的進展情況：「高額學習成本消化期」—「數據對接停工期」—「敏捷開發高效進行」的階段，具體的解釋，將在0x05 團隊協做的反思中給出進一步的詳細的解釋和說明

 

0x05 ：團隊協做的反思

0x0500：教堂 OR 集市團隊

恐怕最慘痛的教訓正是源於「集市式」的管理思惟。

 

集市式管理方式積極端

高效且積極的開發效率 ü  初期根據高昂的學習成本，制定了架構師和團隊其餘成員的結對編程方案，同時立會時特別依據各人的疑問和困惑進行解答，保證了團隊在重構輪子的初期不會由於高昂的學習成本而嚴重拖延進度； ü  中期根據他組的協商結果，制定了依據「必定原則」的儘量獨立效率編程，雖然說在最終的耦合結果並不理想，但這次嘗試也基本確立了團隊各成員的基本開發方向，開發溝通渠道的思路； ü  後期，根據敏捷開發的剩餘需求，採用先後端對接方式的結對編程，極其高效地完成了各部分的收尾工做。         管理方式靈活高效 ü  自主申請任務，確保思路靈活，開發高度積極 ü  各任務均存在必要負責人

 

集市式管理方式弊端

缺少高度的責任制管理 ü  每日立會、每日例會、每宿舍例會均是正常進行，不管是初期的結對編程「培訓」或是中後期的數據對接上，此方面的立會均能有效保證先後端的高效對接，在必定程度上彌補了中期任務分配失衡的錯誤；但最核心的問題，就是負責人的指定，也就是責任的單一化！所以，手中積累了大量的鬆散記錄和項目草圖，卻一直未能有效整合；同時，負責維護的少年也對內容審覈過於嚴苛，致使文檔發佈拖延形成了嚴重的後果。如今回顧，若當初可以將責任高度單一化，並確保能力足夠，可能進展會更爲順利         用集市搭建了教堂，卻忽視了「興趣」和「責任」的非等價關係 ü  咱們順利地採用集市式的模式完成了幾份高質量的做品。一我的初稿、一我的複審迭代更新、一我的再度審覈排版等等，每一個人都出於我的的責任、榮譽以及興趣等複雜情感，深刻地參與到了整個過程當中。雖然沒有很是明確的安排，可是你們都主動承擔了某一部分的任務。咱們用集市搭建起了一座教堂。 ü  以前的成功使得咱們沒能認清楚上面所敘述的一些本質性的東西，從而致使了後面的問題。我認爲其中最主要的是第一條：項目必須首先是你感興趣的，最終對其餘人有用的。以前構築的一系列文檔，源自團隊中對於文字有執着追求的青年的努力，也源自團隊自身開發設計的需求，所以，你們參與得較爲深刻。特別是一些每一個成員都可以用到的文檔，好比設計文檔、需求分析等等。然而，咱們沒有認識到'每日立會'的會議記錄的做用，於是也沒有人對其感興趣。你們都以爲，這個東西彷佛沒那麼重要，沒有給予太多的重視。如今回想起來，我以爲這確實是違背了上面的第一條條件：項目必須首先是本身感興趣的。沒有人願意關注的東西，天然難以採用集市式的方式進行。因而，在這一次，集市沒有起到任何做用，咱們一直所倚靠的集市式成了低質量的罪魁禍首。

 

在經歷了這樣許多以後，我認爲，咱們依舊須要堅持咱們所一直依賴的集市式模式，它是咱們成功的基石。但在此之上，咱們必須另想辦法解決那些不適用於它的情景。在我看來，一個適合咱們團隊狀況的開發模式是這樣的：對於每個任務或者需求，首先應當儘可能採用集市式的思路去完成它。但同時，咱們應當設置一個警惕時間。若是超過這個時間依舊沒有任何轉機，那麼就說明集市模式已經再也不適用於這個任務或需求了。咱們應當綜合各方面意見，選定一個特定的，有足夠能力的且適合完成這個任務的人。讓他爲此事負責，這樣才能產生足夠的質量。從而避免集市式模式失效後直接崩盤的慘痛結果。

 

0x0504：前端AND 後端

前端—後端對接

「半獨立開發」形成冗雜交流 ü  從項目自己的架構出發，Seamantic UI的前端框架和Django框架相比，學習成本相對較低，所以不可避免遇到設計—前端的組合進度提早於後端進度；所以，在經過必定的協商規則，讓設計—前端組合優先整理需求，並反饋給後端調研可行性，但也致使後期，先後端對接過程兩方均作出了必定的修改，同時對接也更加依賴「全棧工程師」協調；

所以，在第二輪迭代的過程當中，團隊將優先保證設計層次的對接。擴展來說，先後端將優先以相似「E-R圖」的方式進行邏輯層次的設計，同時，儘量採起階段性的結對編程，實時完成需求變動的編碼實現

 

0x0508：NOT 任務責任集中/他組協商工做

NOT 任務責任集中

詳情可翻閱0x0500：教堂OR集市模式

 

NOT 他組協商工做

考慮中間層的搭建工做（鑑於第一輪迭代的Nutch插件開發思路未被採納）         優先整合另外兩組原有的接口         協商額外需求的特性         及早進行接口、功能方面的溝通和整合         經過交換人員來創建更有效的溝通渠道

 

0x06 ：團隊貢獻基本統計

項目集市小組職能	姓名	工做量統計
先後端對接組	馮志睿，錢林琛	l  不包含Django框架代碼量，後端人員協做完成python代碼行數807行 l  不包含Semantic UI框架代碼量，前端協做完成1249（accounts）+108（stackExchange）+2431（XueBaOnline）=3788行代碼，但其中代碼複用率較低，存在大量冗雜代碼塊「複製粘貼」式的利用，近期正進行模塊化djhtml工做
測試複審組	李入雲，李雲濤	l  獨立完成服務器和網站的腳本測試600餘行（閉源、包含壓力、響應、安全的多方面測試代碼） l  同期完成先後端代碼的白盒測試工做，同時負責監管Apache服務器自己的性能和日誌
環境配置、原型圖設計、先後端培訓組	馬騰躍，王鹿鳴，王文基	l  配置數據庫基本兼容環境，自動化生成python代碼行數130行 l  完成搜索引擎Solr、Nutch、Apahce的經典服務器環境搭建工做，新服務器發佈後考慮將舊服務器做爲Hadoop節點搭入提高總體服務器性能 l  完成先後端的基本培訓工做，在前期工做結對編程工做協做完成 ü  不包含Django框架代碼量，參與後端python代碼行數的約400行的代碼工做，主要針對先後端對接的代碼量進行協調和開發 ü  不包含Semantic UI框架代碼量，前端部分參與1249（accounts）+108（stackExchange）=1357行代碼量的完成工做
項目進度管理組	李雲濤
架構負責組	王鹿鳴
文檔整理管理組	錢林琛
原型圖搭建管理組	馬騰躍，李入雲	l  完成第一輪迭代所有原型圖的草圖設計工做，後期工做重心轉移至其餘項目集市小組
後期快速修復交流組	王鹿鳴、馮志睿	l  完成BugPhobia的智能交互助手搭建和移植工做 l  修復服務器遷移工做的各種POST丟失BUG