第3-6章作业汇总

Posted 2020-08-10 ghll_coder

第一题：本周的作业请参照此文：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道以上的题目，并保存在文本文件中，并且保证题目不重复。
难度选择	针对同一年级的学生水平也会高低不同这一情况，我们将为用户准备 自测水平的题目，之后根据用户的水平层次来分配难易题目。
年级排行榜	为了让提高同学们的学习动力，我们还将设置年级排行榜，即我们对同一年级学生的答题总题目，正确回答的总题目，答题速度等数据进行统计，利用上述数据作为指标来进行排行，可以让同学们看到其他同学的回答情况，不断向优秀的同学学习！
每周竞赛	设置每周一次的数学答题竞赛，在良性竞争的比赛下，让所有人的数学成绩可以逐步提升。

　　细化项目需求后，就要说一说对这个项目的时间安排了，经过我们组的讨论，至少要三周才能完成，且是在没有其他学科，没有其他课题或项目的影响下。其中至少需要两周时间来进行界面的设计工作，同时后台服务器框架搭建也需要一周，后台的功能代码按照模块来并行进行的话，也会花一段时间。

　　预计开发时间在两周之后，因为包花费一周时间进行需求分析，开发工具和环境的准备，同时正逢国庆节，所以大概会在两周之后进行项目的开发工作。