Beta冲刺——冲刺答辩博客

这个作业属于哪个课程 <2020 春 W 班 (福州大学)>
这个作业要求在哪里 <作业要求>
团队名称 <旗山的骄傲>
这个作业的目标 <Beta 冲刺>
作业正文 <作业正文>
其他参考文献 <《构建之法》>

part.01 设想和目标

做这个项目的背景、意义是什么？要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

  • 解决问题

    • 服务于高校师生，集任务发布、物品租赁、失物招领及其他附加功能的校园综合平台。解决了高校日常生活中需要解决难题时需要发布任务的情景；解决了对某类物品急用时物品租赁的场景；解决了丢失/捡到失物时失物招领的情景；解决了找人/找群/找历年卷时使用附加功能时的场景。

  • 定义是否很清楚

    • 定义较为清楚

  • 是否对典型用户和典型场景有清晰的描述

    • 有针对四个模块对典型用户和典型场景有清晰的描述（见下）

  • 发布任务
    典型用户：刘志勇
    用户需求：代领快递
    场景描述：
    雨天，一位名为刘志勇的大学生收到了一条快递信息，要去5区在19：00前领快递，但是他不想出门，又不知道专门的代领快递的组织，这时他点开了手机上的“校园芥子空间”app，点击“发布任务”，发起了高额悬赏——5元，不到五分钟就有人接了单，在一小时后给他送快递上门，伴随着“尊敬的刘先生，你的快递到了”的话语以及支付宝到账的提示音，任务结束。

  • 物品租赁
    典型用户：刘志勇，黄晓东
    用户需求：出租衣服，租赁衣服
    场景描述：
    31日，这个月的最后一天，还是那位刘同学，手头紧张，想靠出租体面的衣服来换取几顿饭钱，便打开了校园芥子空间，进入物品租赁的页面，发起了租赁。片刻，同样在使用校园芥子空间的同学黄晓东看见了这条租赁信息，那体面的衣服每天只需要不那么体面的10元便能穿在自己的身上，想到这他迅速的发起聊天和刘同学谈妥了具体事宜，交易完成。

  • 失物招领
    典型用户：黄晓东
    用户需求：寻找失物
    场景描述：
    上面的那位黄同学记性不好老是丢东西，今天他把校园卡丢了。已经习惯使用校园芥子空间的他第一时间打开了app，熟练的发布了失物招领信息，数小时后响起一阵敲门声，他打开门一看，是拿着他的校园卡来归还的刘同学，还不忘说“来一杯一点点的四季春”。黄同学的校园卡失而复得，失物招领的任务完成，在app上又发布了代买奶茶的任务……

  • 历年卷
    典型用户：刘志勇
    用户需求：找历年卷
    场景描述：
    期末周了，刘同学开始复习了，但是没有历年卷可以参考的话心里就没有底气，于是他情不自禁的打开了校园芥子空间，点开了其他功能，惊喜的发现这里居然有接下来几门考试的历年卷，忐忑的心放了下来，PPT翻页的鼠标点击声也大了几分……

项目达到目标了么（原计划的功能做到了几个？在原计划之上是否有所拓展)

  • 原计划的功能

    • 原计划功能三大模块基本完成，附加功能模块完成部分，爬虫部分未实现，详细完成情况见下

  • 是否按照原计划交付时间交付

    • 基本按照原计划交付时间交付，alpha阶段燃尽图基本成功燃尽，静待花开，beta阶段燃尽图有少量任务未实现

  • 原计划达到的用户数量达成情况

    • 根据问卷统计，用户数目前为31人，与预期目标还有一些距离

  • 在原计划之上的拓展

    • 新增了安卓的版本控制，可在web后台进行最新版本的apk上传

截止alpha阶段前各部分现实进展

web前台

对应模块 完成情况 存在问题
登录模块的各部分界面：登录、注册、忘记密码界面 基本完成 目前只实现了登录模块，可以进行正常的登录
主界面：实现对各模块进行跳转的主页面 完成 主界面主要是一个导航页，通往各个页面的风向标
发布任务、失物招领、物品租赁各模块的基础界面：总览、查看详情、发布、查看个人发布、搜索界面 基本完成 待完善 三个页面都实现了基本功能，查看详情，发布任务，查看评论。点赞以及实时评论尚未实现
其他界面：查看个人信息、修改个人信息等界面 未完成 时间关系，没有实现。
各模块的基础测试 完成 各个模块的基本功能都完成，没有问题
前后端完成交互 基本完成 因为后端这次是几位同学一起开发，导致后端的数据在不同模块的相似接口中的类型不一样，如一个是驼峰一个是下划线，在组件开发的基础下，导致工作量增加

web后台

