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

時間 2019-12-13

標籤 bugphobia 篇章在線系統 beta 階段展現简体版

原文原文鏈接

0x00 ：序言javascript

1 universe, 9 planets, 前端

204 countries,809 islands, 7 seas, java

and i had the privilege to meet you.python

展信安，致以BugPhobia團隊的終章git

即使對慶典失去興趣和新鮮感github

也選擇用儀式感填補生活數據庫

就像用紙記下「一二三四」的計劃編程

貼在學校衣櫃的鐵皮上後端

0x01 ：團隊成員簡介緩存

圖1 BugPhobia團隊終章篇章的合影

0x02 ：團隊項目願景

0x0200：學霸在線系統基本定位

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

0x0204：Beta階段團隊基本定位

Alpha階段BugPhobia團隊基本定位	Beta階段BugPhobia團隊基本定位
完善？搜索引擎架構？	組間協做！重構兼容！繼續的開發迭代！
完善的用戶個性化管理、完備的問答資源爬取、完善的搜索引擎架構，咱們將用戶精肯定位於計算機系的「對專業課程、概念和軟件使用有着大量需求」的學生羣體，和非計算機專業的「對計算機相關概念和理解有着問答需求」的學生羣體	組間協做：Alpha階段開發過程當中，學霸項目各團隊均忽視了組間協做的高昂成本，各自模塊的完成不等於對接成功！所以，即使在Beta階段的溝經過程長達2周，BugPhobia團隊、Dream團隊、PowerTeam團隊之間協商後端開發接口、SOLR字段開發文檔、SOLR配置和解決方案文檔等，後期的組間協做也初步完善
	重構兼容：Alpha階段，團隊僅考慮自己的實現效果；而Beta階段爲保證其餘協做組的開發進度，團隊從前端的React單頁應用到後端的JSON數據定義完成了所有代碼的重構
	繼續的迭代開發：Beta階段，在後續的開發過程當中考慮到重構、溝通的高昂成本，所以團隊儘量保證技術棧的優先搭建；不管是共用後端（Django）、FLUX單頁開發模式均徹底搭建成功；同時，團隊不只保存開發過程的必要文檔，也留下Semantic UI、Django部分的開發文檔和心得，保證後續的迭代開發可以順利開展；數據處理能力的可擴展性： n SOLR自己具有分佈式支持的特性 n 單頁應用模式對於服務器的計算壓力較小，前端對CDN加速的技術適應性較強

0x0208：Beta階段用戶註冊和訪問量說明

用戶實際註冊數

訪問流量統計

活躍用戶量

——

這裏BugPhobia團隊爲您的支持表示感謝，但經歷了溝經過程的高昂成本消化後，後期實際開發過程當中，即使學霸項目四組間最終完成了項目的對接工做，但從用戶的角度，Beta階段迭代後的產品版本沒法面向用戶，部分功能受到數據組數據類型的限制、後期開發時間的嚴重縮減，致使重構後的產品只能把必要的技術棧填充。

所以，考慮到繼續迭代開發的過程，團隊Beta階段的項目並不面向最終用戶，而面向了繼續迭代和開發的人員；所以，僅從團隊自己的意向出發，團隊此階段的工做已所有順利完成；後續的開發人員可以從三方面入手：

n 共用後端的接口擴充：其可擴展性較強，數據庫和後端接口的相關文檔也所有保留（建議添加課程部分）

n 適用於CDN加速：FLUX單頁模式即ReactJS的開發模式，因爲其架構自己和SOLR的架構自己均支持分佈式的搭建，特別地對於CDN加速的搭建也有很大的幫助

n FLUX單頁開發模式：在ReactJS的單頁應用開發架構下，團隊自己預留了充足的學習文檔和開發文檔能夠提供給後續的開發人員繼續迭代

0x03 ：典型用戶與場景描述

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

0x04 ：團隊項目進展、成果及技術棧

0x0400：Beta階段的挑戰與機遇

Alpha階段解決的問題：團隊磨合

Beta階段面臨的挑戰：四個團隊間的鏈接

