个人阅读作业-阅读和调研

阅读提问

1.在“软件工程概述”章节中对于“软件的生命周期”的描述

一群人要从需求分析 (Requirement Analysis) 开始，忙碌各种事情, 例如设计（软件架构），实现（写数据结构和算法），测试，到最后发布软件, 软件在运行过程中还会出这样那样的问题, 也许我们要时不时给软件打一个补丁, 这叫软件的维护（Software Maintenance）。这一系列过程就是软件的生命周期 (Software Life Cycle, SLC)。

如果软件中途被停用了，过了一段时间重新开始使用这样对于软件是开始一个新的生命周期还是原有生命周期的延续呢？比如有一款游戏停服了，过了一年被另一个公司接手重开了，那么这样通常怎么进行交接工作呢？本学期是我第一次接触软件工程，在正常的软件生命周期中，我认为一个项目中的每个人分工应该是明确的，但是本课程是学生团队去完成一个项目，对于很多人来说是第一次正式合作一个较大的，我的想法是每个人都应该在各个岗位都有所接触，这样可以较为全面的了解一个软件开发活动的细节。

2.在“送一个汉堡包”的章节中提出了对同伴的反馈应该怎样表达

为什么我要啰啰嗦嗦讲这么多两人合作的反馈问题? 因为我认为如果你连一对一的合作都做不好, 不能运用影响力去影响同伴， 让合作双方都能从合作中受益, 提高水平，那你就别扯什么团队合作这些事了。

我的想法是一个团队交流方面的问题不止于此，如果是没有过大量合作经验的人，是很容易陷入“说服”的误区的，因为不愿意承认自己的错误对大部分人来讲是天性（这里并不是贬义，而是一种生来自带的倾向），尤其是两个实力相当的人，并不会那么容易的对对方的反馈产生认可，反而会更急于证明自己是正确的，另外提供反馈的人确实也不一定就是正确的。但是如果实力差距较为明显，新手能够接受高手的指点，但这时容易产生各种摩擦，高手可能会对自己所带的新人缺乏能力而不满，新人可能觉得束手无策，无法得到收获而烦闷。总而言之，我认为既然这里提到是用影响力去影响同伴就不应该只提反馈这一个方面。

3.在“工程师的能力评估和发展”这一章节中

软件设计工程师们在做代码复审的时候，是看“重复字”的多少, 还是程序的艺术性?

我理解的“重复字”是代码复用和引用他人代码，程序的“艺术性”是指一些精妙的方法和思路。这个问题我认为提的有些不全面，不知是何用意？因为我认为一个优秀的程序既不会重复造轮子，也会有巧思，工程性和艺术性是兼具的。同时上文中以诗词作为举例我认为也欠妥，这里的重复字所代表的意义是不一样的，不能作为单独字，而应该和其前一个或者后一个字连起来看作为意象，这个意象用在此处是顶好的，硬要用程序来比喻的话就像是用恰当的遍历方式来遍历，虽然用了很多种遍历，但是并不能因此来批评说是程序的缺陷。程序的复审应当是综合的、全方位的，需要有丰富的经验的人才能看懂一个好程序的巧妙之处，不是“重复字”或者艺术性这样简简单单就能概括的。

4..在“送一个汉堡包”的章节中最后一段

有一个说法, 创业家在创业初期必须要说服三个F: Family, Friend, and a Fool. 如果Family 和 Friend 都没人支持你的想法, 第三个F 估计也帮不了带大的忙。

我认为在前两个中Family应该是次要的，Friend是主要的，因为大部分的工作者之间不是家庭关系，而是朋友关系，更多时候也是朋友才会和你一起投入项目中。作者提到这一部分可能是为了说明合作的两人应该有良好的沟通基础，但是第三个F一般指天使投资，同时也是象征着未来的起步，所以在我个人的眼里重要性有些时候略胜于前者。

5.在“技能的反面”这一章节作者所提到的与技能相对的是解决问题，举的例子是这样的