对应模块 完成情况 存在问题
登录模块的各部分界面：登录、注册、忘记密码界面 基本完成 无
用户管理模块的界面：总览、查看详情、搜索界面等界面 基本完成 无
管理员管理模块的界面：总览、查看详情、搜索界面等界面 基本完成 无
任务管理模块的界面：总览、查看详情、搜索界面等界面 基本完成 无
失物管理模块的界面：总览、查看详情、搜索界面等界面 基本完成 无
物品管理模块的界面：总览、查看详情、搜索界面等界面 基本完成 无
评论管理模块的界面：总览、查看详情、搜索界面等界面 基本完成 无
敏感词管理模块的界面：总览、查看详情、搜索界面等界面 未完成 未实现接口（β阶段完成）
各模块的基础测试 基本完成 未完成全覆盖的测试
前后端完成交互 基本完成 未实现预期的所有功能

Android

对应模块 完成情况 存在问题
登录模块的各部分界面：登录、注册、忘记密码界面 基本完成 后端的注册和登录接口存在一些问题，暂时无法全面完善，因为用户还没完成用户的验证功能，所以忘记密码这一功能也还没实现
主界面：实现对各模块进行跳转的主页面 基本完成 主界面是最花时间的部分，目前已经基本完成，但是RecyclerView的缓存问题还没有解决
发布任务、失物招领、物品租赁各模块的基础界面：总览、查看详情、发布、查看个人发布、搜索界面 基本完成 目前的数据不多，没有实现搜索功能，下次完善
其他界面：查看个人信息、修改个人信息等界面 未完成 时间关系，没有实现
各模块的基础测试 完成 无
前后端完成交互 完成 有一些后端设计的接口和前端的应用存在偏差，这些问题会在下一个阶段统一反馈，统一解决

后端

  • 框架内接口部分

对应模块 完成情况 存在问题
完成对应各个模块（用户、管理员、任务、失物、物品、评论、敏感词）的接口 基本完成 敏感词使用tried树，本次未投入使用（β阶段使用）、各模块因三人开发，需要在下一阶段进行一定的代码重构
使用springboot框架内置的spring-boot-starter-test对框架内部进行测试 完成 无
使用Postman对接口进行初步测试并保留测试结果 完成 测试出各模块因三人开发，有部分返回数据还需进一步统一规范
完成在线接口文档为前端提供对接依据 完成 有部分接口描述不当，影响前端阅读（已修改）

  • 工具类部分

对应模块 完成情况 存在问题
基础工具类的编写：Json工具（封装接口返回数据）、Date工具（封装日期格式等）、Des工具（加密密码）、File工具（文件上传接口的封装及异常返回处理） 完成 无
使用Junit对工具类进行单元测试 完成 无

  • 服务器端

对应模块 完成情况 存在问题
初始化服务器：Tomcat的初始化、mysql的初始化、niginx初始化 完成 niginx初始化还未进行代理（β阶段完成）
部署项目：后端打包war包部署开放端口接口->部署前端项目 完成 未进行代理前端页面访问较慢

项目管理

对应工作 完成情况 存在问题
创建在线接口文档、在线每日工作文档、在线每日会议记录文档、在线工作量化文档 完成 无
创建teambition管理项目、上传更新量化后的工作 完成 任务量化为每人为自己的量化，每人对应任务量不平均
创建github组织，创建团队仓库（团队文档以及代码规范）、创建开发成员分支（6） 完成 有一成员未在分支进行开发
创建博客园博客：总结博客、冲刺计划博客、每日冲刺博客、汇总博客 完成 无
每日在线每日工作文档更新、每日在线每日会议记录文档更新、每日teambition管理（任务完成及统计信息记录）、每日站立式会议、每日博客园博客更新 完成 有任务逾期完成

燃尽图

截止beta阶段前各部分现实进展

web前台

对应模块 完成情况 存在问题
界面UI美化优化 基本完成 一些ui细节由于时间问题未完善
进一步进行测试，寻找潜在bug 基本完成 可能还存在隐藏bug
接口逻辑性能优化 基本完成 无
完成附加功能界面及子界面 基本完成 无
登录模块完成orc验证及找回密码的验证功能 基本完成 web端一般用不上ocr所以取消ocr验证
物品租赁完成根据地图租赁界面 未完成 无

web后台

对应模块 完成情况 存在问题
界面UI美化优化 基本完成 一些ui细节由于时间问题未完善
进一步进行测试，寻找潜在bug 基本完成 可能还存在隐藏bug
接口逻辑性能优化 基本完成 无
登录模块完成找回密码的验证功能 基本完成 无

Android