時間	困難描述
12月13日	n 關於ReactJS和Semantic UI的javascript衝突情況 n 關於Solr自己的配置和插入問題 n 關於對接的終稿交付說明
12月16日	n 溝通問題的協商和解決 n 學霸爬蟲組與需求的不對稱
12月23日	n 關於Solr的數據插入的解決方案 n 關於Seamantic UI自己的BUG解決方案
備註	這裏僅給出部分苦難的描述，對於詳情的分析，請翻閱BugPhobia團隊的Scrum Meeting篇章進行查看和翻閱

0x0404：Beta階段技術棧的解決方案

圖 4-1 團隊總體的架構說明和基礎優點說明

所以，不妨由機遇和挑戰兩方面說明這一問題：

挑戰

n 須要和APP組公用後端

n 前端須要支持經過JSON與後端交互

n 單頁應用技術較新，之前從未接觸過

n 須要對幾乎全部代碼進行重構

機遇

n 優化Alpha階段的細節

n 重構不合理的頁面

n 拋棄在Alpha階段結尾寫成泥球的代碼

n 將代碼組件化，增長代碼重用，整理代碼結構

0x0408：Beta階段技術棧的成果展現

Alpha階段的代碼質量分析	Beta階段的代碼質量分析
【HTML】3300+	【HTML】19
【JS/JSX】300+	【JS/JSX】2800+
【PYTHON】807+108	【PYTHON】1800+

n Alpha與Beta階段對比

頁面結構優化，主頁、用戶管理界面去除了冗餘細節

前端代碼佈局（體現出代碼重用和結構變動）

前端專業化：

ü 基於Webpack的代碼打包和優化（JS優化、壓縮及混淆）

ü CDN友好性（文件名中帶有HASH碼，一旦發生變動能及時傳遞給用戶，不會因爲緩存緣由致使老版本長期緩存在用戶電腦上）

ü 組件重用

先後端解耦

n FLUX單向數據流動及基於ReactJS的組件化

順利遷移到單頁應用模式

不一樣頁面重用部分公用代碼

n 可擴展的框架

上游數據增長：SOLR支持分佈式

用戶訪問量增長：經過獨立的靜態文件服務器或CDN加速前端的分發，能夠有效減輕後端壓力

重寫UI或支持新的平臺：先後端經過JSON實現鬆耦合，能夠完整複用後端代碼

0x05 ：團隊項目的分工協做與基本反思

0x0500：Beta階段團隊組內協做說明

圖 5-1 BugPhobia團隊Alpha階段開發流程說明

圖 5-2 BugPhobia團隊Alpha階段開發流程說明

