构建之法与IC/ID

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业要求在哪里	个人阅读作业#2
我在这个课程的目标是	学习并掌握利用软件工程的思想与方法构建大规模高质量的软件系统的能力\团队协作能力等
这个作业在哪个具体方面 帮助我实现目标	通读教材，从全局初识软件工程；了解版本管理软件，入门持续集成，为项目开展做准备

 

 

 

阅读提问

• Q1 Bug or feature?

  第一章概论有这样一段话:

  软件行业也有一句著名的笑话:It's not a bug, it's a feature!很多人认为有Bug就是不合格,没有Bug就是质量完美．其实这也未必．

  在软件工程里什么是bug呢? 作者认为软件的行为与用户的期望不一样,就叫做bug,是否是bug,取决于用户\开发者的不同角度. 我认为这样说有一定道理. 我认为在不同阶段对待bug的态度和处理方式不同. 在软件开发过程中,如果确立了需求, 绝大部分被发现的bug都需要在软件测试中被解决, 这样才能保证软件的功能和质量. 但是在产品发布, 维护, 更新阶段,我们是否发现了bug就要立即解决呢? 我想这个涉及到 修复成本等问题.

  It’s not a bug, it’s a feature. 我认为这句话在其他领域容易找到生动的例子,比如 酒精对神经的麻痹作用, 破洞牛仔裤等等. 在软件工程领域,有什么生动的例子吗?仔细想了想,是否朋友圈下拉刷新的2-3s的等待时间 在用户看来是恼人的bug, 在设计者看来就是feature呢? 有没有其他例子呢, 还是说这句话只是一句玩笑话……

• Q2 单元测试必须由最熟悉代码的人(程序作者)编写吗？

  作者在第二章个人技术与流程中讲单元测试的时候提到这样一段话：

  单元测试必须由最熟悉代码的人（程序的作者）来写．代码的作者最了解代码的目的，特点和实现的局限性．

  我对此有所疑问. 单元测试的目的是对软件中的最小可测试单元进行检查和验证, 是在软件开发的过程中要进行的最低级别的测试活动.我认为单元测试很重要, 特别是在结合回归测试, 自动化测试的情况下,单元测试很方便且性价比高. 但是也要认识到单元测试只能对程序正确性做出基本的测试, 更不能保证整体软件功能的正确性. 单元测试必须由作者来编写吗? 作者编写单元测试的优势很明显,熟悉程序结构, 能够快速,有针对性地构造单元测试, 但是缺点也很明显, 那就是作为程序的作者,孩子的父亲,大部分人(至少我)都会有手下留情的心态,或许对于程序的边界输入的考虑有所益处,但很多时候也会局限于思维定势,从而忽略了很多问题,而往往这种疏忽是重大的,在其他人看来是显而易见的.

• Q3 结对编程的实用性和搭档的选择

  第四章的两人合作作者提到了为什么要结对编程.

  在结对编程的模式下,一对程序员肩并肩,平等地,互补地进行开发工作.他们并排坐在一台电脑前, 面对同一个显示器,使用同一个键盘,同一个鼠标一起工作.他们一起分析,一起设计,一起写测试用例,一起编码,一起做单元测试,一起做集成测试,一起写文档,等等.

  此后作者用大量的语言解释了结对编程的工作内容和好处,并解答了作者认为读者常见的困惑. 但我还是表示怀疑. 我认为两人轮流写代码\审核等的工作方式要求极高且没有必要.结对编程,需要双方能够平等无障碍的交流, 需要相互磨合,相互学习, 这要求对方和你的学识水平差距不能太大, 性格互补且彼此之间有不浅的交情(这样才能避免摩擦和尴尬)……如果结对编程的队友选择很简单的话,那我认为全国就没有那么多单身狗了 作者还援引民航飞机的PM和PF来说明结对编程的合理性，　但我认为每个领域有每个领域的特点不能简单类比．民航对飞行安全必须有极高的要求，所以需要PM和PF轮换角色,以及对飞行指令的执行与确认, 确保万无一失. 而软件开发这种开发强度高, 对快速开发有要求的领域结对编程恐怕就没那么合适了.

