【已更换图床】week2-个人阅读作业-阅读和调研

❗❗❗ 注意：
第三问使用GitHub图床，可能会出现图片加载失败情况
现已全部替换为CSDN图床
GitHub仓库链接需要科学上网

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程
这个作业的要求在哪里	个人阅读作业-阅读和调研
我在这个课程的目标是	提高开发项目的编程水平，锻炼合作能力
这个作业在哪个具体方面帮助我实现目标	编程能力，团队协作，集成开发

阅读《构建之法》提问

阅读提问要求：

快速看完整部教材，列出你仍然不懂的5到10个问题。

• 在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。
• 列出一些事例或资料，支持你的提问 。
• 说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾?

Question 1

章节：

第一章 概论

1.1 软件 = 程序 + 软件工程

原文：

上面这些和软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关的内容，是软件工程的核心部分。广义上的软件工程也包括用户体验、用户界面设计（User Interface Design）等。

所以，一个推论是：软件 = 程序 + 软件工程。一个扩展的推论是：软件企业 = 软件 + 商业模式。

当然，软件企业还需要各方面的支持工作，例如人员的招聘、绩效评估、升迁、淘汰等人力资源方面的工作。弄清楚这些概念，是进行所有与程序、软件、企业等相关的讨论的基础。回到本节开头的疑惑，答案就很清楚了，程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。

疑问：（经验印象）商业模式真的有这么重要吗？

企业生长都遵循了这样的逻辑：发现需求——找到解决方案——形成产品和服务——建立商业模式——规模复制。（from 胡斌Steven）

因为需求是企业的起点，在我以往的认知中，总结一个刚需提出创新性的解决方案才是一个企业立足之本、做大做强的凭借资本，而通过本书我了解到商业模式和软件工程的重要性。

Question 2

章节：

第一章 概论

1.3 练习与讨论

原文：

Dijkstra曾经提到： “Software engineering， of course，presents itself as another worthy cause，but that is eye-wash: if you carefully read its literature and analyse what its devotees actually do，you will discover that software engineering has accepted as its charter ‘How to program if you can-not.” 软件工程是不是教那些不怎么会写程序的人开发软件？你怎么看？

我认为软件工程不是用于教不写程序的人开发软件的。

软件工程的原则围绕着在软件开发过程中的工程设计、工程支持以及工程管理，开发过程只是软件工程的一部分。

用自己的话说，我认为软件工程不是教不会编程的人编程，而是教会编程的人怎样“规范”地编程、“正确”地完成一个项目。

Question 3

有人认为，“中文编程”，是解决中国程序员编程效率的一个秘密武器，请问它是一个“银弹”么？

我不这么认为。

所谓“英文编程”也并不是直接使用自然语言英文编程，常用的编程语言包括C、Java、Python都与日常英语语法有较大区别，甚至很多单词拼写都是创造 。而中文语法非常复杂，每个字需要哦那个拼音打出来，为了编译器设计也需要大幅修改，大动干戈却没什么改进，得不偿失。

这里引用作者的例子：

我上班后，发现以前同事写的程序真是垃圾，根本看不懂，无法维护。我要推翻重写！后来一个老员工笑嘻嘻地告诉我，我们现在看到的程序，就是去年的新员工愤怒地推翻重写之后的结果，大家反映还没有以前的版本好用呢。

Question 4

章节：

第二章 个人技术和流程

2.2 效能分析工具

原文：

另一方面，代码注入就是将检测的代码加入到每一个函数中，这样程序的一举一动都被记录在案，程序的各个效能数据都可以被精准地测量。这一方法的缺点是程序的运行时间会大大加长，还会产生很大的数据文件，也相应增加了数据分析的时间。同时，注入的代码也影响了程序真实的运行情况（这有点像量子物理学中的“测试的光线干扰了被测物体本身”的现象）。

这个问题有点题外话，笔者指的量子物理学现象是薛定谔定律和测不准原理吗？

如果是的话，量子力学中的观察指的是“观测会使得量子从不确定的叠加态坍塌至确定态”，而不是从一种状态变成另一种状态、或者增大减小原本的某项数值，我觉得意思还是不太一样的（顶锅盖逃

Question 5

章节：

第四章 两人合作

4.2 代码风格规范

原文：

于是，我们最后选择了下面的格式，每个“{”和“}”都独占一行，即格式D：

if (condition) 
{     
	DoSomething(); 
} 
else 
{     
	DoSomethingElse(); 
} 

不要把多个变量定义在一行上。

Foo foo1, foo2; 

还是引用作者的例子，研究表明键盘换一种布局能得到更高的打字效率，但是人们已经习惯了原来的键盘布局。

况且“风格”的定义因人而异，我认为除了一些基本的例如缩进、空格这样公认的代码风格要求，其他可以按照自己的习惯和喜好来编写。

