From d363ea8a4091fed72baf0cdc9328a9830155564f Mon Sep 17 00:00:00 2001
From: Xingyu Wang <xingyu.wang@gmail.com>
Date: Sun, 29 Jan 2023 14:09:57 +0800
Subject: [PATCH] RP

@yzuowei
https://linux.cn/article-15489-1.html
---
 ...�� 10 universal steps for open source code review.md | 142 ++++++++++++++++++
 ...�� 10 universal steps for open source code review.md | 137 -----------------
 2 files changed, 142 insertions(+), 137 deletions(-)
 create mode 100644 published/20221031.1 ������ 10 universal steps for open source code review.md
 delete mode 100644 translated/tech/20221031.1 ������ 10 universal steps for open source code review.md

diff --git a/published/20221031.1 ������ 10 universal steps for open source code review.md b/published/20221031.1 ������ 10 universal steps for open source code review.md
new file mode 100644
index 0000000000..4fba5a0966
--- /dev/null
+++ b/published/20221031.1 ������ 10 universal steps for open source code review.md	
@@ -0,0 +1,142 @@
+[#]: subject: "10 universal steps for open source code review"
+[#]: via: "https://opensource.com/article/22/10/code-review"
+[#]: author: "Martin Kopec https://opensource.com/users/martin-kopec"
+[#]: collector: "lkxed"
+[#]: translator: "yzuowei"
+[#]: reviewer: "wxy"
+[#]: publisher: "wxy"
+[#]: url: "https://linux.cn/article-15489-1.html"
+
+开�代�评审的�个通用步骤
+======
+
+![][0]
+
+> ��你�循这些通用�程，代�评审并��怕。
+
+你是�需�在你还没有完全�解整个项目时就对代�进行评审？抑或你�开了评审，以�让你看起��知�如何进行。
+
+本篇文章想�告诉你一个更好的方法。<ruby>代�评审<rt>code review</rt></ruby> 并�需�你知�所有事情。实际上，就我个人�验而言，这�情况�常普�。
+
+我还记得作为实习生加入 <ruby>红帽<rt>Red Hat</rt></ruby> 的时候，被�求�与代�评审。我们当时采�的是 +1 或 -1 的投票系统，而我在一开始的时候常常踌躇于该如何评审。我�现我会问自己，如果我对于一处改动给予了 +1，而别人�投了 -1，我是�是看起�很蠢？
+
+如果你对一处改动投了 +1，而别人投了 -1，这��味�什么呢？答案是��味任何事�你�能�是�掉了一处别人注�到的细节。这��味�世界末日。这也是为什么我们会用投票系统。正如�所有开�项目一样，代��并是一项��工作。
+
+最近，我接到了太多的代�评审工作，以至于我几乎��过�。我�时也注�到，�与评审的贡献者数�正在稳步�少。
+
+出于这个原因，我想�写一篇文章�述我对代�评审的个人观点。在这篇文章里，我会分享一些诀�与技巧。我将会�你展示几个用�问自己的问题，以�在评审代�时需�注�的一些地方。
+
+### 代�评审的目的是什么？
+
+你是�曾写过一个�常简�的补�？你认为它是如此微�足�，�需�审查。或许你直接就�并了它。直到晚些时候，你�识到你犯了个错误，一个明显的或是愚蠢的错误，比如错误的缩进，比如几行��的代�而�是调用函数（是的，这些都是�验之谈�）。
+
+如果有其他人�审查代�，就会�现这些东西。
+
+代�评审的一个目的便是为你带�一�新的眼�，从新的视角看待你��试解决的问题。这�新的背景也正是为什么代�评审至关��。
+
+你�能认为你必须是一个语言专家，�能审查别人的代��项目，或两者。让我�告诉你一个所有代�评审者都想跟你说的秘密�：大错特错�你并�需�完全�解该项目或者编程语言，就�以为一个改动�供全新的视角。下�，我将�你展示代�评审的通用�程。
+
+### 代�评审的通用�程
+
+这是我的代�评审�程，拆分�了几个�点。这个�程包�了我会问自己的一些问题，以帮助我专注于代�的�化以�其�果。你�需�严格�照这个顺��进行评审。如果有任何原因导致你无法执行其中的�一步，跳过那一步就好。
+
+#### 1��解改动，它想�解决的问题，以�为什么�这么�
+
+为什么需�改动的解释以�任何相关背景都应该被放在 <ruby>�交<rt>commit</rt></ruby> 信�里。如果没有，请�求�供，并请投 -1 直到相关信�被�供。
+
+改动想解决的问题需�被解决�？它是项目应当关注的问题，还是与项目完全无关？
+
+#### 2�你会如何实现解决方案？它会�一样�？
+
+在这个时候，你应该已�知�代�改动是为了什么。��是你会怎么�？在进一步对改动进行细节评审�，先�考这个问题。如果你想出了一个�一样的解决方案，并且你认为你的方案更好，在评审中�出�。你�需�投 -1；去问问作者为什么没有往那个方�走，看看这次讨论会把你们带�何方。
+
+#### 3��行有改动和没有改动的代�
+
+我通常会在代�中设置几个断点，�行代�并检查新代�是如何与其余部分互动的。
+
+如果你无法�行整个代�，试�将带有新代�的函数�制到一个新的本地文件，模拟输入数�，然��行。这在你�知�怎么�行整个项目，或者无法接触到�行所需的特殊环境时很有帮助。
+
+#### 4�新代�会破�任何东西�？
+
+我是说，任何东西。想一想�能的�果。
+
+以一个新的命令行选项为例，它会总是被目标所接��？
+
+是�存在这样一�情况，使得新选项无法被接�或是会与其他东西起冲�？
+
+或许新代�是导入了新的东西。那么这个新的库，以��能的新的�赖关系，能够在�版本或者项目的�行系统中被找到�？
+
+安全方�呢？新的�赖足够安全�？你至少�以在网上快速地�索一下。还有，注�一下控制�日志里的警告。有的时候在�一个库里也�以找到更安全的函数。
+
+#### 5�新代�是�有效？
+
+你刚刚确认了被�出的解决方案大概是正确的。现在该检查代�本身了。你需�关注代�的有效性和必�性。
+
+检查新代�的风格。它与项目的代�风格相匹��？任何开�项目都（应该）有一份文档告知（新）贡献者项目所�循的风格和优秀实践。
+
+比如说，OpenStack 社区的所有项目都有一份 HACKING.rst 文件。你�常也能找到一份[新贡献者指�][1]包�所有必须知�的信�。
+
+#### 6�确认所有新增的��和导入都被使用
+
+你正在评审的代�常常已�过多次迭代，有的时候代�的最终版本与�始版已迥然��。所以我们很容易忘记一些在历�版本中加入的��与引用。自动化检测通常会用到 lint 工具，类似 Python 中的 [flake8][12]。
+
+（LCTT 译注：[lint][5] 指编程中用��现代�潜在错误和约�代�风格的工具，起�于 C 语言编程中的��分�工具 `lint`。“lint� 本�为衣�上积累的绒毛与�尘，“lint� 的��寓�则在于��编程时产生的“绒毛与�尘�）
+
+（LCTT 校注：我建议，“Lint� 工具�以翻译为 “代�清�� 或 “代�清�� 工具。）
+
+你�以在�声明新��的情况下�写代��？通常情况下你�以，但问题是这样是�更好。这会带�什么益处�？我们的目标�是�创造尽�能多的�行代�，而是写出高效且易读的代�。
+
+#### 7�新的函数和方法是�必�？
+
+项目里的别的地方是�存在�以被�用的功能类似的函数？确����新�明轮�以��新实现已�被定义的逻辑永远都是值得的。
+
+#### 8�有�元测试�？
+
+如果补�增加了新的函数或者在函数内添加了新的逻辑，它也应该附带对应的�元测试。新函数的作者总是比别人更适�写该函数的�元测试。
+
+#### 9. 验��构
+
+如果这次�交对现有代�进行了�构（它�能�命�了�个��，或者是改�了的��的作用域，或者是通过加��数�改�函数的足迹，�或者是删去了�个东西），问一问你自己：
+
+- 这个�以被删除�？它会影�到稳定分支�？
+- 所有出现的地方都删掉了�？
+
+你�以利用 [grep 命令][3] �查找。你�会相信有多少次我投 -1 就是因为这个。这是一个任何人都会犯的简�错误，也正因如此任何人都�以�现它。
+
+�交的所有者很容易忽略这些事情，这完全�以�解。我也犯过很多次这�错误。我最终�现问题的根�在于我太急于�出评审，以至于我忘记了对仓库进行整体检查。
+
+除了对项目仓库的检查外，检查其他代�用户也�分必�。如果有别的项目导入了这个项目，它们�能也需�进行�构。在 OpenStack 社区中，我们有对应的工具�查询别的社区项目。
+
+#### 10�项目文档是�需��出更改？
+
+你�以�一次使用 [grep 命令][4] �检查在项目文档中是��到了相关的代�改动。用常识�判断这次改动是�需�被收入文档以告知最终用户，还是�是一个�会影�用户体验的内部�化。
+
+#### �外�示：考虑周到
+
+当你在评审完新代���出建议或评论时，�考虑周到，�馈准确，�述详尽。如果有你��解的地方就�出�问。如果你认为代�存在错误，解释你的�由。记�，如果作者�知�什么地方出了问题，他们就无法修�它。
+
+### 最�几�
+
+唯一的�评审是没有评审。通过评审和投票，你�供了你的观点并为此投票。没有人指望你��出最终决定（除�你是核心维护者），但是投票系统�许你�供你的观点和��。相信我，补�所有者会很高兴你这么�了的。
+
+你能想到别的�点�给出好的评审�？你是�有我�知�的特殊技巧？在评论中分享它们��
+
+--------------------------------------------------------------------------------
+
+via: https://opensource.com/article/22/10/code-review
+
+作者：[Martin Kopec][a]
+选题：[lkxed][b]
+译者：[yzuowei](https://github.com/yzuowei)
+校对：[wxy](https://github.com/wxy)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) �誉推出
+
+[a]: https://opensource.com/users/martin-kopec
+[b]: https://github.com/lkxed
+[1]: https://docs.openstack.org/tempest/latest/contributor/contributing.html
+[2]: https://opensource.com/article/19/5/python-flake8
+[3]: https://opensource.com/downloads/grep-cheat-sheet
+[4]: https://www.redhat.com/sysadmin/how-to-use-grep
+[5]: https://codedocs.org/what-is/lint-software
+[0]: https://img.linux.net.cn/data/attachment/album/202301/29/140840wsbypukbubp69buv.jpg
\ No newline at end of file
diff --git a/translated/tech/20221031.1 ������ 10 universal steps for open source code review.md b/translated/tech/20221031.1 ������ 10 universal steps for open source code review.md
deleted file mode 100644
index 26e1f558c7..0000000000
--- a/translated/tech/20221031.1 ������ 10 universal steps for open source code review.md	
+++ /dev/null
@@ -1,137 +0,0 @@
-[#]: subject: "10 universal steps for open source code review"
-[#]: via: "https://opensource.com/article/22/10/code-review"
-[#]: author: "Martin Kopec https://opensource.com/users/martin-kopec"
-[#]: collector: "lkxed"
-[#]: translator: "yzuowei"
-[#]: reviewer: " "
-[#]: publisher: " "
-[#]: url: " "
-
-开�代�评审的�个通用步骤
-======
-
-��你�循这些通用�程，<ruby>代�评审<rt>code review</rt></ruby>并��怕。
-
-你是�曾需�对代�进行评审，但你还没有完全�解整个项目？或许你�开去评审从而��你看起��是什么都�知�的洋相。
-
-本篇文章想�告诉你一个更好的方法。代�评审并�需�你知�所有事情。实际上，就我个人�验而言，这�情况�常普�。
-
-我还记得在我刚加入<ruby>红帽<rt>Red Hat</rt></ruby>�实习的时候，我被�求�与代�评审。我们当时采�的是 +1 或 -1 的投票系统，而我在一开始的时候常常踌躇该如何评审。我�现我总是问自己对于一处改动是�应该给予 +1 当别人已�投了 -1，我会看起�很蠢�？
-
-如果你对一处改动投了 +1， 但是别人�投了 -1，这��味�什么呢？这��味任何事�你�能�是�掉了一处细节而别人��好注�到了。这��味�世界末日。这也是为什么我们会用投票系统。正如�所有开�项目一样，代��并是一项��工作。
-
-最近，我接到了太多的代�评审工作以至于我难以维�进度。我�时也注�到了�与评审的贡献者数�正在稳步�少。
-
-基于这个原因，我想�写一篇文章�述我对代�评审的个人观点。在这篇文章里，我会分享一些诀�与技巧。我会�你展示几个问题你�以用�自问自答，我也会为在评审代�时需�注�什么�供一些想法。
-
-### 代�评审的目的是什么？
-
-你是�曾写过一个�常简�的补�？补�太过�碎以至于你认为评审是多余的？或许你马上进行了�并。直到晚些时候，你�识到你犯了个错误，一个明显或是愚蠢的错误，或是错误缩进，或是几行��的代�在本�以调用函数的地方（是的，这些都是�验之谈�）。
-
-一段代�本�以交予他人评审并�时�现这些问题。
-
-代�评审的一个目的便是为你在�试解决的问题带�一�全新的视角。新开阔的视野也正是为什么代�评审至关��。
-
-你�能会认为评审别人的代�需�你是一�专家，或是编程语言专家，或是项目专家，或两者兼具。让我�告诉你一个所有代�评审者都想跟你说的秘密�：大错特错�你并�需�完全�解项目或者编程语言�为改动�供全新视角。我将�你展示代�评审的通用�程。
-
-### 代�评审的通用�程
-
-这是我的代�评审�程被拆分�几个�点。这个�程包�了我会问我自己的一些问题，以帮助我专注于代�的�化以�其�果。你�需�严格�照顺��进行评审。如果有任何原因导致你无法执行其中的�一步，跳过那一步就好。
-
-### 1. �解改动，问改动想�解决的问题，以�为什么�解决这个问题
-
-为什么需�改动的解释以�任何相关背景都应该被放在<ruby>�交<rt>commit</rt></ruby>信�里。如果没有，�求相关信�并请��投 -1 直到相关信�被�供。
-
-改动想解决的问题需�被解决�？它是项目应当�焦的问题，还是与项目完全无关？
-
-### 2. 你会如何实现解决方案？它会�一样�？
-
-在这个时候，你应该已�知�代�改动是为了什么。��是你会怎么�？在进一步对改动进行细节评审��考这个问题。如果你想出了一个�一样的解法，并且你认为你的解法更好，在评审中�出�。你�需�投 -1；去问问作者为什么没有往那个方�走，看看这次讨论会把你们带�何方。
-
-### 3. �行有改�和无改�的代�
-
-我通常会在代�中设置几个断点，�行代�并检查新代�是如何与其余部分互动的。
-
-如果你无法�行整个代�，试�将带有新代�的函数�制到一个新的本地文件，模拟输入数�，然��行。这在你�知�怎么�行整个项目或者无法接触到�行所需的特殊环境时很有帮助。
-
-### 4. 新代�会破�任何东西�？
-
-我是说，任何东西。想一想�能的�果。
-
-以一个新的命令行选项为例，它会总是被目标所接��？
-
-是�存在这样一�情况使得新选项无法被接�或是会与其他东西起冲�？
-
-或许新代�是一个新的导入。那么这个新的库，很�能也是新的�赖，能够在�版本或者项目的�行系统中被找到�？
-
-安全方�呢？新的�赖足够安全�？你至少�以在网上快速地�索一下。还有，注�一下控制�日志里的警告。有的时候在�样的库里也�以找到更安全的方法。
-
-### 5. 新代�是�有效？
-
-你刚刚确认了被�出的解决方案大概是正确的。现在该检查代�本身了。你需�关注代�的有效性和必�性。
-
-检查新代�的风格。它与项目的代�风格相匹��？任何开�项目都（应该）有一份文档告知（新）贡献者项目所�循的风格和优秀实践。
-
-比如说，OpenStack 社区的所有项目都有一份 HACKING.rst 文件。你�常也能找到一份[新贡献者指�][1]包�所有必须知�的信�。
-
-### 6. 确认所有新增的��和导入都被使用
-
-你正在评审的代�常常已�过多次迭代，有的时候代�的最终版本与�始版已迥然��。所以我们很容易忘记一些在历�版本中加入的��与引用。自动化检测通常会用到 lint 工具，类似 Python 中的 [flake8][12]。
-
-（LCTT 译注：[lint][5] 指编程中用��现代�潜在错误和约�代�风格的工具，起�于 C 语言编程中的��分�工具 lint。lint 本�为衣�上积累的绒毛与�尘，lint 的��寓�则在于��编程时产生的“绒毛与�尘�）
-
-你�以在�声明新��的情况下�写代��？通常情况下你�以，但问题是这样是�更好。这会带�什么益处�？我们的目标�是多写花�的一行代�，而是写出高效且易读的代�。
-
-### 7. 新的函数和方法是�必�？
-
-项目里的别的地方是�存在�以被�用的功能类似的函数？确����新�明轮�以��新实现已�被定义的逻辑永远都是值得的。
-
-### 8. 有�元测试�？
-
-如果补�增加了新的函数或者在函数内添加了新的逻辑，它也应该附带对应的�元测试。新函数的作者总是比别人更适�写该函数的�元测试。
-
-### 9. 验��构
-
-如果这次�交对现有代�进行了�构（它�能�命�了�个��，或者是改�了的��的作用域，或者是通过加��数�改�函数的足迹，�或者是删去了�个东西），问一问你自己：
-
-- 这个�以被删除�？它会影�到稳定分支�？
-- 所有出现的地方都删掉了�？
-
-你�以利用 [grep 命令][3]�查找。你�会相信有多少次我投 -1 就是因为这个。这是一个任何人都会犯的错误，也正因如此任何人都�以�现它。
-
-�交的所有者很容易忽略这些事情，这完全�以�解。我也犯过很多次这�错误。我最终�现问题的根�在于我太急于�出评审，以至于我忘记了对仓库进行整体检查。
-
-除了对项目仓库的检查外，检查其他代�用户也�分必�。如果有别的项目导入了这个项目，它们�能也需�进行�构。在 OpenStack 社区中，我们有对应的工具�查询别的社区项目。
-
-### 10. 项目文档是�需��出更改？
-
-你�以�一次使用 [grep 命令][4]�检查在项目文档中是��到了相关的代�改动。用常识�判断这次改动是�需�被收入文档以告知最终用户，还是�是一个�会影�用户体验的内部�化。
-
-### �外�示：考虑周到
-
-当你在评审完新代���出建议或评论时，�考虑周到，�馈准确，�述详尽。如果有你��解的地方就�出�问。如果你认为代�存在错误，解释你的�由。记�，作者无法修�他�知�的�洞。
-
-### 最�几�
-
-唯一的�评审是没有评审。通过评审和投票，你�供了你的观点并为此�声。没有人指望你��出最终决定（除�你是核心维护者），但是投票系统�许你�供你的观点和��。相信我，补�所有者会很高兴你这么�了的。
-
-你能想到别的�点�给出好的评审�？你是�有我�知�的特殊技巧？在评论中分享它们��
-
---------------------------------------------------------------------------------
-
-via: https://opensource.com/article/22/10/code-review
-
-作者：[Martin Kopec][a]
-选题：[lkxed][b]
-译者：[yzuowei](https://github.com/yzuowei)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) �誉推出
-
-[a]: https://opensource.com/users/martin-kopec
-[b]: https://github.com/lkxed
-[1]: https://docs.openstack.org/tempest/latest/contributor/contributing.html
-[2]: https://opensource.com/article/19/5/python-flake8
-[3]: https://opensource.com/downloads/grep-cheat-sheet
-[4]: https://www.redhat.com/sysadmin/how-to-use-grep
-[5]: https://codedocs.org/what-is/lint-software