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

Posted 2020-08-10 哈哈爱java

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的使用率还有待提高，大家已经学会了使用，要充分利用起来。