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 完成了后端开发人员调整的协商工做(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 完成学霸项目总体的架构和解释说明工做 |
姓名 |
贡献分分值 |
冯志睿 |
60 |
李入云 |
48 |
李云涛 |
56 |
钱林琛 |
57 |
王鹿鸣 |
66 |
王文基 |
58 |
金东禾 |
5 |
0x09 :团队终章篇章的尾序
仿佛相遇与离别交替出如今一
仿佛重逢与记忆展转浮如今这一切的终章,http://xueba.nlsde.buaa.edu.cn
就仿佛舞者优雅的谢幕
你好,旧时光,和软件工程
一切安好~