項目	Alpha階段開發模式	Beta階段開發模式
面向羣體	面向用戶的開發模式	面向開發人員的開發模式
架構開發	Semantic UI前端和Django後端結合	Semantic+ReactJS前端和Django共用後端結合
車禍係數	在Alpha階段，團隊出於基礎的磨合階段，所以在必定程度上，由Alpha團隊內的組內協做可知： n 團隊技術棧是以架構和後端做爲驅動的開發模式，所以團隊內的協做是以架構師GNU_Linuxer爲基礎，所以極可能因爲架構師傳遞信息的「不肯定性」，致使項目車禍發生 n 團隊先後端對接工做徹底依賴後端人員對前端代碼的理解，所以二者須要必定時間進行結對編程，致使二者之間的耦合相對較差	在Beta階段，經歷Alpha階段的開發，團隊成員自己對項目和架構的認知相對較深，所以團隊的分工呈現多層次的遞歸發展： n 團隊技術棧開發分離，SOLR架構、前端ReactJS、後端Django開發組均能正確獨立地完成相應模塊的開發，所以對接成本下降 n 團隊先後端的對接工做相互獨立，後端人員完成相應接口的設計後，只需經過Django自己的單元測試框架便可完成正確性的驗證；而前端人員能夠直接根據接口文檔完成調用，無需理解具體的原理過程
流水線開發模式	n 在Alpha階段，團隊總體的開發呈現基礎的流水線工做，設計、前端、後端、測試、複審、驗證的流水機制高速運轉，其總體的開發模型符合瀑布模型的流水工做，總體的代碼嚴謹性較強 n 但同時，流水線的阻塞也是開發過程不可避免的階段，部分工做的延誤將有可能致使其餘人員的進度延誤	Beta階段，考慮到流水線機制自己的問題，團隊的開發呈現局部流水、總體並行的開發機制： n 在局部上，項目自己將各功能模塊進行分割操做從而保證了局部的開發模塊可以以流水的形式繼續開發，即前端和後端的對接，測試的驗收等部分工做；而結對編程也一樣發揮了應有的做用 n 在總體上，項目自己處於總體併發的開發機制，一旦某一開發人員開發陷入阻塞態，其餘成員可以依據自身的並行開發序列繼續開發，從而避免總體開發進度阻塞的問題
文檔管理	Alpha階段未強調文檔的基本管理	Beta階段，團隊制定了完整的文檔管理計劃（更多細節能夠瀏覽github的文檔版本）： n 團隊內的文檔儘量使用Markdown文本編輯，容許使用擴展的Markdown語法，但必須保證GIT@OSC或MarkdownPad可以支持相應的擴展語法 n 對於部分必要的新技術，必須同時維護一份技術入門文檔
測試說明	Alpha階段未強調單元測試和部分性能測試的問題	Beta階段制定了完成的測試方案和計劃說明（更多細節能夠瀏覽github的文檔版本和測試報告） n 腳本型功能測試 n 手工測試 n 腳本型安全性測試及性能測試
責任明確	Alpha階段，團隊總體處於集市的開發模式，團隊自己未強調相關任務責任的明確化和細緻化	Beta階段制定了明確的責任分工制度（更多細節能夠瀏覽github的文檔版本和測試報告）

表 5-1 Alpha階段/Beta階段開發模式和團隊協做對比表

u 團隊在Beta階段將完成使用Team@OSC進行任務的管理（https://team.oschina.net/Bugphobia）和Github自己的Issues進行關聯

u 任務具體的發佈流程 ◦團隊所有成員均可以發佈任務，但必須保證任務標籤、任務說明均完備，在發佈後任務將自動進入待辦中狀態

u 全部預約任務均會在兩天前發佈任務，團隊成員在完成任務時應當首先將任務狀態更改成進行中狀態，而任務完成後可自行將任務狀態更改成已完成（或者在Scrum Meeting上說明情況，由其餘人歸爲「已完成」狀態）

u 狀態進入「已完成後」，任務管理將進入「審閱階段」，此階段將由項目經理審閱後更改成「已驗收」狀態，此後項目經理將同期發佈代碼複審工做

0x0504：Beta階段團隊組內協做說明

王鹿鳴

n 完成Semantic UI框架向ReactJS的代碼遷移工做

n 完成其餘模塊的具體頁面的前端實現

n 架構團隊總體的開發流程

u 前端開發

u 全棧溝通、架構、前端

錢林琛

n 完成功能規格說明書、技術規格說明書、績效管理的整理和維護工做

n Scrum Meeting期間完成Scrum Meeting的記錄和更新，要求必須包含：我的的Work Issue的ID關聯（已完成、計劃完成、工做中的困難記錄），燃盡圖，照片，代碼/文檔的簽入記錄說明

n 與團隊成員交流後規劃各個開發時間，進行監督和「干預」

n 必須與爬蟲組、數據組、APP前端組進行溝通

u 項目經理

u 功能溝通，管理

馮志睿

n 調研第三方登錄的基本環境，並在Beta階段進一步支持第三方登錄

n 根據接口定義，實現相應接口（JSON數據格式），交付前端作進一步的解析

u 後端開發

u 全棧溝通、後端、結對編程

王文基

n 根據接口定義，實現相應接口（JSON數據格式），交付前端作進一步的解析

u 後端開發

u 後端、結對編程

趙庶宏

n 根據接口定義，實現相應接口（JSON數據格式），交付前端作進一步的解析

u 後端開發

u 後端、結對編程

李雲濤

n Javascript和DOM的學習進度規劃

