第一题 我组项目的GitHub版本更新流程

通过资料搜集,我们知道目前广泛使用的工作流程有Git flow、Github flow和Gitlab flow。

由于希望小组成员都可以参与到这个项目中来,我们小组最终要开发一个网站。

在学习了阮一峰老师的博文后,我们认为 Github flow 这一工作流程更加适合我们组的开发,具体流程如下图:

其实这三种 workflow 都被广泛地采用,但我们选择使用Github flow 这一工作流程,这是鉴于我们项目的自身特点 :

(1)项目并不大,且分工比较明确(前后端分离),所以只保证一个活跃的 master 分支是足够的;

(2)另外,我们后台的服务也是使用 jenkins 持续集成的(见之前后端环境搭建的博客

所以,只保证一个分区是合适的;

(3)还有,拥有多个分支一般是有许多外部客户来使用的

这样人们可以保证自己拿到的合适的分支(比如 stable 版本供 production 环境使用),而这在我们的项目里是不必要的。

第二题 代码规范、GitHub提交源码的标准

代码规范:https://files.cnblogs.com/files/msec2016/代码规范.pdf

GitHub提交源码的标准:在组员按照上述指定的代码规范完成编写以及测试后,交由组长进行最后审核,完成后提交。

第三题 周例会记录

第一周的时候我们在老师所留作业的指导和带动下学习建立了自己的博客,并且在课下积极的找同伴碰面交流

熟悉的同时也定下了我们课程最后项目的大致构想。

这也是在交流探讨第一次作业中的相关问题,集思广益,发表自己的相关观点。

第二周的作业中,我们学习使用了git,github等内容及其使用,掌握了客户端及命令行的操作方法。

同时完成本周任务的同时我们在组长的带领下开始着手于最后项目的研究。

组长写出了一个前端页面的demo,实现前后数据的传输,我们学习之后也开始了各自的思考和尝试。

确定了我们的编程语言,制定出开发计划和代码规范。方便后续工作的顺利进行。

探讨使用的工具同时也在进一步准备14章课程的讲解准备。

第四题 组内角色任务分配

(1)小组内人员角色分配:

按照书中的团队模式,我们团队属于:

>业余剧团模式(Amateur Theater Team)

这样的团队在每一个项目(剧目)中,不同的人会挑选不同的角色。

在下一个剧目中,这些人也许会换一个完全不同的角色类型。

各人在团队中听从一个中央指挥(导演)的指导和安排。在学生实践项目或培训项目中,这样的事情经常发生。

其中组长在本项目中相当于“导演”,组员们根据自己的能力与爱好选取合适的位置与任务,最终共同完成本项目。

>大体分工如下:

缪东旭(组长):

负责整个项目的任务统筹安排,角色分配,人员督促。

由于本组的三位组员编程能力以及实战项目经验较少,组组长最重要的任务也在于环境搭建与后端代码。

刘莞姝(组员)刘康宁(组员)陈岩岩(组员):

前端页面设计、代码编写,软件文档与博客维护。

特别说明:出于对本组的人员经验的实际情况的考虑,我们的人员角色分工有些不符常规,没有把具体任务划分的很详细,

让每一位组员负责特定的一个部分,例如需求分析特定到人,测试特定到人,界面分析特定到人等等,我们只是定出了大体方向,比如我们进了前后端的工作划分,这样在划分的大模块上面,

我们互相商量共同进行项目的推进,虽然我们也考虑到了这种方式可能有碍于项目的推进和实施,但我们为了最大化的完成作业任务只好采取这样的方式。

具体的分工,比如何人写哪个具体页面,我们会在项目持续过程中具体分配到个人。

(2)项目需求的细化:

1)功能性要求:

用户登录需要验证,不同身份获得不同的权限:例如:老师,学生及普通用户;

老师进入系统可以查询或修改学生成绩等;

学生或者普通用户进入系统可以进行四则运算的不同功能操作页面,例如:练习,考试等;

对于运算都能实现判断功能进行出错率的统计和打分,并保存到个人信息中去;

2)性能要求:

精度:输入输出都要求数据是double类型的。

时间要求:练习无时间限制,考试需要规定具体时间。

灵活性要求:性能稳定,不会出现错题,判别失误或者记分出错的情况。

(3)时间计划:

>时间计划(计划于接下来的三周完成项目):

9/26 - 10/1:用户可以在网站上完成简单地交互(出题、答题)

10/4 - 10/8(国庆期间时间安排不强制):用户登录、注册,参看自己的答题情况

10/10 - 10/15:完成项目的融合与优化

其实,整个项目的安排还是挺紧张的,主要是各位同学对相关技术的预备知识有限,比如说前端页面,大家可以说是从零学起。

大概会问“那为啥要做出这样的技术选型”?

Well,有句话说:

The best time to plant a tree was a decade ago, followed by now.

(4)产品积压工作项:

就目前来说我们的产品积压工作项主要是:

1)需求还不够完善,不够细化;

2)任务分工还存在问题,不能完全的将细化的工作内容指派给个人,不用极其细化但也需要进行明确;

3)编程的部分进展稍慢,需要提高速度将计划内的工作按时完成;

我们相信我们自己的团队能够通过自己的努力在最后收获到最满意的结果。加油!