Updated 'src/io_project/refactoring.md'.

src/io_project/refactoring.md

@@ -1,23 +1,17 @@
-# 重构以改进模块化与错误处理
+# 重构以改进模组化与错误处理
 
-**Refactoring to Improve Modularity and Error Handling**
+为了改进我们的程序，我们将解决四个与程序结构及其潜在错误处理方式相关的问题。首先，我们的 `main` 函数现在执行两项任务：解析命令行参数和读取文件。随着我们程序的增长，`main` 函数处理的单独任务的数目将会增加。随着函数承担的责任越来越多，他会变得更加难于推理、更难于测试，并且在不破坏其某个部分的情况下修改也愈发困难。最好要分离功能，以便每个函数负责一项任务。
+
+这个问题还与第二个问题有关：尽管 `query` 和 `file_path` 属于我们程序的配置变量，但像 `contents` 这样的变量则被用于执行程序的逻辑。`main` 函数变得越长，我们将需要带入作用域的变量就越多；我们在作用域中的变量越多，跟踪每个变量的目的就越困难。因此最好分组配置变量为一种数据结构，使其目的明确。
+
+第三个问题则是，我们使用了 `expect` 在读取文件失败时打印一条错误消息，但错误消息只是打印 `应该已经能够读取文件`。读取文件可能会以多种方式失败：比如，文件可能丢失，或我们可能没有打开他的权限等等。目前，无论何种情形，我们都将针对所有原因打印同一条错误消息，这不会给予用户任何信息！
+
+第四，我们使用 `expect` 来处理错误，当用户在未指定足够参数的情况下运行我们的程序时，他们将得到 Rust 的一个 `index out of bounds` 报错，而这个报错并不能清楚地解释问题。若所有错误处理代码都在一处就最好，以便今后的维护人员在错误处理逻辑需要修改时，就只需在一个地方查阅代码。将所有的错误处理代码放在一处，还将确保我们打印的是对最终用户有意义的消息。
+
+我们来通过重构我们的项目，来解决这四个问题。
 
 
-为改进这个程序，这里就要修复与该程序结构及其处理潜在错误方式有关的四个问题。首先，这里的 `main` 函数现在执行了两个任务：他对参数进行解析并读取文件。随着程序的增长，这个 `main` 函数所处理的独立任务数目将不断增加。而随着函数不断获得其任务，就会变得更加难于推理，更难于对其进行测试，以及更难于在不破坏其各个部分的情况下对其进行修改。那么最后就要将功能拆分，从而每个函数负责一项任务。
-
-这个问题同样联系着第二个问题：尽管这里的 `query` 与 `file_path` 属于这个程序的配置性变量，而像 `contents` 这样的变量则被用于执行该程序的逻辑处理。这个 `main` 函数变得越长，那么这里就会将更多的变量引入到作用域；在作用域中的变量越多，那么就会越难对各个变量的目的保持追踪。因此就最好将这些配置变量，分组到某个结构体中，而令到他们的目的明确。
-
-第三个问题则是，在读取那个文件失败时，这里使用了 `expect` 将一条错误消息打印处理，而该错误消息只会打印 “应能读取这个这个文件。” 文件读取以多种方式失败：比如那个文件可能没有，或可能没有打开他的权限。此时，无论何种情形，这里都将打印同样的错误消息，这样并不会给到用户任何信息！
-
-第四，这里重复地使用了 `expect` 来处理不同重复，而在用户未指定足够参数时，他们就会得到一个并不会清楚解释问题原因、 Rust 的 `index out of bounds` 错误。若全部错误处理代码都在一个地方，那么就最好了，这样在错误处理代码需要修改时，那么以后的维护者就只有一个地方来查阅代码。将全部错误处理代码放在一处，还将确保这里打印的消息，是会对终端用户有意义的那些消息。
-
-下面就来通过对这里的项目进行重构，来解决这四个问题。
-
-
-## 二进制程序项目的关注点分离
-
-**Separation of Concerns for Binary Projects**
-
+## 二进制项目中的关注点分离
 
 将多重任务分配给那个 `main` 函数方面的组织性问题，常见于许多二进制项目。由此 Rust 社区业已开发了在 `main` 开始变得大型起来时，将二进制程序单个关注点进行剥离的守则。这个剥离单独关注点的过程，有着以下几个步骤：