对应模块 完成情况 存在问题
界面UI美化优化 （基本完成）在Beta阶段，对UI做出了较大的修改，包括：背景、标题栏、输入框、左右边距等 没有美工做出来的UI还不是很美观，但是坚持做到了很重要的一点就是整齐划一
进一步进行测试，寻找潜在bug （基本完成）进一步进行测试，寻找潜在bug，主要对数据库的操作进行了测试 因为是一个人负责开发Android端，把精力集中到了功能的开发中
接口逻辑性能优化 （完成）与后端沟通和反馈，对一些接口进行了优化 比如：分页 无
完成附加功能界面及子界面 基本完成 附加功能没有实现
登录模块完成orc验证、找回密码的验证功能及登出功能 （完成）OCR验证校园卡完成、找回密码并验证完成、退出登录完成 OCR通过调用百度的API完成，限制了自定义UI的实现
物品租赁完成根据地图租赁界面 未完成 调用开发平台的API是一个很耗时间和精力的过程，这个功能没有实现
完成评论修改、删除功能 未完成 如果要实现评论的修改，需要对UI进行较大的改动
完成个人信息查看、修改功能 完成 如果要实现评论的修改，需要对UI进行较大的改动
完成各模块搜索功能 未完成 后端已经把搜索的逻辑实现了，前端因为时间的关系，把这个暂时不影响正常使用的功能砍掉了

后端

  • 框架内接口部分

对应模块 完成情况 存在问题
代码进行重构，统一规范 完成 代码完成了重构，封装了返回字符串到常量接口，封装了实现层的逻辑，仍存在架构不合理的地方，后续再进行迭代
增加举报功能对应的接口 未完成 时间因素，前端无法完成该部分界面
文件上传接口部分增加多文件上传与断点续传的功能 基本完成 多文件上传解决，断点续传在本项目中意义不大且实现不易，该功能暂时未完成
完成附加功能模块，在β阶段使用webmgaic完成爬虫，增加爬虫获取数据返回接口 未完成 技术因素，暂时无法爬取对应url
进一步进行测试，寻找潜在bug 完成 无
优化后端逻辑，提高性能 完成 无
系统安全性提升，增加接口请求头token验证与访问接口key密钥加密 基本完成 接口根据端口分配密钥未完成
系统负载提升，增加接口访问的请求队列，解决并发问题 完成 未测试可最大支持并发数

  • 工具类部分

对应模块 完成情况 存在问题
增加爬虫使用的工具类 未完成 技术因素，暂时无法爬取对应url
封装框架内的常用方法到工具类 完成 无

  • 服务器端

对应模块 完成情况 存在问题
使用nigix进行反向代理 完成 无
完成项目的docker化部署 小部分完成 技术不足，未完全搭建完成
增加服务器的安全性，完善安全策略 完成 在控制台增加了访问的ip与端口限制等
增加服务器的承载能力，负载测试 基本完成 使用对应工具进行了初步测试

项目管理

对应工作 完成情况 存在问题
创建在线接口文档、在线每日工作文档、在线每日会议记录文档、在线工作量化文档 完成 无
创建teambition管理项目、上传更新量化后的工作 完成 任务量化为每人为自己的量化，每人对应任务量不平均
创建github组织，创建团队仓库（团队文档以及代码规范）、创建开发成员分支（6） 完成 无
创建博客园博客：总结博客、冲刺计划博客、每日冲刺博客、汇总博客 完成 无
每日在线每日工作文档更新、每日在线每日会议记录文档更新、每日teambition管理（任务完成及统计信息记录）、每日站立式会议、每日博客园博客更新 完成 有任务因时间、技术因素未完成

燃尽图

任务总量变化

和alpha阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

  • 团队软件工程的质量提高情况

    • 和上一个阶段相比，团队软件工程的质量提高了

  • 提高的情况

    • 团队合作方面：提高了每日站立式会议的效率，表现在会议时间缩短的同时且汇报速度提高；前后端交互新增了前端反馈使用的在线文档，加深前后端的线上交流
    • 项目管理方面：沿用teambition的同时，优化了任务量化的方式，成员对应任务的分配更加平均，粒度更高；使用第三方（爱图说）绘制任务总量变化曲线，更为直观；增加了冲刺期间对开发、测试人员每日提交签入的要求，上传记录截图，每日对贡献比进行计算；沿用在线文档辅助项目管理，优化了在线文档的排版，更加适应于新阶段的作业要求
    • 代码质量方面：前后端均对之前代码进行了一定重构，前端优化界面，后端重构代码，规范了三人编写的后端；团队成员依然在不断增加知识储备，总体代码质量在一直提高中

设想用户量是多少, 用户对重要功能的接受程度和我们事先的预想一致么?

  • 用户量, 用户对重要功能的接受程度与预想的一致性

    • 设想用户量在100人左右（现实仅为31人，分析还是推广时间相对较短仅为2天多），用户对重要功能的接受程度在预期之内，根据用户调查报告显示接受程度中等偏上

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

  • 经验教训

    • 因三人编写后端，同类型接口提交参数形式有差，造成了不规范统一的问题
    • 前后端交互，线上交流信息有参差，导致时间的浪费
    • 上阶段前端测试时间安排不合理，导致测试覆盖率较低

  • 改进

    • 后端制定更全面的统一规定，加深交流与联系，更加统一规范
    • 前后端加深交流，会议时多交流，会议下通过文档、聊天工具等更多的交流信息
    • 测试伴随开发进行，时间管理，合理安排时间

part.02 计划

