开始进行大作业编程的第一步是从 Tsinghua Git 上克隆仓库。首先打开 VSCode（如果在 Windows 上，需要用 VSCode 的 Remote 功能连接到 WSL），在 Terminal 中，用下面的命令克隆仓库并用 VSCode 打开项目：

运行命令以后，应该会得到一个新的 VSCode 窗口，之后大作业的所有开发，都会在这个 VSCode 窗口中完成。

需要注意的是，如果你在 Windows 环境下（而不是 WSL）克隆，Git 会把代码中的 LF（换行）替换成 CRLF（回车换行），这会导致自动评测的时候将 CR（回车）引入到命令行参数，将 CRLF（回车换行）引入到标准输入。这可能会影响代码的行为，例如表现为死循环或者等待标准输入。

为了解决这个问题，有如下三种解决方案：

小结：克隆了大作业代码仓库，并且用 VSCode 打开。

仓库中提供了初始的模板代码，首先是 src/main.rs，定义了 main 函数：

这段代码的所有部分都可以删掉重新写，放在模板中只是为了演示一些第三方库的用法。例如如何使用 let is_tty = atty::is(atty::Stream::Stdout); 语句来判断目前处于交互模式还是测试模式：

这么做是为了方便自动测试。和 Online Judge 一样，自动测试程序会通过标准输入输出与 Wordle 程序进行交互，因此不希望出现额外的输出来妨碍自动测试程序。在运行程序的时候，如果把标准输出重定向到了文件或者管道，那么 let is_tty = atty::is(atty::Stream::Stdout) 就会得到 is_tty == false，进入测试模式。例子如下：

接着，代码中出现了 console 库的使用，来打印出带颜色的文字：

在 Rust 语言中，第三方库（即除语言的标准库之外的库）对应的是外部的 crate，所有公开发布的 crate 都在 crates.io 上可以找到，它相当于 Python 语言的 PyPI，Java 语言的 Maven。如果想要查询第三方库的文档，以 console 库为例，做法是：

文档往下翻到 Colors and Styles，就可以看到如何用 console 库设置输出文本格式的例子：

继续往下翻，可以看到这个库提供的 Struct 和函数。点击 Style，就可以看到 Struct Style 的文档。往下翻，就可以看到它提供了各种函数，其中就包括了上面用到的函数：

可以继续探索文档，看看第三方库都提供了哪些函数，如果对实现感兴趣，也可以点击旁边的 Source 链接，可以直接定位到源代码，学习别人的写法

除了 src/main.rs 以外，还提供了 src/builtin_words.rs 文件，里面存储了“可用词”和“候选词”两个词库，你不需要修改里面的内容。

小结：阅读了模板代码，学习了交互模式和测试模式，接触了两个第三方库的用法，学会了怎么阅读第三方库的文档。

可以用 cargo run 程序来运行 Wordle。实际上，这个命令做了两件事情：

你也可以从运行输出中看出它做的事情：

在作业要求中，经常需要向程序传递命令行参数。例如在作业要求中，需要通过命令行传递 -w CARGO 参数，此时可以使用 cargo run -- -w CARGO 命令：

在 -- 之后的命令行参数都原样地传递给了 Wordle 程序。类似地，你也可以传递其他参数。使用 -- 分隔的目的是让 cargo run 识别出哪些参数是要传给 cargo run 自己的，哪些参数是要传给 Wordle 程序的。

小结：用 cargo run 命令运行 Wordle 程序，可以用 cargo run -- 命令行参数 命令来把命令行参数传递给 Wordle 程序。

我们再尝试使用另一个第三方库 colored，来实现和 console 类似的功能。

访问的文档：https://docs.rs/colored，可以看到它已经提供了一个代码例子：

阅读上面的代码，已经大概可以看出这个库要如何使用了。接下来，需要使用命令 cargo add colored 把这个库引入到项目的依赖中：

在 Cargo.toml 文件中也可以看到它的依赖信息已经出现了：

接下来，修改 src/main.rs，根据刚刚从它的文档中学习到的使用方法来尝试一下：

就可以看到下面的输出：

其他库也是类似的。总结一下使用新的第三方库的流程：

小结：学会如何把新的第三方库引入到项目中，并基于第三方库文档提供的代码，实现自己想要的功能。

大作业的代码框架提供了自动测试，可以在本地测试基础要求部分的功能，帮助你检查代码是否出错。

自动测试的运行方式是：

这条命令的意思是，串行（--test-threads=1）地运行所有的测试。这里指定了串行，是因为 Wordle 会涉及到文件的存取。初始代码下运行自动测试，可以看到所有的测试点都失败：

你在接下来的时间内，就要一步一步地完成各项要求，把测试结果变成 PASSED。

从测试结果的底部往上翻，就可以看到每个测试点的具体情况。具体地，它会告诉你正在运行哪个测试点，你的程序输出的是什么，正确输出是什么，如