• Q4 如果你是病人,你希望你的医生是下面的哪一种呢?

  在第三章软件工程师的成长的联系与讨论中有这样一段话:

  作为一个软件工程师, 你觉得自己表现如何? 有没有这样的体会:

  看书的时候觉得“技止此耳”，开发项目的时候才觉得实际情况和书上讲的都有一些出入，一些重要的细节书上没有提。我们很多人是边看asp.net的书, 边开发asp.net 的项目，这相当于一边看医学书一边动手术……如果你是病人，你希望你的医生是下面的哪一种呢？

  a）刚刚在书上看到你的病例，开刀的过程中非常认真严谨，时不时还要停下来翻书看看……

  b）富有创新意识，开刀时突然想到一个新技术、新的刀法，然后马上在你身上试验……

  c）已经处理过很多类似的病例，可以一边给你开刀，一边和护士聊天说昨天晚上的《非诚勿扰》花絮……

  d）此医生无正式文凭或正式医院的认证，但是号称有秘方，可治百病。

  事实上，很多软件项目就是用a）或者b）这样的方法搞出来的。当然 也有一些人走d）这条路。

  ——《构建之法》第三章

   

我认为作为病人我当然希望是c), 但作为开发者 和一个学生, 我不可避免地成为了a) b)这样的“医生”……. 我的问题是, 这个阶段会持续多久呢? 计算机领域新技术层出不穷, 每次项目开发好像都不可避免的需要接触新的知识和技术, 这对我们开发者来说也是能力上的锤炼,也能收获个人的成长.做a和b医生难道就一定不好吗?什么时候可以成为c医生呢?

• Q5 在校学生如何为成为一个PM做准备?

  你是否觉得你的长处不在于写代码和debug，而是协调、沟通，让一个团队或组织有效运转起来？你是否喜欢表达，善于和各种专业背景的人沟通？你是否经常思考如何该井生活中点点滴滴的小问题？你是否会思考这样的问题么：新浪微博、豆瓣、qq、微信都可以社交，它们的定位、产品特性、用户群、解决的需求，有什么不同？你是否对以下领域感兴趣，甚至自己找过相关的书来看：心理学、社会学、组织行为学、统计学、商业模式？

这是第九章项目经理的联系与讨论中的一个开放性问题.看起来PM对综合素养能力要求很高,需要具备一定的专业素养;需要对各个学科领域有独到的见解;需要具备团队沟通能力,领导力和很强的管理组织能力;需要创新思维和对世界的洞察力. 我的问题是, 相对于软件工程师这些对专业能力貌似有显性的要求的职业, PM对于能力的要求似乎“看不见也摸不着”.作为在校学生应该如何培养这些能力呢? 企业面试PM时又是如何在短时间内考察的呢? PM大都是计算机专业的同学吗? 具体到北航,情况又是怎么样的呢?

调研源代码版本管理软件

调研并了解了基于源代码版本管理软件Git的项目管理工具Github、Gitlab、Bitbucket，结果如下：

• 平台介绍：

  • github是第一个供“用Git进行版本控制系统的软件开发项目”使用的基于Web的代码托管服务，是目前全球最大的开源社交编程及代码托管网站，于 2008 年 4 月 10 日正式上线，后被微软收购。

  • GitLab 是一个利用Ruby on Rails开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过 Web 界面进行访问公开的或者私人项目。

  • BitBucket 是 2008 年创建的源代码托管网站，采用 Mercurial 和 Git 作为分布式版本控制系统，同时提供免费账户和商业计划。2010 年被 Atlassian 收购，与 Atlassian 的其他服务(Git GUI SourceTree、HipChat、Cloud9)顺利集成，主要面向慈善企业和企业用户/其主要市场是大型企业。

