现代软件工程 第3-6章 作业

1.GitHub版本更新流程

题目:请参照此文:http://www.ruanyifeng.com/blog/2015/12/git-workflow.html 制定本组项目的GitHub版本更新流程。

    广泛使用的工作流程有Git flow、Github flow和Gitlab flow。比较了三种工作流程,我们选择了Github flow流程。有以下几点原因:

       1.项目规模较小,用Git flow的简化版就能达到我们的需要。

       2.它长期只有一个分支 master,利于管理

       3.因为项目要不断修改,不断改进,需要“持续发布”

       4.小组成员编码能力有限,很多地方需要大家一起协作,所以不便分成很多分支

 

(引用:http://www.ruanyifeng.com/blog/2015/12/git-workflow.html)      

      具体Github flow更新流程操作如下:

      第一步:创建新的分支

      首先我们用git checkout -b flowtest 命令 创建一个分支,git branch 命令可以看出现在有两个分支,并且现在在flowtest 分支。

      第二步:发起一个pull request

      以代码规范文档为例。首先将文档在本地创建之后,用git add、git commit、git push命令之后,上传到远程分支flowtest中。这时,这个分支目前的工作已经完成,可以进行合并操作了。因为是多人协作,所以我们要通知其他Collabrators。我们可以在Github网站上看到pull request页面。这时Pull request数量还是0。

      此时发起一个pull request有两种方法。一个是点开pull request页面,读完introduction之后,会有一个create a pull request的链接,点击直接可以发起。

      另一种方法是在code选项卡这点击New pull request按钮。

       最后在Open a pull request页面填写相关的文字。(文档支持markdown)就可以发起一个pull request了。

      第三步:评审文档、代码

      当一个pull request发起后,小组的所有成员都可以用自己的账号看到这个请求。这时,大家可以提交自己的想法,有什么需要改进的,如果觉得已经达到要求,就可以通过Merge pull request按钮,将这个分支merge到主分支。

     

      第四步:删除分支

      pull request被接受后,这个分支就没有作用了,此时我们将该分支删除即可。

      

      这时,分支就被我们删除了,同事pull request也被我们关闭了。这时就剩下master主分支了,可以继续进行开发。但我们也可以随时查看之前的pull request的操作历史。

      因此,以后我们小组的Github版本更新流程就采取Github flow的方式,具体操作就按照上面的说明来操作。

 

2.代码规范、GitHub提交源码标准

题目:制定本组的代码规范、GitHub提交源码的标准。

   ①代码规范

      经讨论,我们决定用ajax+C#.net开发网页,用Visual Studio IDE开发。因此,我们制定了C#的代码规范。

      因为代码规范特别多,就不在这一一列举了,以下是代码规范的简单目录。具体的代码规范,请前往https://github.com/Hahalovejava/Calculate 在Github 中,我们上传了C#_code_standard.docx和Code_Standard.md两个版本的代码规范。

      一、代码注释

           1、代码注释约定

           2、模块头部注释规范

           3、方法注释规范

           4、代码行注释规范

           5、变量注释规范

     二、命名规则

          1、命名的基本约定

          2、类和接口命名

          3、方法命名

          4、变量命名

          5、组件名称缩写列表

      三、其它规范

          1、编程风格

          2、空白

          3、错误处理

          4、其它

      ②GitHub提交源码标准

     1、创建自己需要的分支,分支命名要能体现是谁创建的分支,或者需求是什么

        2、clone主分支上的文件到本地,在本地,自己的分支上进行自己的工作。然后通过git add、git commit、git push上传到远程GitHub中。要注意的是,一定要先传到自己创建的分支上,先不要直接传到主分支master上。即 git push origin <分支名>(不可以是master)

        3、发起pull request,等待其他小组成员的评价和确认。这里注意,每次必须要让每位小组成员回复一下。这样能确保每个人确认项目的进度。如果着急需要进行下一步的时候,可以微信,短信通知小组其他成员。

        4、由组长将分支merge到master上,并delete该分支

        注意:每次进行操作的时候,必须写好comment,便于以后查看。

 

3.例会

题目:组长组织每周例会(可以使用群微信群试验一下每天沟通项目开发进度的方法)需要有证据能够在博客上公布

    我们四个因为住在毗邻的两个宿舍,沟通特别方便,所以多数情况以线下交流为主。但同样的我们在9月7日建立了微信群,便于交流。   

    ①第一周

    创建微博后,和大家首先沟通了第一篇自我介绍的博客,定下了大体的方向,由组长进行整理。

         

 

      之后,我们就第一周的作业进行了分工。本着我们四人小组的原则,题目分得相当随意~

                 

              

    ②第二周

   第二周大家都是分别在进行学习,线下沟通,调试和修改bug都是在线下。相应的线上交流有些欠缺。

            

    通过线上交流,我们发现了博客园账号不能同时编辑修改的问题。这个我们也反映在了上周的博客中。之后将小组帐号变成了组织也都及时在微信上通知了大家。所以说及时沟通是相当重要的~

                     

 

        ③第三周

     第三周我们首先上网查找资料,然后由晓丽同学整理了代码规范,并编辑成word文档。之后由组长上传到github上并制定了github提交源码标准。之后小组对项目的时间上和分工上做了一下讨论

                                       

                                               

 

4.分工和时间计划

题目:根据邹欣老师的教材相关内容,确定小组成员的角色,细化项目需求、时间计划、列出产品积压工作项和预计开发时间

 

       ①小组成员角色

       根据邹欣老师的教材相关内容,和我们小组自身的情况,我们确定了团队的模式为功能团队模式(Feature Team)。因为小组成员的编码能力有限,都有待提高,所以我们选择功能团队模式。就是小组成员之间平等协作,共同完成一个功能,在这个功能完成之后,再一起去完成下一个功能。这个模式需要小组内的交流比较频繁,我们四个住的比较近,每天沟通非常方便,也很适合这种模式。

     之后我们按照MSF基本原则,大家共同讨论制订了大家的小组成员角色。

   

 

 

          ②细化项目需求

     经讨论,我们暂时将项目的需求进行如下的细化。剩下的细节,功能完善还要在不断开发的过程中进行完善。

     

  

    ③时间计划和预计开发时间

     

     

     ④产品积压工作项

    目前的产品积压工作项是用户的需求还不够完善,目前只考虑到用户是小学生,应该考虑到很多小学生可能还不太会使用电脑,可能由家长来操作。本周要将需求做的更完善,要调查取证。同时小组成员的环境有的还没有完全配置成功,这周要尽快将环境匹配好。Github的使用率还有待提高,大家已经学会了使用,要充分利用起来。

posted on 2016-09-25 15:16  哈哈爱java  阅读(208)  评论(0编辑  收藏  举报

导航

TOP