自动测试程序会自动比对 Wordle 程序的输出和正确的输出。红色代表 Wordle 程序的错误输出，绿色代表正确的输出。你的目标就是消除掉所有的错误。具体怎么做，会在未来的作业要求文档中细化。

如果想要测试单个测例，可以在命令行中指定测例的名字：

此时就不再需要 --test-threads=1 参数了，因为只运行一个测试，不指定这个参数也会是串行的。

需要注意的是，自动测试并不能覆盖所有情况，意味着自动测试通过了 不代表可以得到对应要求的满分 。此外，提高要求没有对应的自动测试，需要自己手动测试。

小结：学习了自动测试的运行方式，学会了如何阅读自动测试的输出结果。

自动测试虽然方便，但是在开发的时候，可能会希望手动运行测试的程序，这样可以直接看到输出的内容，减少调试的时间。

以测例 02_01_specify_answer 为例子，首先进入仓库的 tests/cases 目录下，可以看到这个测例的三个文件：

那么，使用 cargo test -- test_02_5_pts_specify_answer 评测的时候，实际上运行了下面的命令：

这里的 -w build 是 02_01_specify_answer.args 中指定的命令行参数。由于现在还没看到作业要求，所以你可能不知道这些参数是什么意思，等看完作业要求以后，可以再进行回顾。

然后比对 02_01_specify_answer.out 和 02_01_specify_answer.ans 的内容，如果一致，并且程序退出返回值符合预期，则评测通过。

对于需要读取和保存状态的测例，自动测试程序还会做如下操作，以 07_01_save_state 为例：

所以如果自动测试报错了，可以按照上面的命令进行手工测试，此时比较方便使用各种调试手段，例如使用下一节的调试功能。

小结：当自动测试不通过的时候，可以尝试手动测试出问题的测例，此时可以更方便地调试程序。

推荐使用 VSCode 的一大原因，就是 VSCode 对 Rust 调试功能的支持比较完善。合理利用调试器来调试，可以极大地加快开发的效率，帮助你解决各种看起来很玄学的问题。

在之前的课程中，你应该已经学过如何用调试器对 C/C++ 语言编写的程序进行调试。如果没有，至少也学过如何用 printf 来打印中间变量的方法。在实践中，基于调试器和基于打印的调试方法各有优劣，但二者都需要掌握，才能应付更多的场景。

在 VSCode 中使用调试器的方法特别简单。当你打开 src/main.rs，你会发现在 main 函数上面出现了两个“按钮”：

两个按钮分别对应 Run（执行）和 Debug（调试）。按下 Debug，就启动了调试器，就这么简单！接下来，介绍 VSCode 调试的任务就交给 官方文档，这里就不再重复了。

除了在 UI 上进行单步执行、打断点或者继续执行，你还可以修改 launch.json 中的内容来自定义传入程序的命令行参数和进行输入输出重定向等。结合上一小节的内容，可以修改 launch.json 的配置，按照某一个测例设置命令行参数，进行输入重定向，那么就可以用调试器测试程序在该测例上的行为。

如果安装了 CodeLLDB 扩展，还可以让它帮你自动创建调试配置：打开 Rust 项目后，点击左侧 Run and Debug 按钮，点击 Show all automatic debug configurations，选择 Add configuration，选择 LLDB，此时会弹出窗口询问是否要自动从 Cargo 项目中生成 launch.json 配置，选择 Yes。此时就可以在 launch.json 里看到多个调试配置，对应可执行文件、测试等等。接着，参考 CodeLLDB Manual 修改配置文件，可以实现添加命令行参数，进行输入输出重定向等等。

小结：VSCode Rust 插件提供了非常方便的调试器支持，不要忘记使用。结合手动测试，可以提高调试效率。

代码需要提交到 Tsinghua Git 上，因此需要用 Git 来把代码以 commit 的方式，push 到 Tsinghua Git 上。

简单来说，每当你：

等等，当你觉得目前的代码值得提交的时候，使用 Git 命令来生成一个 commit：

然后提交到 Tsinghua Git 上：

这里只考虑了最基本的用法，更详细的用法还需要去学习 Git。

在代码规范文档中，有关于对 Git 提交历史和提交说明的要求，请按照代码规范进行。

小结：了解如何用 Git 提交代码，学习关于 Git 的代码规范。

代码仓库还配置了持续集成（Continuous Integration，缩写 CI），持续集成的意思就是，每当你用 Git Push 新的 commit 到 Tsinghua Git 的时候，Tsinghua Git 会自动运行自动测试程序，也就是在课程组提供的服务器上运行下面的命令：

并且会记录命令的输出和结果，如果命令以非 0 码退出，那么你就会在 Tsinghua Git 上看到一个红色的叉。你可以点进去，直到看到完整的自动测试历史。当所有的自动测试通过的时候，就会看到一个绿色的勾。

持续集成带来了很多好处：

小结：Tsinghua Git 配置了持续集成，每次提交都会进行自动测试，可以在 Tsinghua Git 网站上查看自动测试结果。

你已经完成了快速入门，接下来就是按照大作业的要求，开始编程！

请浏览下一个文档以继续。