• 共同点：

  这三个都是代码托管服务平台，都支持一些基础的功能：

  • 拉取请求

  • 代码审查

  • 内联编辑

  • 问题跟踪

  • Markdown支持

  • 双向认证

  • 高级权限管理

  • 托管的静态网页

  • Fork/Clone Repositories

  • 代码段

  • 第三方集成

• 各自特色

  经过简单调研，发现github、gitlab、bitbucket在Pull (or Merge) Request Process、Integrations、Visibility for Projects and Pricing 三个方面有各自特色。

  • Pull (or Merge) Request Process

    Github：

    The pull request process in Github is designed with team-based projects in mind. In order to facilitate that workflow, Github provides some interesting features:

    • Assign pull requests to teammates

    • Attach milestones, projects, and labels to provide context

    • Subscribe to be notified when the pull request changes

    • Diff of changes between source and base branch

    • One-click merge and delete source branch

    • Integration with external continuous integration tools

    • Pull request templates to ensure contributing guidelines are being followed

    • Conversations around parts of the code that require resolution

    • Required reviews to ensure that every pull request is signed off by someone before the merge

    Gitlab：

    While named differently, Gitlab merge requests work pretty much the same way as pull requests. You get most of the same core features:

    • Assign merge requests to teammates

    • WIP (Work In Progress) indicator to open merge requests before they're ready to be merged

    • Integration with milestones/labels for merge request context

    • Team members can subscribe to be notified when the request is merged

    • Diff of changes between source and base branch

    • Integration with external continuous integration tools

    • One-click merge and delete source branch

  • Integrations（持续集成和部署）

    • github可以在github market和works with Github与第三方工具继承，并允许第三方应用通过github销售服务。另外，GitHub具有强大的REST API，支持自定义集成。

    • Bitbucket由Atlassian拥有，因此，如果您使用Jira或Bamboo，可能会喜欢Bitbucket的内置集成。Bitbucket还拥有一个强大的app market和一个API，可让您构建自己的集成。还值得注意的是，Bitbucket拥有自己的pipelines工具，可以进行持续集成和交付。

    • gitlab内置集成较少，但它是开源的，意味着可以自定义代码的任何部分。另外，gitlab还提供了强大的 plugin system and REST API.；提供了内置在平台中的持续集成工具CI。

  • Visibility for Projects and Pricing

    云托管：

    

    自托管服务：

    

    因为只有gitlab是开源的，使得其自托管服务最便宜。

GitLab让开发团队对他们的代码仓库拥有更多的控制，相比于GitHub，它有不少的特色：允许免费设置仓库权限；允许用户选择分享一个project的部分代码；允许用户设置project的获取权限，进一步的提升安全性；可以设置获取到团队整体的改进进度；通过innersourcing让不在权限范围内的人访问不到该资源。 从代码私有性方面来看，有时公司并不希望员工获取到全部的代码，这个时候GitLab无疑是更好的选择。但对于开源项目而言，GitHub依然是代码托管的首选。

• 参考

  https://stackshare.io/stackups/bitbucket-vs-github-vs-gitlab

  https://zhuanlan.zhihu.com/p/23007198

  https://www.jianshu.com/p/dd62a5c3e6bc

调研持续集成/部署工具

我使用了OO课程中的[oo_2020_preview2_18373407_pre2_task2]（https://gitlab.buaaoo.top/oo_2019_homeworks/oo_2020_preview2_18373407_pre2_task2）,分别使用Gitlab CI和GitHub Action工具,实现在线编译\运行\测试.

总的来说,实现持续集成和部署, 需要本地使用Maven构建项目, 构造简单的Junit的测试, 编写相应的yml文件,然后上传到平台上,依托gitlab/github的 现成工具,实现持续集成/部署.具体效果如下:

