2022北航敏捷软件工程第一次博客作业

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程
这个作业的要求在哪里	个人阅读作业-阅读和调研
我在这个课程的目标是	了解软件工程的方法论、在实践中学习软件工程的各个层次、获得以敏捷流程进行软件开发和产品构建的相关经验、尝试以软件工程的方式来实现脑中想法。
这个作业在哪个具体方面帮助我实现目标	了解软件工程的方法论：阅读书籍《构建之法》，初步了解软件工程涉及到的具体问题和业已形成的方法论，提出问题以明晰接下来的学习目标；搜寻资料，调研源代码管理及 CI/CD 工具。在实践中学习软件工程的各个层次：使用 CI/CD 工具，通过实际体验分析其对于软件工程的意义和价值。

Author 19373540 熊安杰

Date 2022.03.09

阅读提问

“过早优化是一切烦恼的根源”：那么，如何界定早晚？

既然软件是“软”的，那它就有很大的可塑性，可以不断改进。

Chapter. 3 Pg. 53

在既往的实际项目构建经验中，我既有过纠结于为小项目提供足够健壮根基——选择适用于大型软件的复杂架构，以致开发进度严重滞后损害软件开发的实践，也有过受益于未雨绸缪的早期架构设计及亡羊补牢的重构大大减轻扩增需求压力的经验。 软件天然便是“软”的吗？ 我认为，这个命题矛盾地指涉其自身。软件的可塑性在于对其构建方式、架构的设计与考量，而这一考量本身就落入了“优化”的范畴。

为了得到高质量的软件产品，我们是应该把精力更多地集中在提升其中每一个人员、过程、产出物的能力和质量上，还是该把更多精力放在整体流程和架构上？

笔者先给这个问题一个“和稀泥”式的回答：这两者都重要。前者重术，后者重道；前者更多与编码能力相关，后者更多与软件架构相关；前者主要由开发者个体水平决定，后者主要由技术决策者水平决定。

《凤凰架构：构建可靠的大型分布式系统》：引言 - 什么是凤凰架构。

这样的决定往往落入一种挂一漏万的思考模式，即“术”和“道”相辅相成却又相互龃龉。在软件架构不断演进的当下，即便组成软件的构件不断地向模块化的方向前进，使得系统整体更具与具体组件无关的鲁棒性，但也带来了越来越多似乎永远也看不到头的“性能-设计难度-稳健性”之间的 trading。本书浅涉这一议题，却没有涉及进一步的分享和解说。我相信，它的最优解在接下来的实践中会慢慢浮出水面。

需求分析：“最好”还是“最合适”？

软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出真实的需求。

Chapter. 8 Pg. 158

在本书的叙述之中，软件团队似乎有时与用户处于同等的地位，是产品构建的合作者，共同为创造“最好”的产品而努力；另一些叙述中，又处在“乙方”的地位，力图界定出“最合适”用户的需求范围。现实是，软件开发者往往也是目标用户的子集，陷入当局者迷的境地；另一方面，用户的需求亦在不断地变化，“合适”的标准也随之变更，而“好”更无从确定。 “真实”的需求，是“好”的需求吗，是“合适”的需求吗？ 这样的迷思仍困扰着我——如何衡量软件需求的必要性并作出合理的取舍，是重要又十分基本的问题。

测试与质量管理：软件开发的合与分

代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

Chapter. 2 Pg. 25

…软件团队中应该有独立的测试角色。

Chapter.14 Pg. 316

本书中有大量关于测试、质量控制的内容，正如文中的解读和分析，软件质量的保证既取决于个人、亦取决于连接各模块而成的总体。软件开发中涉及“合”与“分”的问题有很多，而尤以质量管理为重。在这个环节中，每个人的技术水平都参与到“木桶”的构建中，而与“短板效应”中的“木桶”不一样的是，团队的、组织化的软件工程项目要最大化集体的力量，保证“木桶”倾斜在一个最大化每一块“木板”效益的角度。 如何去平衡这一“合”与“分”？ 现在的我还不能给出一个很好的答案来。