n 從新梳理前端頁面的邏輯跳轉，整理須要開發的「新頁面」

n 直接以ReactJS的view渲染開始新頁面的編碼和設計

u 前端開發

u 全棧溝通、前端、結對編程、測試

李入雲

n Javascript和DOM的學習進度規劃

n 從新梳理前端頁面的邏輯跳轉，整理須要開發的「新頁面」

n 直接以ReactJS的view渲染開始新頁面的編碼和設計

u 前端開發

u 結對編程、前端

金東禾

n 整理已知的Django框架、Semantic UI框架的入門教程，經過Markdown或LaTex整理爲可讀性較強的文檔，留做爲接任此項目的團隊的學習文檔

u 文檔整理

u 學習文檔整理、技術平臺整理

0x0508：Beta階段團隊組間協做說明

溝通工做梳理

具體細節說明

Dream團隊間的協商

n 完成了先後端對接的共用接口設計文檔（https://github.com/bugphobia/XuebaOnline/blob/master/documents/Beta%20Version/Preparing/Beta%E9%98%B6%E6%AE%B5%E5%89%8D%E5%90%8E%E7%AB%AF%E6%8E%A5%E5%8F%A3%E5%AE%9A%E4%B9%89%E8%AF%B4%E6%98%8E.md）

n 完成了後端開發人員調整的協商工做（Dream團隊的後端開發成員趙庶宏進入BugPhobia團隊完成共用後端的開發）

n 完成了先後端對接的準備和進度的說明

n 提供了通過調試的且單元測試完成經過的後端接口用於具體的對接工做

PowerTeam團隊間的協商

n 提供了SOLR配置和案例插入的解決方案文檔（https://github.com/bugphobia/XuebaOnline/blob/master/completed/Solr%E6%A8%A1%E5%BC%8F%E9%85%8D%E7%BD%AE%E4%B8%8E%E6%95%B0%E6%8D%AE%E5%AF%BC%E5%85%A5%E8%B0%83%E7%A0%94.md）

n 協商解決了SOLR的插入失敗、迭代查詢、服務器端基本驗證等細節（https://github.com/bugphobia/XuebaOnline/issues/63）

n 完成了SOLR平臺的總體部署和協商問題

圖 5-3 團隊間協做分工說明圖例

0x06 ：團隊質量控制與測試方案

0x0600：Beta階段團隊代碼質量說明

圖 6-1 團隊代碼質量分析圖

0x0604：Beta階段功能測試說明

n 用戶管理模塊（手工測試）

測試項目	BUG測試說明	修復狀況說明
正常註冊	——	——
正常登錄	——	——
重複註冊	提示信息出現錯誤，此BUG經調研涉及Semantic UI框架自己標記的BUG	已修復
錯誤信息登錄	後端驗證中提示信息出現錯誤，此BUG提供網頁前端驗證的解決方案	已修復
非法信息註冊	——	——
資料查看	可能出現部分資料屬性返回空值的狀況，經調研此問題涉及部分POST機制，交付Exception模塊處理便可	已修復
資料修改	——	——

n 標籤搜索模塊（手工測試）

測試項目	BUG測試說明	修復狀況說明
搜索存在的標籤	搜索結果未進行分頁，頁面顯示過長	已修復；前端開發人員從新設計佈局並使用分頁佈局JS和CSS完成BUG的校服
搜索不存在的標籤	爲搜索到返回結果，無提示信息；特別說明，此BUG屬於後期測試時用戶提供的BUG標籤，所以在Beta階段完成此BUG的修復工做	已修復
對搜索框進行注入	——	——
直接點擊Tag進行搜索	——	——

n 問答模塊（手工測試）

測試項目	BUG測試說明	修復狀況說明
問題搜索	——	——
回答展現	此部分展現效果根據用戶的反饋，其UI美化相對較差，所以可能須要從新佈局和排版	未修復
問題提出	——	——
相關問題推薦	——	——

0x0608：Beta階段性能測試說明

特別說明：因爲在服務器運行過程當中進行性能測試可能影響用戶使用，咱們未直接對服務器進行測試，而是在咱們的備份服務器上進行與上個版本的性能測試對比，進而估算服務器的承載量

