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