feat: 解决语病

README.md

@@ -26,8 +26,8 @@ expect(sum(1, 1)).toEqual(2)
 
 **没有测试策略。** 上面是 “技” 的难点，测试还有 “术” 的难点。闷着头一通肝测试代码并不高效，使用合适的测试策略远比写 10 个测试用例重要。
 
-上面这些问题很容易让人写出维护性差、经不住业务变动的测试。只要业务一改，你不仅要维护业务代码还要维护测试代码。
-不禁感叹：“测试真浪费时间”，最终放弃写测试，直接开摆。
+上面这些问题很容易让人写出难以维护和复杂的测试。只要业务一改，不仅要维护业务代码还要维护测试代码。
+这时，你不禁感叹：“测试真浪费时间”，最终放弃写测试，直接开摆。
 
 **好的测试会让你获得很高的代码信心，而不好的测试则会严重拖垮项目开发。所以，大家所厌恶的不应该是测试本身，而是那些维护性差的测试。**
 
@@ -45,10 +45,10 @@ expect(sum(1, 1)).toEqual(2)
 
 ![](./bad-translation.png)
 
-先不说翻译的正确性如何，单看这中文的内容就让人没有想看下去的欲望，真的希望 Jest 能找专门点的人来做翻译。
+先不说翻译的正确性如何，单看这中文的内容就让人没有想看下去的欲望，真希望 Jest 能找稍微专业一点的人来做翻译。
 由于官网的中文翻译做的实在太烂，遇到问题几乎在中文社区是找不到的。
 
-直到，我看到了 React Testing Library 作者 Kent C. Dodds 的 [博客](https://kentcdodds.com/) 。
+终于，我看到了 React Testing Library 作者 Kent C. Dodds 的 [博客](https://kentcdodds.com/) 。
 
 ![](./kentcdodds.png)
 

docs/README.md

@@ -25,8 +25,8 @@ expect(sum(1, 1)).toEqual(2)
 
 **没有测试策略。** 上面是 “技” 的难点，测试还有 “术” 的难点。闷着头一通肝测试代码并不高效，使用合适的测试策略远比写 10 个测试用例重要。
 
-上面这些问题很容易让人写出维护性差、经不住业务变动的测试。只要业务一改，你不仅要维护业务代码还要维护测试代码。
-不禁感叹：“测试真浪费时间”，最终放弃写测试，直接开摆。
+上面这些问题很容易让人写出难以维护和复杂的测试。只要业务一改，不仅要维护业务代码还要维护测试代码。
+这时，你不禁感叹：“测试真浪费时间”，最终放弃写测试，直接开摆。
 
 **好的测试会让你获得很高的代码信心，而不好的测试则会严重拖垮项目开发。所以，大家所厌恶的不应该是测试本身，而是那些维护性差的测试。**
 
@@ -44,10 +44,10 @@ expect(sum(1, 1)).toEqual(2)
 
 ![](./bad-translation.png)
 
-先不说翻译的正确性如何，单看这中文的内容就让人没有想看下去的欲望，真的希望 Jest 能找专门点的人来做翻译。
+先不说翻译的正确性如何，单看这中文的内容就让人没有想看下去的欲望，真希望 Jest 能找稍微专业一点的人来做翻译。
 由于官网的中文翻译做的实在太烂，遇到问题几乎在中文社区是找不到的。
 
-直到，我看到了 React Testing Library 作者 Kent C. Dodds 的 [博客](https://kentcdodds.com/) 。
+终于，我看到了 React Testing Library 作者 Kent C. Dodds 的 [博客](https://kentcdodds.com/) 。
 
 ![](./kentcdodds.png)