和alpha阶段相比，每天是否时间规划的更好?

  • 现实情况

    • 和alpha阶段相比，每天时间规划有变得更好

  • 冲刺前

    • 在正式开始冲刺前我们会提早开一次会议，来制定冲刺计划和任务分配，一般预留2-4天来预防突发情况，得益于teambition的使用和组长的安排以及组员的配合，所以我们是有充足的时间来制定计划的

  • 冲刺中

    • 在正式冲刺中，每日每位成员都会在每日工作的在线文档中完成昨天的成就、遇到的困难、今天解决的进度、明天的计划、心得体会等，每日完成一部分的任务并做一部分的计划，所以我们在开发中的计划时间也是充分的

团队在beta阶段是如何解决队友对于计划的不同意见的？

  • 解决方法

    • 先由组长拟定初步计划，如有异议，则成员提出问题，征求各个组员的意见，探讨提出的原因以及合理性，最后投票，大多数人同意的通过

你们原计划的工作是否最后都做完了? 如果有没做完的，为什么?

  • 原计划的工作完成情况

    • 原计划工作基本完成，有部分细节未完成，详细情况见上部分表格

  • 原因

    • 时间、技术因素，前端因小组有三个端的前端开发工作量较大有部分功能未实现，后端爬虫部分因技术问题暂未实现。

  • 原因

    • 本小组的项目相较于其他组模块较多，且前端有三个端，时间较紧有部分未完成

是否每一项任务都有清楚定义和衡量的交付件?

  • 现实情况

    • 每一项任务都有明确的定义，衡量的交付件也由组员探讨得出。

项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

  • 现实情况

    • 在alpha阶段项目大致按照计划进行，除了在前后端交互和部署服务器出现了些问题，这是没有预料到的，因为这是第一次的完全线上开发，这是平日线下合作所没有遇到的，由于服务器的MySQL版本过低，导致前端调用接口返回错误，原因是未统一数据库版本。

在计划中有没有留下缓冲时间，缓冲时间有作用么?

  • 现实情况

    • 我们在冲刺前预留了2-4天缓冲时间，为项目提高容错率，学习新知识，冲刺的准备，规整项目管理，博客的准备；冲刺一般设为中段的时间，在冲刺后也预留了4-6天的时间用于后续的前后端交互，进行项目的部署，以及相应报告、博客的编写。事实上也用到了这段预留下来的缓冲时间，达到了它的效果，有着相当不错的提升效率的作用。

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

  • 收获

    • 一个合理的计划可以提高效率，同时减轻成员的压力，制定合理的计划是一项非常重要的能力，做好计划能够事半功倍。

  • 改进

    • 重来一次的话我们会选择增加制定计划的时间，而不是像过去那样匆忙，才能充分利用时间、提高效率，少走弯路。

part.03 资源

有足够的资源（可以是时间、开发资源等）来完成各项任务么?

  • 时间

    • 项目功能复杂，模块较多，且对应前端有多个端，时间上是不充足的

  • 技术

    • 本团队成员编码能力较高，完成本项目所需的技术是足够的

  • 服务器

    • 服务器为学生机，带宽，内存等明显不足以应对本项目预期的并发负载

各项任务所需的时间和其他资源是如何估计的，精度如何?

  • 时间

    • 开发的预计时间为按照开发人员经验预估，有一定误差

  • 技术

    • 成员项目经验较为丰富，可以满足

  • 服务器

    • 开发成本较低，服务器资源不足为预计之内

和alpha阶段相比，测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

  • 测试、人力和软件/硬件资源方面

    • 前端测试时间较紧，后端测试时间充分；前端由于一人负责一端人手较紧，后端三人有余；软件资源足够，硬件方面个人开发设备绰绰有余，服务器配置不足

  • 美工设计/文案

    • 在美工设计和文案方面确实低估了其难度，这方面主要由组长负责（相当业余），文案完成情况在预期值附近，但美工方面beta阶段的成品视觉感官上没有达到预期的效果。

变更的组员工作如何？如果未变更是否项目完成效率会更高？变更的组员学到了什么？对于可能的变更是否能制定应急计划?

  • 变更的组员工作

    • 1、学习测试相关知识，增加测试的覆盖面的广度与宽度
    • 2、加入本组的Gitub组织，拉取小组的合作仓库（代码、代码规范及一直以来的团队文档），了解项目的整体系统设计
    • 3、作为测试人员加入团队一同进行开发

  • 如果未变更是否项目完成效率会更高

    • 如果未变更，项目在web前台对完成度和效率会更高（离队的418是一位很专业的前端开发人员），但相对的项目都测试效率就会下降

  • 变更的组员学到了什么

    • 主要还是学到了测试的相关知识，应该也有在查看小组之前的文档、博客、代码中学到了一些其他的东西

  • 对于可能的变更是否能制定应急计划

    • 能，在团队成员能力表现较为多元化的情况下，可能的变更可以通过成员的暂时顶替作为应急计划

