AIApe问答机器人Beta阶段展示
AiApe问答机器人Beta阶段项目展示
项目与团队
我们团队执行着Alpha阶段刚开始的分工：软工团队介绍。
在Beta阶段的早期，为了高效地讨论项目的流程、具体分工，团队开会主要采取线下的方式Scrum Meeting 5.26；开发和测试阶段，大家多以线上讨论，在群中反馈各类信息。每日例会也以线上腾讯会议的形式展开，同时在讨论设计上的问题时，我们也会在线下进行讨论Scrum Meeting 6.3。
与Alpha阶段不同的是，Beta阶段成员之间沟通的频率更高。除了每日例会外，后端之间、前端之间经常线下沟通，以便尽快解决所遇到的问题。交流次数的提高使得开发的效率提高了不少。
项目典型用户场景
项目的典型用户场景参考：AIApe问答机器人Beta阶段测试报告的场景测试部分。用户场景满足参考：AiApe问答机器人软件发布声明的使用方法部分。
项目杀手级功能
神经网络模型
我们的交互机器人部署了NLP模型，具体模型和效果可以参考AIApe问答机器人NLP模型介绍。
辅助提问
当遇到机器人提供的回答无法满足用户需求时，机器人将会把用户提出的问题转化为提问模板，并且引导用户提问。
代码分析
后端使用了astyle标准化代码，使用Cppcheck检查代码。
我们的产品还将提供C语言代码分析功能。它能够帮助用户标准化代码，并且反馈给用户可能出现的错以及对应的行号。
代码分析主要是用来检查未初始化变量，内存泄漏，资源泄露，悬垂指针，printf/scanf的pattern和对应的变量对应关系，数组越界，平台依赖的int-pointer间强转等比较不容易别发现的问题。我们并没有加入编译的功能，所以无法检查语法错误。
相对于竞品来说，我们的项目最大的特点就是使用了问答机器人，而辅助提问功能也是根据问答机器人应运而生的。团队将问答社区做的更加简介，所以有更多的精力来完成机器人的部分。我们认为同类产品更加注重功能的完整性和准确性，而现阶段通过对话提问的机器人并不是主流，或者说效果不佳，所以竞品大多使用直接匹配问题的思路。
宣传与用户日活
在软件发布之后，我们通过微信、QQ等常用社交软件进行宣传。在各微信群、QQ群里发布软件上线通知。
用户日活
截至6.18日15.00时，产品累计浏览次数超过300次，活跃注册用户30人左右。并且由于产品支持不登陆对问题和解答进行查看，所以使用用户量应该更高。
用户反馈
在这几天的使用过程中，我们收到了许多用户的反馈。大多数是正面的评价，还有一些是对于软件用户体验的建议。
项目与团队总结
项目管理
团队成员简介与博客
团队成员介绍可移步软工团队介绍。
团队协作方式
团队开发阶段主要以线上交流方式为主。这样的沟通方式利弊显著：时间灵活但效率不及当面交流。PM会定期要求成员汇报工作，并且将汇报记录整理成文档。在Beta阶段，团队之间加强了线下的沟通。这让开发的效率提升了不少。
团队开发实际进展如燃尽图所示：
团队成员评分
关于Beta阶段团队评分细则，可移步荡起双桨团队贡献度评分规则。
关于Beta阶段团队贡献和评分结果，可移步AIApe问答机器人Beta阶段团队贡献与评分。
软件工程质量
项目拥有完整的文档和清晰的存档结构，拥有Bug整理，测试分析，前后端代码规范，技术、功能、前后端接口、数据库设计说明书等开发文档。同时会议、管理、展示文档也全面记录了项目开发完整过程。
项目测试说明详见AIApe问答机器人Beta阶段测试报告，其中包括压力测试、场景测试和单元测试等测试信息。
项目的文档管理有层次，会议记录详细，软件各部分重要技术说明完整。
项目部署了CI/CD进行自动化测试。
教训与反思
黎昊轩
相对于Alpha阶段的产品来说，Beta阶段的产品功能更加完善，交互UI更加美观...这些离不开团队里每一位成员的辛勤付出。我们在Beta阶段充分吸取了Alpha阶段任务分配粗糙，设计不明确的教训。在Beta阶段的初期就对整个阶段的工作进行了详细的划分。
在开发阶段，团队成员之间交流频率比Alpha阶段更高，并且线下交流更多。虽然这些交流都没有被记录在每日例会中，但是这些面对面的开发和讨论让项目进展更快，我们的开发效率更高。同时，在不断交流的过程中，我们仍然不断地发现新问题、完善设计。并且，在这个阶段，我们更加注重用户体验和交互UI。从用户的角度去思考问题，能够让我们更加完善产品。
黄思为
我认为自己并没有形成一个工程的模式，在写代码时总觉得十分“琐碎”，我不确定这是前端的特点还是我没有找到正确的代码规范或书写方式。
在Alpha阶段我们前端的展示效果不是很好。在Beta阶段开始前，我与队友详细地讨论了前端页面的细节问题，最终首先确定了一个框架，再进行书写。我个人认为前端还是以展示为驱动的，不仅仅是要实现基础功能。
李明昕
beta 阶段的开发体验较 alpha 阶段好很多。一方面是开发内容，alpha 阶段由于后端用的是 ASP .NET 框架，一开始不熟悉开发起来就有一定的困难，而在 beta 阶段由于我负责的部分主要是用 Python 完成，相对来说更上手，体验也就更好。另一方面是团队协作方面，在 beta 阶段，团队的沟通较之前来说更积极，整体的团队配合也比 alpha 阶段好了很多。
对于在 beta 阶段分配到的任务，我个人对自己的完成情况还算满意，但在开发内容上相较另一个后端同学来说少了些，现在看来在开发的过程中可以动态调整安排，根据每个人的情况对任务进行再分配，使得工作量可以更加的平衡。我认为这一点是我 beta 阶段做的还不太好的地方。
邓新宇
- 结构设计很好，基本上符合高内聚低耦合，但是在实现的时候，却经常破坏设计，尤其是在beta阶段的时候，工程的代码量已经很大了，改着改着就成屎山了，就算有文档和注释也开始乱了。并且机器人服务作为一个上层服务，可能需要调用其他服务，写的很混乱，有一些通用的算法，最开始没有注意到其公共性，而实现在了业务类内部，导致复用的时候出现了困难。以后应该适当地将工程进行拆分，一个主项目，搭配多个子项目，这样一方面不至于工程过于臃肿难以维护，也可以强制进行一定的隔离和保护。
- 最开始设计架构的时候没有考虑到后台定时任务，所以后来添加热榜更新、数据库与NLP微服务数据同步的定时任务的时候，十分痛苦。跟上面一条一样，定时任务完全可以和其他部分不在一个工程中，甚至不必在一个进程中，它们之间可能会共用一些部分，将共用的部分抽象成一个单独的类库工程，然后一个Web工程提供Web服务一个控制台工程进行后台定时任务，这样的安排会比一个大工程完成所有工作清晰得多。
- 开发模块的时候没有考虑测试，导致测试的时候出现了一些障碍。一方面，有些相对比较大的类是直接实现的，没有接口，导致单元测试无法构建动态代理的Mock对象；另一方面，IoC容器中，临时生命周期的对象，如果需要一些共享的变量，我都采用的static变量的方式，但是这在单元测试的时候出现了问题，因为所有单元测试用例共用同一个static对象，应当将共享变量抽象成一个类，将这个类的生命周期设置为单例的，然后添加到IoC容器中，使用的时候将这个单例的共享对象通过依赖注入添加到临时对象中。
- API设计的前后，没有进行线下的讨论，虽然在线上让大家一起看看，但是没有进行有效的反馈，导致API经常需要修改。
董俊杰
感受和反思
主要感受是这门课工作量很大，需要团队成员间的配合；此外在开始工作之前对软件的的大体框架做一个设计非常有必要
