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阶段的基本功能：完善的用户个性化管理、完备的问答资源爬取、完善的搜索引擎架构，我们将用户精确定位于计算机系的“对专业课程、概念和软件使用有着大量需求”的学生群体，和非计算机专业的“对计算机相关概念和理解有着问答需求”的学生群体。
|
名字 |
王晓文 |
李茹欣 |
|
用户身份 |
某校计算机系学生，在专业课的大海中是一条淡水鱼 |
某校经管学院学生 |
|
年龄 |
岁 |
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 他组协商工作 |
|
|
0x06 ：团队贡献基本统计
|
项目集市小组职能 |
姓名 |
工作量统计 |
|
前后端对接组 |
冯志睿，钱林琛 |
行 （accounts）+108（stackExchange）+2431（XueBaOnline）=3788行代码，但其中代码复用率较低，存在大量冗杂代码块“复制粘贴”式的利用，近期正进行模块化djhtml工作 |
|
测试复审组 |
李入云，李云涛 |
余行（闭源、包含压力、响应、安全的多方面测试代码） l 同期完成前后端代码的白盒测试工作，同时负责监管Apache服务器本身的性能和日志 |
|
环境配置、原型图设计、前后端培训组 |
马腾跃，王鹿鸣，王文基 |
行 l 完成搜索引擎Solr、Nutch、Apahce的经典服务器环境搭建工作，新服务器发布后考虑将旧服务器作为Hadoop节点搭入提升整体服务器性能 l 完成前后端的基本培训工作，在前期工作结对编程工作协作完成 行的代码工作，主要针对前后端对接的代码量进行协调和开发 （accounts）+108（stackExchange）=1357行代码量的完成工作 |
|
项目进度管理组 |
李云涛 |
|
|
架构负责组 |
王鹿鸣 |
|
|
文档整理管理组 |
钱林琛 |
|
|
原型图搭建管理组 |
马腾跃，李入云 |
l 完成第一轮迭代全部原型图的草图设计工作，后期工作重心转移至其他项目集市小组 |
|
后期快速修复交流组 |
王鹿鸣、冯志睿 |
l 完成BugPhobia的智能交互助手搭建和移植工作 l 修复服务器迁移工作的各类POST丢失BUG |