From e5c2807edfdc270e037080dc122845e5803ca21d Mon Sep 17 00:00:00 2001
From: yzuowei <yzuowei@outlook.com>
Date: Fri, 27 Jan 2023 10:07:47 +0800
Subject: [PATCH] translated

---
 ...�� 10 universal steps for open source code review.md | 115 +++++++++---------
 1 file changed, 59 insertions(+), 56 deletions(-)

diff --git a/sources/tech/20221031.1 ������ 10 universal steps for open source code review.md b/sources/tech/20221031.1 ������ 10 universal steps for open source code review.md
index 3a5c517c3a..a7b84ce098 100644
--- a/sources/tech/20221031.1 ������ 10 universal steps for open source code review.md	
+++ b/sources/tech/20221031.1 ������ 10 universal steps for open source code review.md	
@@ -2,118 +2,120 @@
 [#]: via: "https://opensource.com/article/22/10/code-review"
 [#]: author: "Martin Kopec https://opensource.com/users/martin-kopec"
 [#]: collector: "lkxed"
-[#]: translator: "yzuowei"
+[#]: translator: " "
 [#]: reviewer: " "
 [#]: publisher: " "
 [#]: url: " "
 
-10 universal steps for open source code review
+开�代�评审的�个通用步骤
 ======
 
-Code review doesn't have to be scary when you follow this universal process.
+��你�循这些通用�程，<ruby>代�评审<rt>code review</rt></ruby>并��怕。
 
-Have you ever found yourself in a situation where you needed to do a code review but didn't fully understand the project? Maybe you did not review it to avoid looking like you didn't know what you were doing.
+你是�曾需�对代�进行评审，但你还没有完全�解整个项目？或许你�开去评审从而��你看起��是什么都�知�的洋相。
 
-This article assures you that there's a better way. You don't need to know everything to provide a code review. In fact, based on my experience, that's quite common.
+本篇文章想�告诉你一个更好的方法。代�评审并�需�你知�所有事情。实际上，就我个人�验而言，这�情况�常普�。
 
-I remember when I joined Red Hat as an intern and was asked to help with code reviews. We used a system of +1 or -1 votes, and I was initially very hesitant to weigh in. I found myself asking whether when I gave a +1 on a change but then someone else voted -1, would I look foolish?
+我还记得在我刚加入<ruby>红帽<rt>Red Hat</rt></ruby>�实习的时候，我被�求�与代�评审。我们当时采�的是 +1 或 -1 的投票系统，而我在一开始的时候常常踌躇该如何评审。我�现我总是问自己对于一处改动是�应该给予 +1 当别人已�投了 -1，我会看起�很蠢�？
 
-What does happen if someone votes -1 on a change you've vote +1? The answer is nothing! You might have missed a detail that the other person noticed. It's not the end of the world. That's why we have this voting system. Like the rest of open source, merging code is a collaborative effort.
+如果你对一处改动投了 +1， 但是别人�投了 -1，这��味�什么呢？这��味任何事�你�能�是�掉了一处细节而别人��好注�到了。这��味�世界末日。这也是为什么我们会用投票系统。正如�所有开�项目一样，代��并是一项��工作。
 
-Lately, I've been so inundated with code reviews that I can hardly keep up with them. I also noticed that the number of contributors doing these reviews steadily decreased.
+最近，我接到了太多的代�评审工作以至于我难以维�进度。我�时也注�到了�与评审的贡献者数�正在稳步�少。
 
-For this reason, I'm writing about my point of view on writing a code review. In this article, I'll share some helpful tips and tricks. I'll show you a few questions you should ask yourself and a few ideas of what to look for when doing a code review.
+基于这个原因，我想�写一篇文章�述我对代�评审的个人观点。在这篇文章里，我会分享一些诀�与技巧。我会�你展示几个问题你�以用�自问自答，我也会为在评审代�时需�注�什么�供一些想法。
 
-### What is the purpose of a code review?
+### 代�评审的目的是什么？
 
-Have you ever written a really simple patch? Something you think is so trivial that it doesn't require a review? Maybe you merged it straight away. Later, it turns out there was a mistake, something obvious or silly, like the wrong indentation or a few duplicated lines of code instead of a function call (yes, I'm speaking from experience!).
+你是�曾写过一个�常简�的补�？补�太过�碎以至于你认为评审是多余的？或许你马上进行了�并。直到晚些时候，你�识到你犯了个错误，一个明显或是愚蠢的错误，或是错误缩进，或是几行��的代�在本�以调用函数的地方（是的，这些都是�验之谈�）。
 
-A code review by someone else would have caught these things.
+一段代�本�以交予他人评审并�时�现这些问题。
 
-The point of a code review is to bring a fresh pair of eyes with a new perspective on the problem you're trying to solve. That new context is exactly the reason a code review is crucial.
+代�评审的一个目的便是为你在�试解决的问题带�一�全新的视角。新开阔的视野也正是为什么代�评审至关��。
 
-You may think that you must be an expert in the language to review someone else's code, the project, or both. Here's a secret all code reviewers want you to know: That's wrong! You don't need to fully understand the project or the language to provide a fresh perspective on a change. There's a universal process of code review.
+你�能会认为评审别人的代�需�你是一�专家，或是编程语言专家，或是项目专家，或两者兼具。让我�告诉你一个所有代�评审者都想跟你说的秘密�：大错特错�你并�需�完全�解项目或者编程语言�为改动�供全新视角。我将�你展示代�评审的通用�程。
 
-### The universal process of a code review
+### 代�评审的通用�程
 
-Here's my process for code review, grouped into a couple of points. The process provides questions I ask myself to help me focus on a code change and its consequences. You don't need to go in this specific order. If there's a step, you can't execute for any reason, just move to another step.
+这是我的代�评审�程被拆分�几个�点。这个�程包�了我会问我自己的一些问题，以帮助我专注于代�的�化以�其�果。你�需�严格�照顺��进行评审。如果有任何原因导致你无法执行其中的�一步，跳过那一步就好。
 
-### 1. Understand the change, what it's trying to solve, and why
+### 1. �解改动，问改动想�解决的问题，以�为什么�解决这个问题
 
-The explanation of why the change is needed and any relevant context should be in the commit message. If it isn't, request it and feel free to -1 until it's provided.
+为什么需�改动的解释以�任何相关背景都应该被放在<ruby>�交<rt>commit</rt></ruby>信�里。如果没有，�求相关信�并请��投 -1 直到相关信�被�供。
 
-Is it something that needs to be solved? Is it something the project should focus on, or is it completely out of scope?
+改动想解决的问题需�被解决�？它是项目应当�焦的问题，还是与项目完全无关？
 
-### 2. How would you implement the solution? Would it be different?
+### 2. 你会如何实现解决方案？它会�一样�？
 
-At this point, you know what the code change is about. How would you have done it? Think about this before reviewing the change in detail. If the solution you have in mind is different from the one you're reviewing, and you think it's better, bring that up in the review. You don't need to -1 it; just ask why the author didn't go in this direction and see how the discussion evolves.
+在这个时候，你应该已�知�代�改动是为了什么。��是你会怎么�？在进一步对改动进行细节评审��考这个问题。如果你想出了一个�一样的解法，并且你认为你的解法更好，在评审中�出�。你�需�投 -1；去问问作者为什么没有往那个方�走，看看这次讨论会把你们带�何方。
 
-### 3. Run the code with and without the change
+### 3. �行有改�和无改�的代�
 
-I usually put a few breakpoints into the code, run it, and inspect how the new code interacts with the rest.
+我通常会在代�中设置几个断点，�行代�并检查新代�是如何与其余部分互动的。
 
-If you can't run the whole code, try to copy the function containing the new code to a new local file, simulate the input data, and run that. This is helpful when you either don't know how to run the whole project or when it requires a specific environment to which you don't have access.
+如果你无法�行整个代�，试�将带有新代�的函数�制到一个新的本地文件，模拟输入数�，然��行。这在你�知�怎么�行整个项目或者无法接触到�行所需的特殊环境时很有帮助。
 
-### 4. Can the new code break anything?
+### 4. 新代�会破�任何东西�？
 
-I mean, really anything. Think about the consequences.
+我是说，任何东西。想一想�能的�果。
 
-In the case of a new command-line option, will it always be accepted by the target?
+以一个新的命令行选项为例，它会总是被目标所接��？
 
-Can a situation occur when the option wouldn't be accepted or when it could conflict with something?
+是�存在这样一�情况使得新选项无法被接�或是会与其他东西起冲�？
 
-Maybe it's a new import. Is the new library, and possibly a new dependency, available in the older releases or systems you ship the project for?
+或许新代�是一个新的导入。那么这个新的库，很�能也是新的�赖，能够在�版本或者项目的�行系统中被找到�？
 
-What about security? Is the new dependency safe to use? The least you can do is run a quick Internet search to find out. Also, look for warnings in the console log. Sometimes there are more secure methods within the same library.
+安全方�呢？新的�赖足够安全�？你至少�以在网上快速地�索一下。还有，注�一下控制�日志里的警告。有的时候在�样的库里也�以找到更安全的方法。
 
-### 5. Is the code effective?
+### 5. 新代�是�有效？
 
-You've determined that the proposed solution is probably correct. Now it's time to check the code itself, its effectiveness, and its necessity.
+你刚刚确认了被�出的解决方案大概是正确的。现在该检查代�本身了。你需�关注代�的有效性和必�性。
 
-Check the style of the new code. Does it match the style of the project? Any open source project has (or should have) a document informing (new) contributors about the styles and good practices the project follows.
+检查新代�的风格。它与项目的代�风格相匹��？任何开�项目都（应该）有一份文档告知（新）贡献者项目所�循的风格和优秀实践。
 
-For instance, every project in the OpenStack community has a HACKING.rst file. There's often also [a guide for new contributors][1] with all the must-know information.
+比如说，OpenStack 社区的所有项目都有一份 HACKING.rst 文件。你�常也能找到一份[新贡献者指�][1]包�所有必须知�的信�。
 
-### 6. Check that all new variables and imports are used
+### 6. 确认所有新增的��和导入都被使用
 
-Often, there have been many iterations of the code you're reviewing, and sometimes the final version is very different from when it started. It's easy to forget an import or a new variable that was needed in a former version of the new code. Automation usually checks these things using linting tools like [flake8][2] in the case of Python code.
+你正在评审的代�常常已�过多次迭代，有的时候代�的最终版本与�始版已迥然��。所以我们很容易忘记一些在历�版本中加入的��与引用。自动化检测通常会用到 lint 工具，类似 Python 中的 [flake8][12]。
 
-Can you rewrite the code without declaring new variables? Well, usually, yes, but the question is whether it's better that way. Does it bring any benefit? The goal isn't to create as many one-liners as possible. The goal is to write code that is both efficient and easy to read.
+（LCTT 译注：[lint][5] 指编程中用��现代�潜在错误和约�代�风格的工具，起�于 C 语言编程中的��分�工具 lint。lint 本�为衣�上积累的绒毛与�尘，lint 的��寓�则在于��编程时产生的“绒毛与�尘�）
 
-### 7. Are the new functions or methods necessary?
+你�以在�声明新��的情况下�写代��？通常情况下你�以，但问题是这样是�更好。这会带�什么益处�？我们的目标�是多写花�的一行代�，而是写出高效且易读的代�。
 
-Is there a similar function that can be reused somewhere in the project? It's always worth helping to avoid reinventing the wheel and re-implementing logic that's already been defined.
+### 7. 新的函数和方法是�必�？
 
-### 8. Are there unit tests?
+项目里的别的地方是�存在�以被�用的功能类似的函数？确����新�明轮�以��新实现已�被定义的逻辑永远都是值得的。
 
-If the patch adds a new function or new logic in a function, it should also include new unit tests for that. It's always better when the author of a new function also writes unit tests for it.
+### 8. 有�元测试�？
 
-### 9. Verify refactoring
+如果补�增加了新的函数或者在函数内添加了新的逻辑，它也应该附带对应的�元测试。新函数的作者总是比别人更适�写该函数的�元测试。
 
-If the commit refactors existing code (it renames a variable, changes variable scope, changes the footprint of a function by adding or removing arguments, or removes something), ask yourself:
+### 9. 验��构
 
-- Can this be removed? Will it affect the stable branch?
-- Are all the occurrences deleted?
+如果这次�交对现有代�进行了�构（它�能�命�了�个��，或者是改�了的��的作用域，或者是通过加��数�改�函数的足迹，�或者是删去了�个东西），问一问你自己：
 
-You can use the [grep command][3] to find out. You wouldn't believe how many times I've voted -1 just because of this. This is a simple mistake that anyone can make, but that also means anyone can uncover it.
+- 这个�以被删除�？它会影�到稳定分支�？
+- 所有出现的地方都删掉了�？
 
-The owner of the commit can easily overlook these things, which is totally understandable. It's happened to me many times too. I'd finally figured out the root of the problem I'd been fixing, so I was in a rush to propose the review, and then I forgot to check the whole repo.
+你�以利用 [grep 命令][3]�查找。你�会相信有多少次我投 -1 就是因为这个。这是一个任何人都会犯的错误，也正因如此任何人都�以�现它。
 
-Apart from the project's repository, sometimes it's also necessary to check other code consumers. If some other project imports this one, they may need refactoring, too. In the OpenStack community, we have a tool that searches across every community project.
+�交的所有者很容易忽略这些事情，这完全�以�解。我也犯过很多次这�错误。我最终�现问题的根�在于我太急于�出评审，以至于我忘记了对仓库进行整体检查。
 
-### 10. Does project documentation need to be modified?
+除了对项目仓库的检查外，检查其他代�用户也�分必�。如果有别的项目导入了这个项目，它们�能也需�进行�构。在 OpenStack 社区中，我们有对应的工具�查询别的社区项目。
 
-Again, you can use the [grep command][4] to check whether the project documentation mentions anything related to the code change. Apply common sense to determine whether a change needs to be documented for end users or it's just an internal change that doesn't affect user experience.
+### 10. 项目文档是�需��出更改？
 
-### Bonus tip: Be considerate
+你�以�一次使用 [grep 命令][4]�检查在项目文档中是��到了相关的代�改动。用常识�判断这次改动是�需�被收入文档以告知最终用户，还是�是一个�会影�用户体验的内部�化。
 
-Be considerate, precise, and descriptive if you make a suggestion or comment on something after you've reviewed the new code. Ask questions if you don't understand something. If you think the code is wrong, explain why you think so. Remember, the author can't fix it if they don't know what's broken.
+### �外�示：考虑周到
 
-### Final words
+当你在评审完新代���出建议或评论时，�考虑周到，�馈准确，�述详尽。如果有你��解的地方就�出�问。如果你认为代�存在错误，解释你的�由。记�，作者无法修�他�知�的�洞。
 
-The only bad review is no review. By reviewing and voting, you provide your point of view and vote only for that. Nobody expects you to give the final yes or no (unless you're a core maintainer!), but the voting system allows you to provide your perspective and opinion. A patch owner will be glad you did it, trust me.
+### 最�几�
 
-Can you think of any other steps for a good review? Do you have any special technique different from mine? Let us all know in the comments!
+唯一的�评审是没有评审。通过评审和投票，你�供了你的观点并为此�声。没有人指望你��出最终决定（除�你是核心维护者），但是投票系统�许你�供你的观点和��。相信我，补�所有者会很高兴你这么�了的。
+
+你能想到别的�点�给出好的评审�？你是�有我�知�的特殊技巧？在评论中分享它们��
 
 --------------------------------------------------------------------------------
 
@@ -121,7 +123,7 @@ via: https://opensource.com/article/22/10/code-review
 
 作者：[Martin Kopec][a]
 选题：[lkxed][b]
-译者：[译者ID](https://github.com/译者ID)
+译者：[yzuowei](https://github.com/yzuowei)
 校对：[校对者ID](https://github.com/校对者ID)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) �誉推出
@@ -132,3 +134,4 @@ via: https://opensource.com/article/22/10/code-review
 [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