ASE Backend Alpha Sprint Review

[Backend] Alpha Review展示博客

1. 团队成员介绍：仅限于Alpha阶段有贡献的成员。
2. 典型场景描述：描述并说明你们认为的产品面向的典型场景。
3. 团队管理与协作：包括但不限于团队内部如何协作，与其他团队如何协作，如何使用源代码管理工具，各成员工作量分配等。
4. 项目质量控制：包括但不限于项目各方面（场景符合度，代码规范，测试，文档）的质量评估，开发中如何控制项目质量，燃尽图走势，代码签入统计等。
5. 技术细节介绍：包括但不限于技术框架，技术难点（可以是算法上的，也可以是数据库设计等），独到的工作。
6. 事后诸葛亮：对Alpha阶段工作的反思，主要内容可以参考邹老师的博客：http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html

团队成员介绍

Alpha阶段参与成员有

• Zhikai Chen
  • 负责整体框架的搭建和前端和模型通讯的api部分
    
• Jia Ning
  • 负责数据库的建立维护数据库相关接口api与数据录入部分
    
• Hao Wang
  • 负责沙箱的构建与系统的调试维护
    
    

典型场景描述

我们的产品面向编程语言的初学者，当前产品暂时只支持python语言的学习，该产品通过题目推荐的方式可以让没有python语法基础的用户迅速地学习到基础的python语法，进一步，对有一定语法基础的用户可以推荐的题目来训练相关数据结构与算法；除此之外还能进行智能的代码报错与代码搜索功能。

团队管理与协作

## 内部协作

任务划分

我们组在Alpha阶段的参与人数为三人，所以协作管理的时候相对没有那么繁琐，只不过每个人的任务量多了些，主要可以划分为数据库管理、Restful API设计执行、代码运行环境管理以及文档的设计沟通四个部分（还有一个scrum管理），于是我们给每个issue分配了一个owner，实际工作的时候由它划分子任务交给固定的人来完成。
| 队员 | issue |
| ---- | ---- |
| Zhikai Chen | Restful API设计执行、Scrum管理 |
| Jia Ning | 数据库管理：表、属性、接口 |
| Hao Wang | 代码运行沙箱及使用沙箱的接口、文档设计 |

工具管理

我们使用Azure DevOps来管理项目，包括任务分配、燃尽图等等。

外部协作

文档

作为提供web服务、设计API连接模型组和前端组通信的枢纽，我们与前端组和模型组分别共同维护了一个API文档，根据设计文档协商好的参数格式、返回内容以及代码规范来编写代码。

• 与模型组的api doc
• 与前端组的api doc

对接

在对接阶段，我们为每个队员安排了新的任务来配合项目的上线工作：
| 队员 | issue |
| ---- | ---- |
| Zhikai Chen | API接口调整 |
| Jia Ning | 录入数据 |
| Hao Wang | 部署代码到服务器 |
| Xin Kang | 阅读代码 |

项目质量控制

关于团队代码的质量，我们给自己在四个方面进行打分：

• 测试：6/10
• 代码规范： 5/10
• 文档： 7/10
• 需求分析：5/10

1. 关于测试：我们本次项目测试都有组内测试文件和对接测试，但是文档小修小改太多以及后端错误捕捉不到位导致模型组的问题有时候对前端不透明，后来确定格式之后这个问题基本得到了解决。

2. 关于代码规范：代码规范没有文档，开发人员基本通过解耦任务、开发经验并阅读各自的代码来尽量保持变量命名等的一致性。实际上由于模型、接口、沙箱三个app基本分配给了三个队员来写，所以每个app内部的代码风格都是一致的，但是队员之间并没有协商好代码规范。

3. 关于文档：我们与模型组所有的文档都通过devops来维护，每一篇文档都至少经过2~3次的修缮工作，比之前更加健全，考虑更加周到。我们与前端组的所有文档都通过hackmd.io来维护，双方都对api提出了设计思路，修改过很多次，尤其是返回的错误信息，后端逐步完善对erro的捕捉防止传递给前端。

燃尽图

代码签入记录

只能显示一小部分

所有记录

技术细节介绍

作为AICoach项目的后端组，我们的主要任务是提供整个web服务的逻辑处理、数据存储和作为前端、模型的沟通桥梁。经过开会讨论，我们选择Python的Django web framework作为后端开发的框架。和前端以及模型组的沟通都走http，在alpha阶段的开发里我们的数据库就简单的使用Django默认的SQLite作为数据存储的工具。由于后端的同学们之前都缺乏web开发的经验，在整个开发的过程中我们学到了很多web开发方面的规范和技术，Django也确实是一个特别方便易学的框架。

总的来看，后端主要提供了以下功能：

功能名称	服务对象	涉及工具
用户信息	前端	Django
调查问卷	前端、模型	Django
题目信息	前端、模型	Django
做题	前端、模型	Docker、Django、pypi
推荐	模型	Django
部署	后端	Nginx、Docker、uwsgi

AICoach中需要用户提交代码，后端提供执行安全执行环境。

事后诸葛亮

详情见(事后诸葛亮)[https://www.cnblogs.com/vo1ad0r/p/11938725.html]

设想和目标

我们的软件想解决初学编程语言的入门困难。

计划

1. 项目的整个过程都按照计划进行，但这个计划在项目开始后第一天发生了很大更改。我们原本有充足的时间做好了计划，但是工作第一天scrum组长就宣布要离开了，以及两位已经安排好的队员也退出项目所以这是我们没有估计到的一个风险，就是队员“临时”退出的问题。这个问题的没考虑到主要是一开始没有和一些没选课或者不需要学分的同学单独确定，解决方式就是剩下的队员立马集结起来重新确定计划。

2. 团队在计划阶段同事们对于计划有不同意见，主要是靠一些队员斡旋一下或者请教mentor和助教来解决的。

3. 我们在计划中没有留下缓冲区，实际上在对接过程中有很多小bug。如果有两到三天的缓冲区可以把这些bug更优雅地完全fix掉，而不是选择退而求其次的打补丁形式。

4. 是否每一项任务都有清楚定义和衡量的交付件?在doc上明确写出来的任务是有的，但是有些非常小的bug非常快速的解决了就没有记录下来。

5. 将来的计划会做什么修改？Beta阶段我们会设置两天左右的缓冲区，并且要求后端的模型层和视图层工作再解耦的更好一些，写一份模型层的文档来给视图层调用数据库接口。

我们学到了什么? 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

我们在组与组直接的接口采用了文档交流的形式，但是组内不同模块直接的交流没有完善成文档，导致组内同学工作的时候遇到不明白的（表项含义，接口含义）会频繁的采用聊天的方式交流，效率不高。应该在写自己的工作的同时完善好相应的文档。

在变更管理上，我们会及时有效地通知，保证每个相关的员工都及时知道了变更的消息，及时确定或者更新文档，尽量避免冗余的工作请求，但是也要求员工能够有效地处理意料之外的工作请求。