• 使用gitlab

  • gitlab代码仓库

  • .gitlab-ci.yml文件:

     image: local-registry.inner.buaaoo.top/image-dev/java:8u201
     ​
     stages:
       - build
       - test
     ​
     before_script:
       - java -version
       - javac -version
       - mvn -v
     ​
     mvn_build:
       stage: build
       script:
         - echo "Build Project"
         - mvn compile
       artifacts:
         paths:
         - target
     ​
     mvn_test:
       stage: test
       dependencies:
         - mvn_build
       script:
         - echo "Run JUnit4"
         - mvn test
         - echo "Code coverage 99%"
       coverage: '/Code coverage \d+/'

  • 效果截图

    

  • 参考资料

    https://gitlab.buaaoo.top/help/ci/quick_start/README.md

• 使用github

  github使用持续集成/部署类似,只是某些名词换了个说法而已, 但大部分与gitlab的使用有对应的地方.在能简单使用gitlab CI之后, 上手github Actions很快.

  • github代码仓库

  • .yml文件

     # This is a basic workflow to help you get started with Actions
     ​
     name: CI
     ​
     # Controls when the action will run. 
     on:
       # Triggers the workflow on push or pull request events but only for the main branch
       push:
         branches: [ main ]
       pull_request:
         branches: [ main ]
     ​
       # Allows you to run this workflow manually from the Actions tab
       workflow_dispatch:
     ​
     # A workflow run is made up of one or more jobs that can run sequentially or in parallel
     jobs:
       # This workflow contains a single job called "build"
       build:
         runs-on: ubuntu-latest
     ​
         steps:
           - uses: actions/checkout@v2
           - name: Set up JDK 1.8
             uses: actions/setup-java@v1
             with:
               java-version: 1.8
           - name: Build with Maven
             run: mvn compile
       test:
         runs-on: ubuntu-latest
         needs: build
         steps:
           - uses: actions/checkout@v2
           - name: Set up JDK 1.8
             uses: actions/setup-java@v1
             with:
               java-version: 1.8
           - name: Build with Maven
             run: | 
               echo "----Run JUnit4----"
               mvn test
               echo "----Code coverage 99%----"

  • 效果截屏

  • 参考资料

  • http://www.ruanyifeng.com/blog/2019/09/getting-started-with-github-actions.html

    https://docs.github.com/en/actions

简要谈一下你使用CI和CD工具后的看法，其中包括但不限于

• 对所使用CI/CD工具的特点、特性描述

• 对上述特点、特性的进一步分析，包括从技术、产品、需求等角度展开

• 对于上述的各个工具，进行一个系统化的对比，并说明每种工具的优势和劣势区间，以及所适应的场合

  gitlab CI是gitlab内置的持续集成服务工具.如果在仓库根目录下添加.gitlab-ci.yml文件, 为gitlab项目配置使用Runner的话,每次提交时就会触发pipeline,gitlab将自动识别.gitlab-ci.yml文件并执行相应脚本,从而受喜爱持续集成.

  初步体验发现,gitlab有shared runner,而且CI非常容易快速上手，工具很强大．

  github Actions实现了类似的功能. 持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。另外,github依托巨大的开源优势, 创建了marketplace,可以利用现成的优秀actions实现持续集成/部署,我觉得marketplace是github Actions最显而易见的特色.

  经过更深入地调研, 我找到了如下资料:

  • Gitlab vs Github Continuous Integration Comparison

  • GitHub Actions vs GitLab CI

  另外我发现在2015年的6月末，发布了极具战略意义的重要版本 GitLab v7.12，这个版本支持了 SAML 认证，Merge Request 准许功能（类似 GitHub 上的手动允许合并功能），以及最重要的一点：对原本的 CI 功能进行了重构，支持了 .gitlab-ci.yml 使用 CI 配置文件、内置了 WebHook 功能。而GitHub Action 是 GitHub 于 2018 年 10 月推出的一个 CI\CD 服务。. 之前一直都是 Beta 版本，正式版于 2019 年 11 月正式推出。可以看到gitlab在这方面的技术积累更早, 服务工具比较成熟和稳定,我个人初步使用认为gitlab的CI功能体验好一点.

 

标签：集成,CI,github,代码,gitlab,单元测试,之法,IC,ID
来源： https://www.cnblogs.com/yzmcoding/p/14552028.html