你有没有感到你做的事情可以让别人来做（更有效率）?

  • 现实情况

    • 可能会因为擅长的领域有所不同导致某些事情让其他人来做更高效，有的同学可能更为擅长与文档攥写、有的可能擅长于管理作为leader、有的可能更为擅长开发，但是实践本身也是一种学习，所以在时间允许的情况下期望能够让每位成员多学习新东西，有所收获。

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

  • 经验教训

    • 要准确根据当前的资源来判断估计任务的难度和所需花费的时间，提早开始冲刺预留时间提高机动性，前端测试覆盖面低就是安排不当导致的

  • 改进

    • 给予简单的任务更早的完成期限，困难的任务更长的时间，更为恰当的对资源进行分配，这样不会造成简单的任务拖延时间过长，造成人员时间上的浪费

part.04 设计/实现

项目是否经历重构？为什么需要重构？

  • 项目是否重构

    • 后端进行了重构，前端三个端未进行过重构

  • 重构原因

    • 后端由三人编写，有个人一些不同的个人习惯，导致代码结构不统一，不规范，选用了一个相对规范的格式重构了后端代码，按增删查改封装了实现层，封装了接口返回的固定字符串到常量类中等。

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

  • 单元测试（unit test）

    • 有效，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复，让前后端的代码更加健壮

  • UML

    • 因为在实现过程中，设计上的不断改变，最初的UML能起到的作用较小，有必要更新UML文档，为后续的软件迭代更新提供依据

什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

  • 出现bug的地方

    • 前后端交互，在已经编写了接口文档的前提下还是出现了许多接口使用不正确的情况
    • 服务器部署，部署花费时间过久，出现了本地服务器测试时未出现的bug

  • 原因

    • 前后端交互，由于完全线上开发，还是缺乏了一些必要的交流沟通
    • 服务器部署，服务器配置过低过卡，使用不熟练，未考虑使用的集成web应用服务器mysql版本的问题

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

  • 现实情况

    • 由于后端部分是由三个成员编写的，alpha阶段时间比较紧张，所以在beta阶段由专门一个成员负责代码规范的统一；前端由各自负责成员进行复审；前后端基本严格执行了代码规范

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

  • 收获

    • 还应更加加深成员之间的沟通，不论是更好的统一负责同一类型工作的成员之间，还是分别负责前后端的成员之间
    • 还应多学习服务器端搭建的知识，以更好的解决出现的问题

  • 改进

    • 制定更加细化的开发规范，统一开发；增加会议成员间的沟通交流以及线下的及时反馈
    • windows作为服务器还是不规范，学习使用linux平台作为服务器的搭建，更规范

part.05 测试/发布

和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？

  • 现实情况

    • 和alpha阶段相比，测试工作有提高。主要提高的的应该是测试的覆盖率与对同模块的多方面测试。

团队是否有一个测试计划？为什么没有？

  • 现实情况

    • 因为前后端完全分离，可以前端和后端分别测试，测试分为前端单元测试、性能测试、页面测试；后端API测试、单元测试和性能测试，总体来说是自下而上的测试方法，基本覆盖软件开发需要的测试。

团队是否有测试工具来帮助测试？

前端

  • 测试工具选择

    • web 前台：chorme 的插件 Frames per second、Component render、Vue.js Devtools v5.0
    • web 后台：Jtest、百度云第三方性能测试工具
    • Android：Espresso、Junit、LeakCanary

  • 测试工具介绍

    • web 前台：

      • chorme 的插件 Frames per second、Component render：chorme 的插件，可对 web 前端 js 代码进行单元测试，生成报告与可视化图标
      • Vue.js Devtools v5.0：vue 官方性能分析用的插件，可以模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

    • web 后台：

      • Jtest：jest 是 facebook 推出的一款测试框架，集成了 Mocha，chai，jsdom，sinon 等功能。
      • 百度云第三方性能测试工具：百度云提供的第三方服务，可对程序进行效能分析生成性能分析报告

    • Android：

      • Espresso：Espresso 是谷歌大力推荐的一套测试框架，从 Android studio2.2 版本开始，google 就开始支持在 as 上 espresso 自动生成单元测试代码，Espresso 测试运行速度很快，它允许你在应用程序处于静止时操作和断言等，Espresso 面向那些认为自动化测试是开发声明周期的一部分的开发人员，并且虽然它可以被用作黑盒测试，但是熟悉代码库的人可以解锁 Espresso 的全部功能
      • Junit：JUnit 是一个 Java 语言的单元测试框架。它由 Kent Beck 和 Erich Gamma 建立，逐渐成为源于 Kent Beck 的 sUnit 的 xUnit 家族中最为成功的一个。 JUnit 有它自己的 JUnit 扩展生态圈。多数 Java 的开发环境都已经集成了 JUnit 作为单元测试的工具
      • LeakCanary：使用 MAT 来分析内存问题，有一些门槛，会有一些难度，并且效率也不是很高，对于一个内存泄漏问题，可能要进行多次排查和对比才能找到问题原因，为了能够简单迅速的发现内存泄漏，Square 公司基于 MAT 开源了 LeakCanary

  • 测试工具运用

    • web 前台：

      • chorme 的插件 Frames per second、Component render：使用 chorme 的插件 Frames per second、Component render 对内部 js 方法单元测试
      • Vue.js Devtools v5.0：使用 Vue.js Devtools v5.0 模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

    • web 后台：

      • Jtest：使用 Jtest 对内部 js 方法单元测试
      • 百度云第三方性能测试工具：使用百度云第三方性能测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，生成性能模拟报告

    • Android：

      • Espresso：使用 Espresso 对内部对应方法进行单元测试
      • Junit：使用 Junit 对内部对应方法进行单元测试
      • LeakCanary：使用 LeakCanary 分析内存泄漏

