第3-6章作业汇总

第一题:本周的作业请参照此文: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道以上的题目,并保存在文本文件中,并且保证题目不重复。

难度选择

    针对同一年级的学生水平也会高低不同这一情况,我们将为用户准备 自测水平的题目,之后根据用户的水平层次来分配难易题目。

年级排行榜

    为了让提高同学们的学习动力,我们还将设置年级排行榜,即我们对同一年级学生的答题总题目,正确回答的总题目,答题速度等数据进行统计,利用上述数据作为指标来进行排行,可以让同学们看到其他同学的回答情况,不断向优秀的同学学习!

每周竞赛

    设置每周一次的数学答题竞赛,在良性竞争的比赛下,让所有人的数学成绩可以逐步提升。

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

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

 

posted @ 2016-09-25 14:24  ghll_coder  阅读(189)  评论(0编辑  收藏  举报