敏捷流程：构建“玩具”的方法？

…敏捷有它最适用的范围：

产品可靠性要求：不高，容忍经常出错…

Chapter.6 Pg. 128

在本书的语境里，敏捷一开始显得像是一种“最佳做法”的理想组合，是多种“最佳实践”的大拼盘。随后，又将敏捷流程定性为构造“玩具”的方法。 敏捷流程不能应用于更高要求、更大规模的项目吗？ 我（作为技术论者）认为，所谓“敏捷”不适于高标准要求项目构建的原因，并不在于它的价值取向从一开始便是“不稳定的”，而在于现有工具无法进一步地提高高质量软件的生产力。我相信，架构的合理设计能够弥补投入的不足与团队焦点的快速转换让敏捷流程同样具有足以称稳健的鲁棒性，只是对于“敏捷”的错误认识往往让团队忽视这些需求。

“惊喜功能”：先有鸡还是先有蛋？

还有一种是让用户惊喜的功能，这些功能一旦出现，就能给用户满意度带来正面的帮助。

Chapter.8 Pg. 175

“惊喜功能”一度让我雀跃于找到了需求分析的关键——既然屡出奇兵的产品设计模式如此诱人，那么最好的做法是不是在核心功能实现的基础上不断堆砌新想法即可？

但这份热情很快退散，“能给用户满意度带来正面的帮助”是“用户决心使用“之后才能带来的反馈，这样的考量陷入“先有鸡还是先有蛋”的困境， 如何去权衡一个需求对于用户的心理冲击力和吸引力，如何保证它的尝试成本小到用户绝对会迈出一步使用它？ 这是仍在困扰我的问题。

调研源代码版本管理软件

基于 Git 的项目管理工具包括 GitHub、GitLab、Bitbucket、Gitee 等，以下分项总结其特点。

有意思的是，前三者均肇始于二十一世纪第一个十年的末尾——可以看到，分布式、社会化的开发浪潮以及开源文化的风行，极大地扩大了软件开发领域的生产力。在其背后，是工具的进化带来流程的优化，进而开创新的软件开发时代的过程。

GitHub

GitHub 基于 Git，利用其分布式版本管理特性，作为属于开发者的远端代码仓库存在。在 Git 所提供的强大版本管理能力之外，GitHub 提供了面向开发者、面向开源文化下社会化共同开发场景的多种社群功能，具体而言包括如下这些方面：

反馈及互动：对代码项目进行关注、点赞、提出问题或建议（Issue）等，对开发者（用户）进行关注、浏览时间线等；
合作及管理：通过复刻（Fork）、拉取请求（Pull Request）进行自由的增量开发，同时为代码仓库提供问题追踪、任务列表、贡献管理、Wiki 等社会化开发功能，集成 CI/CD 服务以便于测试及发布；
统计及分享：为代码仓库提供翔实的数据分析以利开发流程追踪和管理，提供 GitHub Pages 网页托管服务以便信息共享；
开源文化：对接开源项目的具体需要，提供开源许可证、开发者行为准则模版等便于开发者使用，从代码仓库平台的角度促进开源软件的发展。

GitLab

GitLab 以 Git 作为版本管理后端，同时扩充集成其他软件开发功能，如在线编辑、Wiki 管理、Issue 跟踪、CI/CD 功能等，以自动化软件开发的多个步骤。在团队协作及项目管理方面，具备许多上述 GitHub 的类似功能，不再赘述。

与 GitHub 的不同之处在于，GitLab 本身作为开源软件引入了来自全球开发者的贡献，并可自由利用以获得私有的部署版本；同时，提供企业版本适于市场的高级需求以盈利。可以说，GitLab 本身也是开源文化的好案例。

Bitbucket

Bitbucket 同样是基于 Web 的版本库托管服务，提供了与 GitHub 相似的大多数功能，并额外支持 Mercurial 版本控制系统。

