https://missing.csail.mit.edu/https://missing-semester-cn.g...https://www.bilibili.com/vide...Segmentfault主页：https://segmentfault.com/u/wi...注元编程通常是指用于操作程序的程序，讲座中的讨论更多的是开发过程。构建系统“构建系统”帮助我们执行一系列“构建过程”。构建过程包括：目标、依赖项和规则。你必须告诉构建系统你具体的构建目标，系统的任务就是找到构建这些目标所需要的依赖，并按照规则构建所需的中间产品，直到构建出最终的目标。理想情况下，如果目标的依赖项没有改变并且我们可以重用以前构建中的那些依赖项，那么与其关联的构建规则将不会被强制执行。make是最常用的构建系统之一，您会发现它安装在几乎所有基于UNIX的系统上。make教程可以参考阮一峰的这篇文章：MakeCommandTutorial。其他常用构建系统/工具：C和C++：Cmake，可以参考CMake入门Java：Maven、Ant、Gradle前端开发：Grunt、Gulp、WebpackRuby：RakeRust：Cargo依赖管理软件仓库Ubuntu：可以使用工具apt访问Ubuntu包仓库CentOS、Redhat：通过yum工具访问软件仓库Archlinux/Manjaro：通过pacman工具访问Archlinux软件仓库和ArchUserRepository（AUR，ArchUserRepository）Ruby：通过pacman访问RubyGemsgem工具Python：通过pip访问Pypi版本号的工具，不同项目使用的版本号的具体含义并不完全相同，但是一个比较通用的标准是语义版本号，它有不同的语义。其格式如下：major.minor.patch(主版本号.次版本号.补丁号)。相关规则是：如果新版本没有改变API，请增加补丁号；如果您添加了API并且更改是向后兼容的，请增加次要版本号；如果您修改了API但它不向后兼容，请增加主版本号。这样做有很多好处。比如我们的项目是基于你的项目构建的，只要最新版本的主版本号不变，次版本号不低于我们之前使用的版本就安全了。也就是说，如果我依赖的版本是1.3.7，用1.3.8、1.6.1，甚至1.3.0都没问题。如果版本号是2.2.4，可能就不行了，因为它的主版本号增加了。持续集成持续集成或CI是“代码更改时自动运行的东西”的总称，可以将其视为基于云的构建系统。市场上有许多公司提供各种CI工具，例如TravisCI、AzurePipelines和GitHubActions。它们的使用方式相同：在代码仓库中添加一个文件（recipe），在里面写规则，规则包括事件和动作。最常见的规则是：如果有人提交代码，则执行测试套件。当这个事件被触发时，CI提供者会启动一个（或多个）虚拟机，执行你制定的规则，通常会记录相关的执行结果。您可以进行设置，以便在测试套件失败时收到通知，或者在测试全部通过时在存储库主页上显示徽标。Github还有一个CI工具Dependabot用于维护依赖。GitHub页面就是一个很好的例子。每次有代码更新时，Pages都会执行Jekyll博客软件，然后通过GitHub域访问您的站点。这些事情对我们来说太微不足道了。现在我们只需要在本地进行修改，然后使用git提交代码，发布到远程即可。CI会自动帮我们处理后续。测试套件（Testsuite）：统称所有测试单元测试（Unittest）：一种“微型测试”，用于测试某个包的特性集成测试（Integrationtest）：一种“宏测试”，针对系统对它的很大一部分进行了测试，以查看其不同的功能或组件是否可以协同工作。回归测试：用于确保以前引起问题的错误不会再次出现。Mocking：用伪造的实现替换函数、模块或类型，屏蔽那些与测试无关的。例如，你可能会“模拟一个网络连接”或“模拟一个硬盘”作业问题1一些有用的makebuildtargets（比如这个问题使用了phony）。.PHONY:cleanclean:gitls-files-o|xargsrm#这也会删除gitignore中的文件，比如一些编辑器配置文件#这道题也可以做#rmplot-*.png#rmpaper.pdfExercise3#!/bin/sh##Anexamplehookscript验证将要提交的内容。#由“gitcommit”调用，不带任何参数。如果钩子想要停止提交，它应该#在发出适当的消息后以非零状态退出。#将输出重定向到stderr.exec1>&2if(!make)thencat<<\EOFError:makefailed.Excuting'makepaper.pdf'.EOFmakepaper.pdfexit1fi练习4基于GitHubPages创建任何可以自动发布的页面。在仓库中添加一个GitHubAction，对仓库中的所有shell文件执行shellcheck（方法之一）。Exercise5构建自己的GitHubaction，对仓库中的所有.md文件执行proselint或write-good，在自己的仓库中开启此功能，提交一个有错误的文件，查看功能是否生效。
