北航 2022 软工第一次阅读作业

项目	内容
这个作业属于哪个课程	北航 2022 春季敏捷软件工程
这个作业的要求在哪里	作业说明链接
我在这个课程的目标是	学习现代软件工程开发的模式，锻炼团队协作开发的能力
这个作业在哪个具体方面帮助我实现目标	通过阅读《构建之法》了解现代软件工程概念 调研 Git 托管平台以及 CI/CD 的使用

《构建之法 - 现代软件工程》读后提问

阅读后发现这实在是一本很有意思的书，让我找回来以前看科普书的乐趣，同时其中实打实的内容也引发了我很多对于软件工程开发的思考。

“技能”比“解决问题”更重要吗？

技能的反面是 “Problem Solving”

作者在文中提出说“通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。”对于这一点我还是非常认同，但是对于作者在文中推崇先解决“低层次问题”，我仍然有一点相反的意见：在我看来，在一些情况下这种“解决低层次的问题”未必比学习“解决问题的方式”更重要，在技术发展日新月异的今天尤为如此。

举一个简单的例子：例如学习网页开发，在十五年前某个人学习网页开发时，可能会花很大精力在 Flash 上，因为 Flash 在当时能做出令人惊艳的动画效果，并且在许多网站中都大量运用了 Flash。但是在 2022 年的今天，我们却很难再见到 Flash 技术的应用了，因为这项技术已经被扫入历史的垃圾堆了（当然，Flash 在当时本身是一项不错的技术）。同理类似有微软开发的 Fox Pro，在今天也被遗弃了。那么学习熟练解决这种“低层次的”的技能真的还要那么大的价值吗？再如从前一个人能熟练地背诵库中的各种 API，但是在当下这个 IDE 技术迅速发展的今天真的有用吗？

对此，我认为在目前这个技术迭代飞速的时代，尤其是在互联网这个领域，“技能”或许本身的重要性没有以前来的大了，反而“解决问题”本身更能适应当前时代的发展。

对于技术而言，“精通”比“全栈”更重要吗？

作者在文中用“单人乐队”与“乐手”举例，想说明我们应当精通某一样技术，而不是做一个泛泛的“全栈工程师”。然而实际上仅仅精通某一项单独的技能已经不足以满足现实的需求了。尽管现代软件工程利用“封装”等思想大大简化了开发的难度，但是在开发的过程中，人们仍然会不时地遇到一些只了解单个领域就无法解决的问题，此时往往需要一名了解多个领域的“全栈工程师”的帮助。

事实上，现在越来越多的领域正在成为交叉的领域，这一点在人工智能技术飞速发展的今天显得尤为明显。除了在研究人工智能理论的一小部分人外，大多数人聚焦在如何使用人工智能技术为现有的领域提供更好的支持，这使得人工智能成为了一个非常广阔的一个交叉领域，许多大学中也开办了许多面向这种交叉学科的专业，例如“智能制造”等。一名工程师往往需要将某样技术应用到现实生活中来，这样的技术可能是某一样非精通的“技能”，也可能是某一样精通的“专业”。优秀的工程师需要同时具备技术的深度与技术的广度。

结对编程是否对结对者的水平差异提出了更高要求？

只有水平上的差距，没有级别上的差异。尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。

在书中作者介绍了许多结对编程的好处，例如减少 bug、提高工作效率、提高解决问题的能力等。同时作者推荐结对编程时不需要过于注意两个人水平上的差距，认为双方具有同等的决策权力。

但是在各种编程概念（例如 Go 语言中的协程、Rust 语言中的 Linear Type）和编程范式（例如函数式编程）的今天，两个人水平上的差距是否愈发是结对编程中不可忽视的重要影响因素之一呢？尤其是在函数式编程中（例如 Haskell 或者 Scala 等语言），往往会用比较抽象的组合子对问题进行建模，而这一点是非常依赖于编程者的函数式水平的。如果两个人水平上差距过大，很有可能会经常出现一个人不断询问另一个人某段代码的含义。诚然，在某种意义上这可以帮助开发者尽早发现自己代码中的 bug，但是我认为这对于开发进度的拖慢是不可忍受的。

软件开发中的重大决策应该由“猪”来定夺吗？

在遵循敏捷原则的团队里, 成员们并不忌讳谈论不同的投入和负责程度 - 因为这就是现实。 但是他们一般有一个原则:

重大决定由 “猪” 来定夺。

作者在这篇文章中将项目人员按照投入程度分为了猪、鸡、鹦鹉三种，并提出“应该让研发和市场第一线全心投入的‘猪’来定夺重大决策”。但是在实际的生产当中，猪未必适合这个位置。

例如在某个开发团队中，“开发人员”是团队中“猪”的角色，他们为团队编写关键代码，并且全力投入。那么在这个团队中应当由“猪”来引导产品发展方向吗？实际上，在一个团队的分工中，其他角色也占用很重要的位置，例如市场调研的人员往往可以比开发人员先一步了解市场变化的动向，因此他们也往往能够更清楚地把握市场风向。尽管他们在投入上可能并不如开发人员，但是由他们进行决策可能更加科学。

另一方面，需求调查和团队管理一样都是十分专业的任务，需要交给专业的人来完成。尽管某个开发人员非常投入，但是他未必能够胜任这样的角色；反之，尽管某个成员在团队中承担着“鸡”的角色，但是他做专业的事也未必不如外行的“猪”。因此我认为这里仅仅按照这个方面划分团队人员有点粗暴了。

软件开发时应当由 PM 负责分解需求吗？