一个IT 专业的大学生来面试, 简历上写“技能: 精通 Visual Studio C# 编程”。于是面试官请他实际用VS IDE 写一段程序 (冒泡排序)。一个“不精通”的面试者的编程过程实际上就是一个“解决问题”的过程。

· 嗯, 怎么开始一个C# 的命令行程序呢?

· 定义数组是怎么弄的? 是“int [] arr”还是“int arr[]”, 还是 ArrayList，还是 Array <T>。哦, 我平时都是上网查的. 哦, 我不知道还有 MSDN 网站。

· 嗯, 为什么编译没过呢, 哦, 这里少一个分号。

· 嗯, 怎么设断点? 怎么定义命令行参数? 额, 我要查一查…

作者说这些是低层次的问题，这点没错，但是这所谓的反面更像是实现细节，技能是一种整体构思。在我看来，这不应该叫做反面，而是补集的关系，整体构思需要被细节所填充。叫做解决问题实际是过于宽泛了，同时作者在下面所说的：

从科研，或者理论的高度上说, 所有的“技能”都能总结成简单的”已经知道怎么做了”

也是这个意思，技能就是理论框架。

6.同一篇的这一句话

那怎么提高技能呢? 答案很简单, 通过不断的练习, 把那些低层次的问题都解决了, 变成不用经过大脑的自动操作, 然后才有时间和脑力来解决较高层次的问题。

技能是作者认为的高层次，但是不断练习解决的是低层次问题，这似乎和提高技能没什么关系，不知是为何意？

调研源代码版本管理软件

使用GitHub Actions自动部署

仓库地址：https://github.com/tsuJui/vue_test

.yml文件内容：

name: GitHub Actions Vue Demo
on:
  push:
    branches:
      - main
jobs:
  main:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
      - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
      - name: Checkout
        uses: actions/checkout@v2
        with:
          persist-credentials: false

      - name: Install and Build
        run: |
          npm install
          npm run build
      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@releases/v3
        with:
          ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
          BRANCH: gh-pages
          FOLDER: dist

      - name: Run On Push
        run: |
          echo "Run On Push"

GitHub Actions使用非常方便只需配置yml即可自动部署。 

调研源代码版本管理软件

CI/CD工具的特点和特性

CI/CD是一种在开发阶段引用自动化来频繁向客户交付应用的方法，其核心就是将持续集成和持续交付和持续部署作用于应用的整个生命周期。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。

CI特点：让开发人员能够频繁地将代码集成到主干，同时还会运用自动化测试保证每次的更改不会破坏应用的正常运行。运用CI能够快速修复在自动化测试中的错误。

CD特点：持续部署是CI/CD工具的最后阶段，保证开发人员的更改能够快速生效。便于持续接收和整合用户反馈。

CI/CD工具对比

Jenkins有大量插件库，容易调试运行、搭建节点、部署代码。能够支持不同的语言并且非常直观。但是插件集成复杂，对于比较小的项目开销比较大，因为你需要自己搭建。缺少对整个 pipeline 跟踪的分析、

GitLab CI/CD有着更好的 Docker 集成，运行程序扩展或收缩比较简单，合并请求集成。容易添加作业、处理冲突问题。在安全和隐私政策方面也较好。缺点是需要为每个作业定义构建并上传 / 下载，在实际合并发生之前测试合并状态是不可能的，同时还不支持细分阶段。

GitHub Actions上的首要优势是设置简便性。GitHub Actions在云端运行，你也可以选择在本地运行，这就是所谓的运行器。可以通过GitHub Marketplace相互分享。可以重用其他开发者编写的Action。实现了异步CI/CD。缺点是需要自己写缓存机制。

Travis能够开箱即用构建矩阵快速启动，拥有轻量级YAML配置和开源项目的免费计划，并且无需专用服务器。缺点是价格更高，没有免费的企业计划，一些自己所需的第三方的东西需要定制。