第一题：本周的作业请参照此文：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html 制定本组项目的GitHub版本更新流程。--By林培文
通过文档的学习，我们知道它需求是开发的起点，先有需求，而后有功能分支。功能开发完成后，该分支就合并到主分支，进而删除该分支，即”功能驱动式开发”。首先，我们先了解下三个流程的基本细节：
Git Flow：项目长期存在两个分支，Master和Develop，分别用于发布及开发。该流程中，还存在短期分支，进行功能开发、维护等。但很多项目持续发布，此时维护两个长期分支，维护开发较大。
Github Flow：开发过程中始终保存一个长期分支，即Master，一旦有新的需求，便从主分支中拉出新的分支，在Commit新功能后，发出pull request让别人注意到你的修改，修改被接受后，Merge进Master。最后，删除该分支。
Gitlab Flow：一个用于仓库管理系统的开源项目，其主要功能如下：代码托管服务；访问权限控制；问题跟踪、bug的记录、跟踪和讨论；Wiki，项目中一些相关的说明和文档；代码审查，可以查看、评论代码等。
通过对比以上三种方式，依据项目需求和现实情况，小组最终决定在Android平台上实现该项目。并且小组约定按照如下方式进行操作。
首先，小组成员各自将代码Clone到本地客户端。
然后，依据如下对应的工作流程操作：
1.依据需求建立对应功能分支;
2.对代码进行修改;
3.完成了某项功能，提交(commit，只是提交到本地代码库);
4.pull request到Web端，让别人看自己所做的更改，如果存在冲突，解决冲突后在pull request。
5.小组成员检查后，在Web端进行Merge。
到目前为止，本小组都是按照该方式进行开发，其结果如下：
第二题：制定本组的代码规范、GitHub提交源码的标准。--By梁旭晖
在一个团队里，代码规范是一件很重要的事情，因为团队之中，伙伴之间可能需要看懂彼此的代码，这个时候，代码规范就显得尤其重要。
一、代码风格规范：
1、去除没有用到的引用，避免因为类引用没有使用而警告。
2、使用4个空格的tab键进行缩进。
3、条件，循环语句必须使用{}来包含操作，即便只有一句话。
4、条件，循环语句的{}上下要对齐，每个“{”和“}”都独占一行。
5、不要把多条语句放在同一行上，即便是变量声明，也最好另起一行。
6、已经废弃的旧代码请删除，不要留注释，注释的只能是对于代码的解释。
7、命名要规范：
1）不允许使用汉语拼音命名。
2）尽量少用缩写，但如果用了，要明智地使用，且在整个工程中统一。
3）避免使用类似的名字，或者仅仅是大小写不同的名字。
4）全局变量大写。
5）不要使用没有意义的名字，比如haha。
6）不要使用单个字母，比如x，y。
7）无意义的循环变量，可以直接用 i，j，k等。
8）多个单词拼接而成的变量名，后面的单词，首字母大写。
9）避免使用长的名字（小于 15 个字母是个好主意）。
8、注释要规范：
1）代码细节的注释使用//，较长或者多行注释使用/* */。
2）写明类目的，借口的目的。
3）对于比较复杂的函数，提供调用示例。
4）为不容易理解的变量提供注释。
5）异常抛出需要提供注释。
6）代码修改，提供注释。
7）自定义函数的功能需要注释
8）复杂注释放在函数头，针对一句的注释放在句末。
二、代码设计规范
1、如果一个功能要多次使用，请把它封装为函数
2、针对接口编程，不针对具体类编程
3、一个类完成一个具体的功能，不要有太大的类，不要把很多功能都封装在一个类中。
4、尽量少用全局变量和局部静态变量。
5、不要使用goto
6、非必要的情况下，不要使用多态
7、非必要的情况下，不要使用继承。
8、函数的参数最好在5个以内。
9、一个函数的长度，最好在150行以内。
10、布尔表达式内的条件在3个以内
11、if 嵌套3层以内
12、不要省略返回值的类型，可以用void
13、函数的返回值要和声明类型一样，不要依赖于自动转换。
14、传入函数的参数，函数内部要验证其正确性，不能默认用户传入的都是正确的参数。
参考文献：http://blog.chinaunix.net/uid-9354-id-2425025.html
http://blog.csdn.net/kimylrong/article/details/7700311
http://www.docin.com/p-655201628.html
http://wenku.baidu.com/view/8b03b3ff0242a8956bece430.html
https://www.douban.com/note/82618786/
第三题：组长组织每周例会（可以使用群微信群试验一下每天沟通项目开发进度的方法）需要有证据能够在博客上公布。--By郭青云
我们组的小伙伴们在接到每周的作业后，无论是在线上还是线下都积极参与了讨论哦。小伙伴们还热情地为项目的开发提出了很多很有用的提议，因为线上讨论的截图太多，所以这里决定只选取每周讨论内容的四张截图放在了下面^_^.
第一周：第一周作业任务
第二周：第二周作业任务
第三周：项目需求讨论
第四题：根据邹欣老师的教材相关内容，确定小组成员的角色，细化项目需求、时间计划、列出产品积压工作项和预计开发时间。--By侯伟婷
经过和小组成员的讨论，我们确定了有关小组成员角色、项目需求、时间计划等事项。
根据之前的项目经验和各项技术的熟练程度，我们小组的角色分工如下。
表格1 角色分工
|
成员 |
角色分工 |
|
林培文 |
工程师、UI设计，前端开发 |
|
郭青云 |
工程师、系统后台框架设计、接口设计 |
|
梁旭晖 |
工程师、需求分析、后台维护 |
|
侯伟婷 |
工程师、系统测试、编写文档、数据库设计 |
提到项目需求的话，就要着重说明一下项目的功能性需求，我们看到了上一届完成的项目，大体思路是和他们一致的，就是给出一定的题目由用户答题，用户答题之后，后台负责判断答案的正确与否。但是我们在此基础上做出了如下拓展：
表格2 项目功能细化与需求扩展
|
拓展功能 |
功能描述 |
|
年级选择 |
按照小学具体情况，共设置6个年级的题目，不同年级的学生选择本年级的题目答题，并给出答对和答错的题目数量。 |
|
题目要求 |
一次可以批量给出100道以上的题目，并保存在文本文件中，并且保证题目不重复。 |
|
难度选择 |
针对同一年级的学生水平也会高低不同这一情况，我们将为用户准备 自测水平的题目，之后根据用户的水平层次来分配难易题目。 |
|
年级排行榜 |
为了让提高同学们的学习动力，我们还将设置年级排行榜，即我们对同一年级学生的答题总题目，正确回答的总题目，答题速度等数据进行统计，利用上述数据作为指标来进行排行，可以让同学们看到其他同学的回答情况，不断向优秀的同学学习！ |
|
每周竞赛 |
设置每周一次的数学答题竞赛，在良性竞争的比赛下，让所有人的数学成绩可以逐步提升。 |
细化项目需求后，就要说一说对这个项目的时间安排了，经过我们组的讨论，至少要三周才能完成，且是在没有其他学科，没有其他课题或项目的影响下。其中至少需要两周时间来进行界面的设计工作，同时后台服务器框架搭建也需要一周，后台的功能代码按照模块来并行进行的话，也会花一段时间。
预计开发时间在两周之后，因为包花费一周时间进行需求分析，开发工具和环境的准备，同时正逢国庆节，所以大概会在两周之后进行项目的开发工作。