一个团队项目要在一段时间内完成诸多任务，满足用户的需求，实现团队的目标，同时还希望项目能维持良好的技术架构，以便持续开发，千头万绪，从哪里人手? 一队人马站在项目的“需求”前，就像愚公和家人站在王屋山前一样，他们可能都在想：这座山到底要花多少时间才能搬走呢？这时候我们需要一个角色站出来领导大家，把看似巨大无从下手的项目逐步分解为可以操作的工作。PM 是责无旁贷的领导者。

在谈到分解需求时，作者提出 PM 应当是“责无旁贷的领导者”。然而，在实际开发中，开发者可能会遇到各种技术层面上的困难，而这一点 PM 有可能是无法预料到的。因此如果简单地让 PM 成为项目需求的分解者，那么在项目管理和项目时间安排上极有可能出现估计错误的情况。

因此，我认为除非 PM 是一位有着丰富经验的开发人员，而且对于开发的项目有着足够的了解，那么这样的 PM 有义务领导团队进行任务规划。否则在分解任务时应该让主力的开发人员与 PM 进行协商；否则，PM 的错误估计可能会导致项目的开发工作无法继续进行。

设计用户体验时，如何把握用户的需求而不造成体验的割裂？

我们的PM/Dev/Test 在设计/实现/测试这个功能的时候想过目标用户的英文水平是什么样么? 他们需要哪个程度的英文解释? 如果他们连 "a" 都不懂, 他们能来到你这个网页搜索含有英文的结果么?!

作者在这里描述了必应搜索的“实时显示英语解释”，并指出在实际应用时，英文解释无需显示“a”“on”等简单词汇。但是应该如何掌控这个设计的尺度呢？

不同的人的英文水平可能是大不相同的，例如一个上网查找英文资料的小学生与一个托福 110 的大学生，二人对于英文单词的学习进度也是不同的，如果软件自作主张地取消一些词的显示，可能会造成体验上的割裂感。那么在实际设计时，考虑到这一点该如何准确把握用户的需求呢？

源代码版本管理软件调研

GitLab 和 GitHub 是目前世界上最流行的两个基于 Git 的项目管理平台，因此我挑选了这两个平台作为调研的对象。

相同点

首先，二者都基于版本控制软件 Git，都可以托管 Git 仓库的代码，其代码管理上的功能也大致相同：包括 clone，fork，pull request 等。二者都能部署 CI/CD，都有项目管理的功能，支持团队协作开发。

除此之外，GitHub 和 GitLab 都是基于 Ruby on Rails 开发的，这一点非常有意思。这里我看了一篇 Gitlab 团队写的一篇博客。在这篇博客中，GitLab 团队提到了以下几点：

• Ruby 的生态非常丰富，可以大大减少开发的难度
• Rails 虽然速度没有其他框架快，但是却非常适合开发（Ruby was optimized for the developer）
• Rails 框架中的包管理得非常有条理，不会混乱（反面可能是 NPM）

不同点

首先，GitHub 是最早进行 Git 托管服务的平台之一。相比于其他代码托管平台，GitHub 上面已经形成了一个非常庞大的社区。除了传统的代码托管服务外，GitHub 还提供了依赖检测、片段分享等功能。现在的 GitHub 除了被当作代码托管平台外，也渐渐成为了一个程序员的社交平台，发展成了类似于“Facebook”的存在。自从 2018 年微软收购 GitHub 后，GitHub 被有些人诟病“商业化气息过重”，但是借着微软 GitHub 也开放了大量原先的会员功能（例如无限量的私有仓库等）。目前的开源社区中，暂时还没有能够完全取代 GitHub 的托管平台和社交平台。

GitLab 是一个开源的项目管理平台，它的代码管理功能和 GitHub 一样，但是它允许用户在自己的服务器上部署 GitLab 平台，这一优势使得许多平台和企业选择了 GitLab 作为内部托管平台。同时，GitLab 也是一个非常好用的 DevOps 平台，官方开放了大量 API 供开发者和维护人员使用，便于第三方在上面进行二次开发。（顺便，北航的面向对象课程也使用了自建 GitLab 作为代码托管平台，其中诸如“Impersonate”之类的功能真的非常好用）

持续集成/部署工具调研

GitLab CI 使用

在本节中，我尝试使用 GitLab CI 来编译我的编译器。仓库地址为 http://gitlab.oo.buaa.edu.cn/roife-personal/racoon 。

GitHub Action 使用

在本节中，我尝试使用 GitHub Action 来编译我的简历模板。仓库地址为 https://github.com/roife/resume 。

对 CI/CD 工具的看法

我使用了 GitLab CI 和 GitHub Action 两款 CI 工具，下面对二者进行分析：

• GitLab CI
  • 特点：GitLab CI 在使用时需要指定一个用来运行的 runner，使用时需要在自己的设备上部署一个 runner 来跑相应的任务。好处是这个过程是高度可控的，使用者可以根据自己的需要来选择 runner，而且可以自定义 runner 的配置（如使用 docker 等）。但是如果不是自己部署的 GitLab 服务器，则可能需要购买官方的 runner。
• GitHub Action
  • 特点：GitHub Action 背靠 GitHub 广大的资源社区以及微软的资源，因此在使用体验上要好于 GitHub Action，包括各种环境等。同时，GitHub Action 在限制内可以免费试用，因此对于学生党或者购买有一定困难的国人来说非常方便。

	GitHub Action	GitLab CI
优势	可以直接使用社区资源，方便快捷	自由度更高，有丰富的 API 进行控制
劣势	可定制性没有 GitLab CI 高	需要自己进行一定配置
适应的场合	社区开源项目	私有项目或保密项目