与前两项服务不同，BitBucket 聚焦于为专有软件的开发者提供服务，集中于私有仓库、私有项目的管理，并从此出发丰富平台功能。

Gitee

Gitee 是由开源中国提供的类似服务，具备更好的本地化及国内生态基础，同时集成国内的多项服务，例如微信、钉钉等。借由 Gitee 的实践可以看到，代码托管平台在社交化、本地化方面的巨大需求和既有探索。

调研持续集成/部署工具

本次调研使用了 GitHub Actions 及 GitLab CI 两种持续集成/部署工具。

GitHub Actions

这一部分的实验选择了过往使用 html+css+js 编写的基于 Markdown 的日记管理平台 Markdown_Diary。

作为简单的 web-app，进行修正、增量开发之后，利用 CI/CD 工具可以实现即时的部署上线。

实验结果如下：

如下进行 Action 配置脚本的编写：

name: Deploy With GitHub Actions
on:push:branches:- master
jobs:build-and-deploy:runs-on: ubuntu-lateststeps:- name: Checkoutuses: actions/checkout@master- name: Deployuses: peaceiris/actions-gh-pages@v3.7.3with:github_token: ${{ secrets.GITHUB_TOKEN }}publish_dir: ./public

每次向主分支进行 push 后，会自动检出最新的代码；接下来，调用开源的 GitHub Pages 部署脚本，该脚本在虚拟环境下进行环境配置等工作并更新部署的项目代码，从而实现最新代码版本的上线运行。

GitLab CI

本部分实验采用了继往基于 Nuxt.js 开发的粘贴板平台前端，将代码存放在了 OO 课程提供的 GitLab 平台。

实验结果如下：

首先，在自己的机器上配置了 GitLab Runner，采用模式：Docker；在本机上完成了 runner 的注册，与 GitLab 平台进行连接。

编写了如下 pipeline 脚本以进行自动化的安装和部署：

stages:- buildbuild:stage: buildtags:- bogononly:- mainscript:- node -v- npm config set registry https://registry.npm.taobao.org- npm install- npm run build

脚本中指定了运行分支、在哪些 runner 上运行、需要运行的命令。

在运行 pipeline 时，可以看到日志中显示 runner 首先配置 Docker ，自动拉取并设置 node:latest 镜像，继而按脚本依次完成包安装和项目构建。

体会和感想

CI/CD 工具的出现，极大地便利了测试、部署、集成流程。软件开发中冗杂的构建和测试工作，都可以借助它来便捷、自动化地完成。实验所涉的两种 CI/CD 服务配置的思路近似，原理也相同。部署等工作被从开发流程中剥离出来，解放了开发者的生产力。

成体系、流程化的 CI/CD 服务的出现，在工程化的软件开发中格外凸显出它的必要性。从独自开发、到团队合作的“软件工程”，CI/CD 与项目管理工具一起，为软件开发的工作流增加了一致性保证和规范化流程，减少了开发人员间的冲突和龃龉。

实验中，选择了两种模式相异的 CI/CD 工具，可以说他们分别代表目前软件开发及项目管理工具中的两类思路：

GitHub Action 提供了现成的虚拟机资源，能够快速、简便地利用社区中广博的开源配置脚本，完成各类集成、部署、测试任务。适应前文所述的平台开发初衷：以形成社区的方式，最大限度地发挥社会化、去中心化的软件开发新形态的优势。

GitLab CI 则将 CI/CD 功能高度模块化和客制化，提供了统一、易用的配置端口和方案，剩下的流程交给用户设计和实现。作为开放源代码、可自部署的平台，这样高自由度的设计，便利了其目标用户的使用，恰如其分地满足了企业用户、私有项目的需求。

从这两个迥然相异、但殊途同归的项目管理平台的设计中，我们也能看到需求如何驱动了软件项目的发展。项目的开发、功能的设计围绕目标用户、目标需求进行取舍。在成功的软件项目中，没有绝对的优点或缺点，只有适合用户的需求取向和大刀阔斧砍除的冗余需求。