后端

  • 测试工具选择

    • 后端 API 测试：Postman
    • 后端单元测试：Junit
    • 后端框架（spring boot）单元测试：spring-boot-starter-test
    • 后端性能测试：JProfiler

  • 测试工具介绍

    • 后端 API 测试：

      • Postman：Postman 是一款功能强大的发送 HTTP 请求的 工具 ,常用于 web 开发、接口测试,使用非常方便

    • 后端单元测试：

      • Junit：JUnit 是一个 Java 语言的单元测试框架。它由 Kent Beck 和 Erich Gamma 建立，逐渐成为源于 Kent Beck 的 sUnit 的 xUnit 家族中最为成功的一个。 JUnit 有它自己的 JUnit 扩展生态圈。多数 Java 的开发环境都已经集成了 JUnit 作为单元测试的工具

    • 后端框架（spring boot）单元测试：

      • spring-boot-starter-test：Spring Boot 集成的 pring-boot-starter-test 是基于 JUnit 的单元测试工具。

    • 后端性能测试：

      • JProfiler：JProfiler 是一个商业授权的 Java 剖析工具，由 EJ 技术有限公司，针对的 Java EE 和 Java SE 应用程序开发的，可模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

  • 测试工具运用

    • 后端 API 测试：

      • Postman：通过 Postman 对后端编写的所有 http（GET\POST）接口模块进行测试

    • 后端单元测试：

      • Junit：通过 Junit 对后端工具类对应方法进行测试

    • 后端框架（spring boot）单元测试：

      • spring-boot-starter-test：通过 spring boot 的测试模块（spring-boot-starter-test 基于 junit）对后端框架（spring boot）的服务层进行单元测试

    • 后端性能测试：

      • JProfiler：使用 JProfiler 模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

  • 现实情况

    • 前后端均有使用对应工具对软件的性能进行测试，从目前来看这些测试工作有用，应改进进行覆盖面更广的测试

在发布的过程中发现了哪些意外问题？

  • 现实情况

    • 在代码部署到服务器上时由于服务器和本地环境不一致出现了些问题，在修改了数据库的版本问题后成功发布

我们学到了什么? 如果重来一遍, 我们会做什么改进?

  • 收获

    • 测试是一项枯燥、但是非常有必要的软件开发的一个过程，可以在软件出现bug时快速排错，提高修复效率。

  • 改进

    • 如果重来一遍，我们会多留出一两天的时间给测试，这次冲刺中仍低估了测试需要的时间导致在即将结束时匆忙测试，前端的测试相对流于表面、不够全面。应该在测试的边界问题、测试的全面性上多下功夫。

part.06 团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？

  • 现实情况

    • 首先前后端的分工是由组员自愿的，因为在组队时有考虑到分工的问题，所以现在的组员是能够在自愿的情况下完成一个项目，每个人都能担任想要的角色，提升自己对应位置的工程能力，做到人尽其才，各有所得。

团队成员之间有互相帮助么？

  • 现实情况

    • 因为组员是合作过多次的老队友，所以在遇到问题时我们不会吝啬自己的言语、提出自己的疑问，同时需要帮助时也会尽力提供，帮助完成任务。如前后端在冲刺期间如果遇到问题会在站立式会议提出，大家可以一起给出建议（其实都是一个专业或多或少都会点，只是每人在哪方面更擅长的问题），有时往往问题能在多人讨论中被提出后轻松解决，其实也和“小黄鸭调试法”一样，当你在多人讨论时把程序的调试、纠错或测试过程中，耐心地向所有人解释每一行程序的作用，自然灵感也来了。

当出现项目管理、合作方面的问题时，团队成员如何解决问题？

  • 现实情况

    • 目前为止在项目管理上基本未出现问题，项目管理应该是本小组做的相对比较不错的一部分，有在线文档（如接口文档、前端反馈文档用于前后端交互，每日冲刺汇总用在线文档，每日会议记录在线文档等），teambition用作项目管理，qq群作为讨论及发布公告，腾讯会议进行站立式会议；合作方面，如有疑问会直接提问对应工作的负责人（比如对于前后端交互，后端就专门有设一位成员解答前端疑问），直接解决问题，谁出现问题谁修改，直至达成统一意见。