關鍵詞說明：間隔請求，同時請求，帶寬瓶頸，CDN負載

模擬請求數量	請求方式	服務器正確相應數量	平均事務響應時間	事務響應百分比
100	同時請求	100	0.1	1
100	間隔請求	100	0.1	1
300	同時請求	300	0.2	1
300	間隔請求	300	0.1	1
600	同時請求	573	0.6	0.955
600	間隔請求	600	0.3	1
1000	同時請求	721	1.9	0.721
1000	間隔請求	984	1	0.984
2000	同時請求	733	——	0.3665
2000	間隔請求	1229	2.4	0.6145
綜合評價	網站對間隔請求（兩請求時間間隔大於0.1秒）的響應較好，對同時請求的響應尚有待改進。目前在600併發時對請求的響應相對穩定可靠，超過600請求不能保證響應的正確性。對於同時請求的狀況，因爲服務器須要向用戶發送一個較大的打包的js文件，同時須要與用戶創建session鏈接，這一階段對帶寬的要求較高，所以成爲了性能的瓶頸。現實中，在用戶量較少的狀況下，不多有兩用戶同時訪問的狀況；若是用戶量提高顯著，咱們的架構支持向CDN的轉移，所以瓶頸將會消失。綜上，咱們認爲網站的負載足以知足當前的需求。

網絡環境\性能	1M帶寬	10M帶寬	100M帶寬
酷睿2單核+1G內存	加載緩慢，基本正常運行	加載正常，基本正常運行	加載正常，基本正常運行
酷睿2+2G內存	加載緩慢，正常運行	加載正常，正常運行	加載正常，正常運行
酷睿i5+4G內存	加載緩慢，正常運行	加載正常，正常運行	加載正常，正常運行
綜合評價	網站採用單頁應用的形式呈現，所以在首次加載時會發生較大的下載量。在帶寬不足的狀況下加載較爲緩慢，但能夠完成加載。網站對前端的計算需求不強，使用運算性能較弱的機器依然能夠正常執行。在網站和服務器的數據交換上，因爲每次請求的數據量較小，所以帶寬不會成爲瓶頸。

0x060c：Beta階段兼容性測試說明（詳情請於測試報告中查看）

0x0610：Beta階段場景測試說明（詳情請於測試報告中查看）

0x07 ：團隊項目進度說明

圖7-1 團隊Scrum的燃盡圖說明

圖7-2 團隊Beta階段參與程度基本情況說明

0x08 ：團隊具體貢獻分配

項目集市小組職能	姓名	工做量統計
先後端對接組	馮志睿，趙庶宏	l 不包含Django框架代碼量，獨立完成python代碼行數1200行（結對） l 不包含Django框架單元測試自動生成的代碼量，獨立完成單元測試代碼量300+行
測試複審組	李雲濤	l 獨立完成服務器和網站的腳本測試600餘行（閉源、包含壓力、響應、安全的多方面測試代碼） l 同期完成先後端代碼的白盒測試工做，同時負責監管Apache服務器自己的性能和日誌
環境配置、SOLR對接解決組	王文基	l 完成搜索引擎Solr、Nutch、Apahce的經典服務器環境搭建工做，新服務器發佈後考慮將舊服務器做爲Hadoop節點搭入提高總體服務器性能 l 完成搜索引擎Solr與學霸數據組的對接工做，解決組間協做反饋BUG
前端開發組	李雲濤、李入雲	l 完成搜索結果展現頁面、問答模式頁面（三類）說明的HTML頁面約400行（已所有嵌入JS頁面完成相關設計），JS代碼約300行
項目經理管理組	錢林琛	l 基礎的博客維護：包含Scrum Meeting、發佈說明、最終評審報告等多方面 l 完成必要的進度監督和干預工做 l 成問答頁面的相關設計工做
架構負責組	王鹿鳴	l 完成先後端的所有對接工做，完成JS/JSX代碼2200+行 l 完成服務器的基礎配置工做和網頁的配置遷移工做 l 完成學霸項目總體的架構和解釋說明工做