ASE Backend Review
团队成员介绍：仅限于Alpha阶段有贡献的成员。
典型场景描述：描述并说明你们认为的产品面向的典型场景。
团队管理与协作：包括但不限于团队内部如何协作，与其他团队如何协作，如何使用源代码管理工具，各成员工作量分配等。
项目质量控制：包括但不限于项目各方面（场景符合度，代码规范，测试，文档）的质量评估，开发中如何控制项目质量，燃尽图走势，代码签入统计等。
技术细节介绍：包括但不限于技术框架，技术难点（可以是算法上的，也可以是数据库设计等），独到的工作。
事后诸葛亮：对Alpha阶段工作的反思，主要内容可以参考邹老师的博客：http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html
团队
Zhikai Chen, Hao Wang, Jia Ning, Xin Kang, Lihao Ran
项目管理
alpha和beta阶段，我们组前后总共组织了20余次每日立会，完成了17次scrum report，并与前端组和模型组同时讨论了几次。每次report包括任务进度、代码签入、问题报告等部分，并且收集在目录中。其中代码、文档、任务分配以及燃尽图均在Dev Azure上保留有记录。
report样例：
技术细节介绍
数据库设计
数据库设计可以划分为几个部分：
- 问卷和问卷的选项
- 代码题目
- 用户部分
- 代码提示
- 用户行为（评价、提交、点击、通过、失败）
事实上就是与功能相对应的几个部分。在设计过程中不断进行着重构于改进，经历了从一开始实现前的初始设计的模块（上图origin）到实现过程中逐渐完善的模块的演化（下图improved）。用户部分为了能方便的使用到django提供的很多支持，如session权限控制等，继承自django的django.contrib.auth.models.AbstractUser类。用户的其他部分与其他模块都是自行设计相关的属性域。
除了基本的数据库模块的设计外，还进行了进一步的抽象，为常见的嵌套多重查询等进行了进一步的封装，提供了更快捷的API用于其他部分的设计。
Restful API 文档
接口文档
Restful API文档示例（提供给前端）：
代码及测试代码
所有代码参照约定好的需求文档的接口完成，均要求owner提供测试样例并负责下一步对接工作。
测试代码样例：
测试方式
- python代码测试
- postman请求测试
用户管理
登录注册
- 注册：读取请求中的用户名、邮箱以及密码，对其进行格式验证，验证用户名和邮箱是否已存在，验证两次密码是否一致。所有验证通过后创建用户，在response中返回用户名和用户id。
- 登录：读取请求中的用户名和密码，进行格式验证。验证通过后对比密码和数据库中密码是否一致，若一致则登录成功，在session中存储登录状态、用户名、用户id，在response中返回用户名和用户id。失败的情况返回失败信息。
权限管理
在用户访问特定url时，首先判断用户是否登录，若已登录判断登录用户的id和要访问的url对应的id是否一致。一致的话允许访问，否则禁止访问。
运行环境
用户提交完代码后，后端相应的接受代码提交的接口会为当前提交创建一个新的docker container，相应的题目标准输入输出也会被docker load。在创建运行容器的同时会开始计时，如果到达计时阈值后代码仍在运行，那么服务器端会将这次提交视作死循环（恶意代码）然后kill这个运行容器。我们利用docker提供的资源限制功能，使得可以同时在服务器上同时测试大量测试代码，并且保证了后端的安全：即使有恶意用户提交了恶意代码，后端服务也不会受到影响。
反思 Postmortem
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
进一步降低编程学习的门槛，提升非专业人员的学习效率。
清楚。
典型用户：编程初学者
典型场景：初学者需要快速入门，但苦于没有优秀的教程。
2.是否有充足的时间来做计划?
时间足够，但大多数人没有好好利用。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
对于不同的意见，我们会反复论证，如果意见始终不能达成一致，最后会投票决定。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大多数都完成了，但也有很多没有做完的。
之所以没有做完，是因为很多人还肩负着其他科研任务，没有有效利用有限的时间。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有，但比较少，原因可能是在做一件事前，大家会在scrum上论证的比较充分，筛除了很多可能的“无用功”。
3. 是否每一项任务都有清楚定义和衡量的交付件?
是的，每一个task都有id，并在scrum report里有记录，但是beta阶段有点草率。
4. 是否项目的整个过程都按照计划进行?
大部分是，因为每次scrum都会总结每个人所做的事情，并且分配下一阶段的工作，制定计划。有时会有人有特殊情况，延迟了进度，但很快会补上。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，缓冲区的作用比较大，有时遇到特殊情况，会耽误一些模块的开发进度，而且在不同模块对接的时候也遇到了各种各样的问题，如果没有缓冲区，肯定没有办法按时完成任务。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
会更加明确每个人的任务。
资源
1. 我们有足够的资源来完成各项任务么?
硬件设备以及项目管理工具都非常齐全，主要是有效的数据不够，这给模型组设计模型造成了很大困难。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
一开始开始精度估计很粗略，主要根据任务的owner的经验进行估计，后来随着项目任务的进行，大家随时调整时间安排，所以精度问题就被忽略了。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
用户测试的时间不足，因为随着项目接近尾声团队中慢慢出现了一些懈怠或者是忙于别的工作的行为所以导致一时间人力资源比较紧张。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
经过调查，我们组的同学都没有。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的，有变更的地方都会在teams上通知到个人。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
必须实现的功能是大家一开始在课堂上协商确定好了的，推迟实现的功能根据大家其他工作的工作安排决定，assign给合适的人。
3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?
大家都不太懂“出口条件”是什么，经过这一个项目之后，稍稍清楚了一些。但是说实在的，在这个项目里面我们没有用到太多。
4. 对于可能的变更是否能制定应急计划?
计划比较粗略，主要是看自愿和该任务owner自行找其他人帮忙解决，或者由master负责。我们主要遇到的是人员变更，alpha阶段初期PM退出，beta阶段另一位同学退出并有两位同学再加入，所以sprint启动阶段需要更多沟通的master的督促。
5. 员工是否能够有效地处理意料之外的工作请求？
可以，但需要利用到缓冲区的时间。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目开始初期完成的，Restful API、Database、Sandbox分别由一个人负责起草设计，然后慢慢完善的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
一开始很多，大家都不知道如何解决甚至引起了争论。解决方式：具体执行人先发布第一版，根据这个版本来改进，经过文档修缮和大家讨论之后达成一致。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
运用了单元测试。Django自带了测试方法，也可以利用Postman进行单元测试，非常有效，其他工具没有尝试过。
4. 什么功能产生的Bug最多，为什么？
推荐功能产生的Bug最多，因为一开始没有设置冷启动，推荐系统的启动条件比较苛刻，要求足够的用户数据。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
Alpha阶段代码复审做的比较好，对接时所有代码都经过wanghao同学复审了一遍，但beta阶段由于整体代码量不大所以就走走形式了。
测试/发布
1.团队是否有一个测试计划？为什么没有？
我们有测试计划，并且每个组都安排出了专门负责对接测试、用户调查的同学。
2.是否进行了正式的验收测试？
暂时没有找验收对象，接受测试的用户也是我们提前找好的，因为不希望给数据库带来太多垃圾数据。
3.团队是否有测试工具来帮助测试？
有，后端主要利用postman这个工具来进行测试。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
利用postman来进行测试是非常有用的
（a）大大节省了写测试代码的时间
（b）可以导出测试代码给不熟悉接口的同学快速上手，重复使用，对接时可以快速找到问题
测试上的改进，对于一些重要的接口可以多人测试或者结对测试，减少错误风险。
5.在发布的过程中发现了哪些意外问题？
有些同学的电脑浏览器打不开地址，并且暂时没有找到原因解决。
运行代码的功能在机器上连续请求的时候会出现崩溃现象，但是已经修复问题。
发现了测试过程中没有发现的bug，比如接口错误，找不到相应用户，用户编辑区外的文字可以被删除等等，都已解决。