我个人而言，if后面的{ 就更倾向于空格不换行，还有声明无需初始化的局部变量时也不换行。

如果写成：

list *i;
list *j;
list *k;

我反而会觉得看起来很不适应。

调研源代码版本管理软件

GitHub

查阅到的一些主要优点：

错误跟踪，此功能属于协作功能，可以在项目中检测软件错误记录，提高代码质量。

快速搜索，存储库提供方便的项目结构，允许有效的搜索和排序。

社区，用户数量超过2000万，是共享经验和技能的重要来源。

共享，项目源代码不仅可以使用Git进行复制，还可以作为归档下载。

协作开发，GitHub为团队管理提供了高效的功能。

团队协作流程：

• 前期准备
• 创建开发分支
• Fork项目到个人的仓库
• Clone项目到本地
• 和团队项目保持同步
• push修改到自己的项目上
• 请求合并到团队项目上
• 团队项目负责人审核及同意合并请求

GitLab

我通常小组作业主要就是使用GitHub或者GitLab，功能上个人体验差不多。但是GitLab个人版有团队人数、仓库成员人数、仓库文件大小等等限制，觉得有些不方便。

以及冯如杯跟进实验室项目的时候，体验了一下GitLab企业版的团队协作功能。团队能够设置不同层级title以便逐级通知，上级发布的任务可以继续细化分配到个人，并且通过“任务ToDoList+在线文档+多个代码仓库“集成，在比较大型的团队协作方面（例如一个二十人的项目，三四个人一个小方向并有小组长，项目总负责人对接三个负责人，负责人和小组长对接）还是比较有优势的。

Bitbucket

BitBucket最适合小型开发团队，对于小团队免费，这意味着最多5名成员的团队将获得无限数量的免费存储库。

Bitbucket是基于Mercurial实现，直到2011年才开始支持Git，权衡点在于，Mercurial更注重易用性，而Git更注重操控性。BitBucket集成Jira工具，在整个开发阶段都和Jira做了整合，通过集成的错误跟踪组件，JIRA自动更新有关检测到的问题的信息。

项目管理：根据拉取请求状态转换 Jira 事务，与指定审批人一起创建合并清单，并检查通过审查的构建内容。将各种功能融入到结构化系统当中，从而让整个软件公司（从工程到设计）始终处于整体运转状态。在 Jira 事务或 Trello 卡片上访问分支、构建状态、提交和状态。

BitBucket不开源，私人项目或者敏感项目（例如涉及到一些商业合作）更适合一些。

但是据说BitBucket系统不稳定，因此我并没有使用过。

调研持续集成/部署工具

GitHub Action

代码仓库地址：

RuBing-Yang/SignalSystemHW

是信号与系统课程的二人结组作业，把一张图片先频域变换再哈夫曼编码，压缩成二进制文件，再解压回图片。

运行方式：

直接运行/SignalSystemHW/main.py

动态链接库：/SignalSystemHW/cython/rect.cp39-win_amd64.pyd

输入文件：/SignalSystemHW/images/image.bmp

python的编码压缩后文件：/SignalSystemHW/encode.txt

c++的哈夫曼编码压缩后文件：/SignalSystemHW/huffman.bin

哈夫曼节点保存：/SignalSystemHW/num2freq.bin

哈夫曼树保存：/SignalSystemHW/tree.bin

c++的哈夫曼解码文件：/SignalSystemHW/dehuffman.txt

输出图片：/SignalSystemHW/images/out.bmp

一句话运行：

在pycharm打开PyHuffman文件夹，确保rect.cp39-win_amd64.pyd文件在文件夹中，运行main.py文件

添加了GitHub Action作业后如下：

其中HashMap-Encode-Job作业具体内容如下：

图像压缩编码、解码输出结果：

GitLab Runner

在vscode连接docker，安装GitLab WorkFlow


配置yml文件，推送到GitLab上


创建Docker Image作为GitLab Runner，并连接运行激活

使用感受

GitHub Action对于简单项目来说很方便，但是需要复杂的测试时没有管道编排（ Pipeline Orchestration）会导致运行时间更长，并且不利于查看。在团队集成上，位于同一团队内的存储库，无法跨其他私有存储库访问操作。无法重新运行工作流中的单个作业、删除单个工作流运行，管理时更混乱。

GitLab CI/CD我一开始偷懒没搭建好Docker，导致后面环境配置花了更久时间。GitLab和GitHub一样都是通过yml文件进行配置，语法看起来大致相似，但是GitLab的语法相对而言更细一些。在团队管理中能设置用户权限和成员锁定，通过签名限制提交，并防止敏感文件被意外推送到生产环境。在产品开发上，创建和记录计划和流程，维护端到端可追溯性。

参考：GitLab CI/CD vs GitHub Action

比较看下来，个人而言我觉得GitHub Action风格简洁适合个人作业和小项目，GitLab CI/CD更适合团队合作集成软件开发。