part.07 总结

  • 组员们自我总结

  • 陈浩男 221701412

    • 经过了Alpha冲刺、Beta冲刺，作为组长，我觉得我们整个小组，从团队氛围，到组员关系，到整体的团队协作能力，都有了很大的提高，一路走来，我很感谢我的小组成员，他们有实力也愿意为团队做贡献。一直以来虽然大大小小的项目都写过一些，但以往的都仅仅只是局限于完成代码层面上的。通过这次的软件工程实践，我才可以说是真真实实的体会了一个什么叫做相对完整的软件项目，从一开始的团队组建选题开始，成员有所划分，一个完整团队开发需要的有人担任产品经理、项目经理来完成项目的管理；需要开发人员分别负责前后端开发、测试等对应的开发工作。从选题过后的原型设计，需求分析、系统设计、数据库设计再到后面的两阶段的冲刺，可以说这次的时间教给我的不仅仅是代码开发，还有更多的是如何进行团队协作，一个系统的开发流程应该完成的分析与设计，测试在开发中的意义，文档对与开发的帮助，团队以及项目的管理方式，面临成员变动的处理等等。
      在这长达接近一个学期的开发中，谈谈我的队友们吧，414一直以来都是中流砥柱，很有耐心也很稳，尤其文档真的写的很棒；418作为离队成员，在团队合作期间，愿意听取队友的意见，前端的界面一如既往的很美观；420话少靠谱，在beta阶段一人扛起了两个web前端的工作；429同学可能是本次实践中收获最多的几人之一，从最开始的从未接触过前后端分离式的开发，几乎没有经验，到现在相对熟练的掌握了部分后端框架的开发使用；428是后来的新队友，积极乐观，在负责测试工作的时候为众人还是提供了不少中肯的建议；417、439基础相对较差，在冲刺的最后仍没有参与到真正的代码开发中，参与了部分测试，确实是个遗憾，他们主要负责了本团队的项目管理工作，诚然，我们小队做的还是不错的项目管理（这部分是我觉得我们组在实践中做得最好的一部分）离不开他们的付出。
      整个软工实践下来，我学到了很多，也遇到了很多困难。明白了一个道理，有些东西不是一蹴而就的，就像我们软件开发，你得先让它能跑起来，然后再去做相应的优化；就像我们的学习，我们先要有对全局的把握，然后再去逐个深入。 对于目前我们一起完成的校园芥子空间有一些亮点，也还有着不少未完成的遗憾，还不是一个可以独当一面发行的项目。希望日后还能继续完善！
      虽然软工实践就要结束了，但希望我们旗山的骄傲不散！👍

  • 黎家泽 221701414

    • 在Beta冲刺，对前面Alpha冲刺的代码做了较大的修改，主要集中在界面UI和不同代码模块的接口之间，同时完善了项目的功能。对于界面UI，改用了一致的全局变量来统一风格，并且对控件的位置做了修改，界面整体看起来更整齐美观。在本次冲刺当中，优化了不同代码块的接口调用，让代码的可读性更好，并且降低了每个代码模块的耦合度。Alpha阶段遗留的未完成的功能，在本次冲刺当中都完成了，并且增加了版本控制，把App挂到了线上，推广了出去。

  • 刘志勇 221701417

    • 在这次冲刺中，我的任务还是比较轻松的，记录会议内容，发布博客，宣传APP。首先得感谢我的队友们，很努力的完成着自己的工作，并时不时给予我帮助，很圆满地完成了本次冲刺。其次，这次冲刺我也学到了很多，收益匪浅，是一次很不错的冲刺体验。

  • 程伟行 221701420

    • 这次的冲刺中，临时接下了另一个同学的web项目，深刻的体会到了续写别人项目的苦，由于代码的风格不同，给编程带来很多的麻烦。不仅是这次冲刺，我觉得在这个学期的编程中，因为小组内每个人的不同的编码风格，也就是没对前端，后端分别进行统一的代码编写规定，给项目的进行造成许多阻碍。

  • 许光清 221701428

    • 自身是换组队员，在旧组中因团队实力有限开发过程中困难重重，来到新团队后，组内优秀大佬很多，对自己来适应新项目的过程就相对变得容易，在自己遇到任务困难时组内成员都会积极帮助解决问题，经过这十多天的冲刺对自己收获也不少，这是个优秀的开发团队，能让自己发挥自己的优势为团队做贡献。

  • 黄晓东 221701429

    • 因为这次冲刺我的任务相对简单，所以得以空出时间来看一下其他人写的代码，多读多学；另外通过解决前端反馈的问题，得细看代码才能找到出bug的原因，所以对代码的理解更加深刻，纠错的速度也变快了，也因此对一个完整的软件项目有了一个大体的认识，对前后端分离的写法也得以实践，可以说是收获满满。冲刺结束了，一方面感谢老师的指导和助教的辛苦付出，另一方面也必须感谢同组的组员，对我第一次写项目的生疏比较包容，乐于为我解答，让我能够更快地进入状态。

  • 郑斯彬 221701431

    • 在这次冲刺的一开始我认为可能很简单，但是但实际上手项目的时候还是出现了许许多多的问题，只能说学海无涯。新的知识学习的时候需要更深入。在这次的冲刺工程中同样认识到了多学其他语言带来不同观点的好处。并且认识到了代码优化的重要性。

  • 关敏 221701439

    • 在这次冲刺中，我的任务主要有记录会议内容，发布博客，后面的软件宣发和自己尝试测试。这次项目开发中，我并没有真正的参与开发工程，实际上负责的是比较轻松的文案和偶尔的帮忙。虽然如此但在随团队的开发中还是聪队友的行动中学习到了很多收益匪浅，是一次很不错的冲刺体验。

  • 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

  • PS： CMM/CMMI的五个分级特征

    • 初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。
    • 可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。
    • 已定义级(Defined)。开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。
    • 已管理级(Managed)。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，实现及时纠正。
    • 优化级(Optimizing)。可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法

  • 现实情况

    • 对于CMM/CMMI 软件成熟度的分级（初始级(initial)、可重复级(Repeatable)、已定义级(Defined)、已管理级(Managed)、优化级(Optimizing)）中的五个分级，现在的团队应该是处于略低于第三档已定义级且高于第二档可重复级的状态的，现在的团队有基本的管理制度与规程，有初步的标准化与文档化且可基于以前的实践经验重复以往成功的项目环境及条件，但缺乏完善的培训制度和专家评审制度。

  • 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

  • 现实情况

    • 我认为现在的团队处于规范阶段，因为整个开发还是基于原型中设计的功能来实现，部分代码可能还有潜在的重构规范必要性，与预期功能还有小部分差距。

part.08 提高软件工程的质量

代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

  • 代码管理的质量

    • 代码管理本次是通过一位成员来统一规范，修改不同规范处的代码，来达到一致

  • 代码复审和代码规范的质量

    • 代码复审的质量则取决于规范代码的成员的水平，当然会由其他成员再次复审，提出需要修改的地方再复工。

整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

  • 程序的架构提高

    • 最基本的面向对象设计：整体程序的架构是高内聚，低耦合的；软件的实体应对拓展开放，对修改关闭；复用的子类型应在任何场景都能替换父类型；面向接口编程；优先使用聚合或合成关系复用代码；接口使用小而专
    • 业务（逻辑）架构的提升：：使用一套方法论对产品（项目）所涉及到的需求的业务进行业务边界划分，简单的讲就是根据一套逻辑思路进行业务的拆分，总体原则是对业务进行业务边界的划分，比如做专属网站，需要把对应的细节功能清晰的划分出来，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、选择什么样的硬件等等
    • 应用架构的提升：应用是介于业务语言与技术语言之间，是对整个系统实现的总体上的架构，需要指出系统的层次、系统开发的原则、系统各个层次的应用服务，例如，上述系统中可以分为、数据层（资源层）、数据服务层、中间构建服务层、业务逻辑层、表现层，并写明每个层次应用服务
    • 数据（持久化）架构的提升：对存储数据（资源）的架构方法论，其架构原则同应用架构大同小异，即考虑到各个系统应用场景、不同时间段的应用场景对数据进行诸如数据异构、读写分离、数据库或NOSQL的策略、缓存的使用、分布式数据（数据库）策略等等
    • 技术架构的提升：对上述架构中提出的功能（或服务）进行技术方案的实现的完成与优化，包括软件系统实现、操作系统选择、运行时设计。提升技术架构时的设计面，提升专业性

  • 质量的提高的衡量

    • 底层代码性能的明显提升，占用内存、运行速度等性能指标的提高；用户体验反馈的明显提高；系统的负载能力等的上升

其它软件工具的应用，应该如何提高？

  • 现实情况

    • 几种测试工具的使用，以及项目管理软件工具，文档编写工具，美工工具等的使用的提高，就遵循一句话——熟能生巧，多学多用，多看别人优秀的作品，取其精华，去其糟粕，拥有他人优点的同时发挥自己的建树，站在巨人肩膀上看问题，自然也就提高了

项目管理有哪些具体的提高？

  • 现实情况

    • 站立式会议第一天分工后成员量化各自的任务，然后在teambition上分配任务，每日拖动完成的任务，来展示项目的完成进度，分工明确，同时量化细致，可以以此来分配成员的贡献度。

项目文档的质量如何提高？

  • 现实情况

    • 一方面是细化任务，更加具体，才能有更高的质量，另一方面是多观摩别人的文档，吸取经验。

对于人的领导和管理， 有什么具体可以改进的地方？

  • 现实情况

    • 要有适当的奖惩机制，例如每日工作在规定时间内未汇报的则给予适当的（全部成员一致同意的）惩罚，提早完成分内工作的则给予奖赏。在调动成员的工作积极性方面，仍有提升的空间。

part.09 项目展示

旗山的骄傲

旗山的骄傲

posted @ 2020-06-12 00:23  旗山的骄傲  阅读(226)  评论(3)  编辑  收藏  举报