Add simplified Chinese translation #20
Conversation
|
Thanks for drafting the simplified Chinese version, we are more than happy to review it. @gavinbird and I can add comments on the file to point out the places need to be modified and you can decide whether to take our suggestions and do the modification, does it sound good to you? |
|
@poponybing yes, for sure. sounds good to me. |
zh-cn/README.md
Outdated
|
|
||
| 当前包含以下文档： | ||
|
|
||
| * [Google 代码审查指南](review/index.md)，实则两套指南： |
zh-cn/README.md
Outdated
|
|
||
| 文档中使用了 Google 内部术语，在此为外部读者澄清： | ||
|
|
||
| * **CL**：代表“变更列表（changelist）”，表示已提交到版本控制或正在进行代码审查的自包含更改。有的组织会将其称为“变更（change）”或“补丁（patch）”。 |
There was a problem hiding this comment.
我觉得翻译可以更加活泼一些，不必拘泥于诸文逐字的翻译。Google内部的写作风格也是风趣幽默，不会很正式，如果翻译风格能够更加活泼生动会更贴近Google的风格，也更吸引年轻的开发者的阅读兴趣。
比如
“CL就是changelist的缩写， 代表一份已经提交到版本控制或者正在进行代码审查的一段独立式更改。其他的小伙伴们可能管它叫“变更（change）”或“补丁（patch）”。
There was a problem hiding this comment.
很認同生動這點，當時在不了解 Google 內部寫作風格時，比較難以掌握該如何進行翻譯。這邊會將 review comment 的建議稍做修改，讓文句在不脫離原文意思太多的狀況下變得順暢一點!
zh-cn/README.md
Outdated
| 文档中使用了 Google 内部术语，在此为外部读者澄清： | ||
|
|
||
| * **CL**：代表“变更列表（changelist）”，表示已提交到版本控制或正在进行代码审查的自包含更改。有的组织会将其称为“变更（change）”或“补丁（patch）”。 | ||
| * **LGTM**：意思是“我觉得不错（Looks Good to Me）”。这是批准 CL 时代码审查者所说的。 |
There was a problem hiding this comment.
“我觉得不错” -> "我觉得很棒"。 代码审批者说了这句话就代表你的更改被批准了。
|
|
||
| ## Body 是信息丰富的 {#informative} | ||
|
|
||
| 其余描述应该是提供信息的。可能包括对正在解决的问题的简要描述，以及为什么这是最好的方法。如果方法有任何缺点，应该提到它们。如果相关，请包括背景信息，例如错误编号，基准测试结果以及设计文档的链接。 |
There was a problem hiding this comment.
“可能包括” -> "可以包括"
“如果方法有任何缺点” -> “如果这个方法有任何缺点”。
“如果相关。。。” -> “如果有其他相关信息， 请将有关的背景信息例如bug numbers, 测试结果，设计文档的链接写在cl description里面.”
|
|
||
| 其余描述应该是提供信息的。可能包括对正在解决的问题的简要描述，以及为什么这是最好的方法。如果方法有任何缺点，应该提到它们。如果相关，请包括背景信息，例如错误编号，基准测试结果以及设计文档的链接。 | ||
|
|
||
| 如果你包含指向外部资源的链接，可能由于受到保留政策或访问限制影响，让未来的读者无法阅读。因此请尽可能可能包含足够的上下文，以供审阅者和将来的读者理解你的 CL。 |
There was a problem hiding this comment.
“如果你包含指向外部资源的链接，可能由于受到保留政策或访问限制影响，让未来的读者无法阅读”
->
"如果你的description里有指向外部资源的链接，请考虑到这些链接有可能有时效性和访问限制，有些读者可能打不开这些链接"
| - **更简单的回滚。** 大型 CL 更有可能触及在初始 CL 提交和回滚 CL 之间更新的文件，从而使回滚变得复杂（中间的 CL 也可能需要回滚）。 | ||
|
|
||
| 请注意，**审查者可以仅凭 CL 过大而自行决定完全拒绝您的变更。**通常他们会感谢您的贡献，但要求您以某种方式将其 CL 改成一系列较小的变更。在您编写完变更后，或者需要花费大量时间来讨论为什么审查者应该接受您的大变更，这可能需要做很多工作。首先编写小型 CL 更容易。 | ||
|
|
There was a problem hiding this comment.
“在您编写完变更后，或者需要花费大量时间来讨论为什么审查者应该接受您的大变更，这可能需要做很多工作。首先编写小型 CL 更容易。”
->
"一方面，将大CL分离成多个小CL是很麻烦的，另一方面，去说服审查者直接接受你的大CL也会很花时间。 所以从一开始就写小CL会让整个过程简单很多。"
zh-cn/review/developer/small-cls.md
Outdated
|
|
||
| 一般来说，CL 的正确大小是**自包含的变更**。这意味着： | ||
|
|
||
| - CL 进行了一项最小的变更，**只解决了一件事**。通常只是功能的一部分，而不是一个完整的功能。一般来说，因为编写过小的 CL 而犯错也比过大的 CL 犯错要好。与您的审查者讨论以确定可接受的大小。 |
There was a problem hiding this comment.
“与您的审查者讨论以确定可接受的大小”
->
"写之前，您可以和您的审查者一起讨论一下怎样大小的CL最合适"
zh-cn/review/developer/small-cls.md
Outdated
|
|
||
| 在编写大型 CL 之前，请考虑在重构 CL 之前是否可以为更清晰的实现铺平道路。与你的同伴聊聊，看看是否有人想过如何在小型 CL 中实现这些功能。 | ||
|
|
||
| 如果以上的努力都失败了（这应该是非常罕见的），那么请在事先征得审查者的同意后提交大型 CL，以便他们收到有关即将发生的事情的警告。在这种情况下，做好完成审查过程需要很长一段时间的准备，对不引入错误保持警惕，并且在编写测试时要更下功夫。 |
There was a problem hiding this comment.
“以便他们收到有关即将发生的事情的警告”
->
"好让他们提前做好大规模代码变更的心理准备"
|
|
||
| 审查的目标是保持代码库和产品的质量。当审查者对您的代码提出批评时，请将其视为在帮助您、代码库和 Google，而不是对您或您的能力的个人攻击。 | ||
|
|
||
| 有时，审查者会感到沮丧并在评论中表达他们的挫折感。对于审查者来说，这不是一个好习惯，但作为开发人员，您应该为此做好准备。问问自己，“审查者试图与我沟通的建设性意见是什么？”然后像他们实际说的那样操作。 |
There was a problem hiding this comment.
“审查者会感到沮丧并在评论中表达他们的挫折感”
->
"审查者会对你写的代码感到不满, 并在评论中表达了他们的不满"
|
|
||
| ## 修复代码 {#code} | ||
|
|
||
| 如果审查者说他们不了解您的代码中的某些内容，那么您的第一反应应该是澄清代码本身。 如果无法澄清代码，请添加代码注释，以解释代码存在的原因。 只有在想增加的注释看起来毫无意义时，您才能在代码审查工具中进行回复与解释。 |
There was a problem hiding this comment.
“只有在想增加的注释看起来毫无意义时，您才能在代码审查工具中进行回复与解释。”
->
"只有当你觉得用代码注释也很难解释清楚的时候，再用code review tool的评论功能对你自己的代码做进一步的解释"
|
|
||
| 如果审查者说他们不了解您的代码中的某些内容，那么您的第一反应应该是澄清代码本身。 如果无法澄清代码，请添加代码注释，以解释代码存在的原因。 只有在想增加的注释看起来毫无意义时，您才能在代码审查工具中进行回复与解释。 | ||
|
|
||
| 如果审查者不理解您的某些代码，那么代码的未来读者可能也不会理解。在代码审查工具中回复对未来的代码读者没有帮助，但澄清代码或添加代码注释确可以实实在在得帮助他们。 |
There was a problem hiding this comment.
这样做是因为, 如果审查者不理解您的某些代码，那么代码的未来读者可能也不会理解。这些读者大多数情况都只看代码而不是看code review里的评论，所以这些评论对这些读者没有什么帮助，但澄清代码或添加代码注释确可以实实在在得帮助他们
There was a problem hiding this comment.
稍微修正成
这样做是因为, 如果审查者不理解您的某些代码，那么代码的未来读者可能也不会理
解。在 code review tool 中的评论对未来对这些读者没有什么帮助 (因大多数情况读者
可能都只看代码而不是看 code review 里的评论)，但澄清代码或添加代码注释确可以实实
在在得帮助他们
在保持原文下文句下增加解釋說明原文含義
| ## 什么是紧急情况？ {#what} | ||
|
|
||
| 紧急 CL 是这样的**小**更新：允许主要发布继续而不是回滚，修复显着影响用户生产的错误，处理紧迫的法律问题，关闭主要安全漏洞等。 | ||
|
|
There was a problem hiding this comment.
紧急 CL 可以是这样的小更新：能够让产品发布继续进行而不是回滚，能够修好目前在产品里对用户造成严重影响的bug, 能够处理紧迫的法律问题，能够修好重大安全漏洞等。
zh-cn/review/emergencies.md
Outdated
|
|
||
| 紧急 CL 是这样的**小**更新：允许主要发布继续而不是回滚，修复显着影响用户生产的错误，处理紧迫的法律问题，关闭主要安全漏洞等。 | ||
|
|
||
| 在紧急情况下，我们确实关心 Code Review 的整体速度，而不仅仅是响应的速度。仅在这种情况下，审查人员应该更关心审查的速度和代码的正确性（是否解决了紧急情况？）。此外（显然）这类状况的审查应该优先于所有其他 code reivew。 |
There was a problem hiding this comment.
"我们确实关心" -> "我们真正关心的是"
"而不仅仅是响应的速度" -> "而不是单个评论的回复速度"
zh-cn/review/emergencies.md
Outdated
| 需要说明的是，以下情况并非紧急情况： | ||
|
|
||
| - 想要在本周而不是下周推出（除非有一些实际[硬性截止日期](#deadlines)，例如合作伙伴协议）。 | ||
| - 开发人员已经在很长一段时间内完成了一项功能想要获得 CL。 |
There was a problem hiding this comment.
"开发人员已经在很长一段时间内完成了一项功能想要获得 CL。"
->
"开发人员已经在这个feature上努力了很久，他们真的很想把这段代码提交上去"
zh-cn/review/emergencies.md
Outdated
|
|
||
| - 想要在本周而不是下周推出（除非有一些实际[硬性截止日期](#deadlines)，例如合作伙伴协议）。 | ||
| - 开发人员已经在很长一段时间内完成了一项功能想要获得 CL。 | ||
| - 审查者都在另一个时区，目前是夜间或他们已离开现场。 |
zh-cn/review/emergencies.md
Outdated
| - 想要在本周而不是下周推出（除非有一些实际[硬性截止日期](#deadlines)，例如合作伙伴协议）。 | ||
| - 开发人员已经在很长一段时间内完成了一项功能想要获得 CL。 | ||
| - 审查者都在另一个时区，目前是夜间或他们已离开现场。 | ||
| - 现在是星期五，在开发者在过周末之前获得这个 CL 会很棒。 |
zh-cn/review/emergencies.md
Outdated
| - 开发人员已经在很长一段时间内完成了一项功能想要获得 CL。 | ||
| - 审查者都在另一个时区，目前是夜间或他们已离开现场。 | ||
| - 现在是星期五，在开发者在过周末之前获得这个 CL 会很棒。 | ||
| - 今天因为[软（非硬）截止日期](#deadlines)，经理表示必须完成此审核并签入 CL。 |
There was a problem hiding this comment.
“经理说这次代码审查必须完成，这段代码必须要在今天提交，因为今天是一个非硬性的截止日期（soft deadline), 如果是硬性截止日期，cl可以被看作成一个紧急cl”
zh-cn/review/emergencies.md
Outdated
| - 审查者都在另一个时区，目前是夜间或他们已离开现场。 | ||
| - 现在是星期五，在开发者在过周末之前获得这个 CL 会很棒。 | ||
| - 今天因为[软（非硬）截止日期](#deadlines)，经理表示必须完成此审核并签入 CL。 | ||
| - 回滚导致测试失败或构建破坏的 CL。 |
There was a problem hiding this comment.
回滚一个导致测试失败（test failure）或构建破坏(build breakages)的 CL。
zh-cn/review/emergencies.md
Outdated
| - 如果在某个日期之前没有发布，您的产品将在市场上完全失败。 | ||
| - 一些硬件制造商每年只发送一次新硬件。如果您错过了向他们提交代码的截止日期，那么这可能是灾难性的，具体取决于您尝试发布的代码类型。 | ||
|
|
||
| 延迟发布一周并不是灾难性的。错过重要会议可能是灾难性的，但往往不是。 |
There was a problem hiding this comment.
延迟产品发布一周并不是灾难，错过重要会议也不是灾难，毕竟你也不想让你刚刚发布的产品里有严重的bug。
zh-cn/review/emergencies.md
Outdated
|
|
||
| 大多数截止日期都是软截止日期，而非最后期限。软截止日期表示希望在特定时间内完成某项功能。它们很重要，但你不应该以牺牲代码健康为前提来达到。 | ||
|
|
||
| 如果您的发布周期很长（几周），那么在下一个周期之前就可能会牺牲代码审查质量来获取功能。然而，如果重复这种模式，往往会给项目建立压倒性技术债务。如果开发人员在周期结束时经常提交 CL，只需要进行表面评审就必须“进入”，那么团队应该修改其流程，以便在周期的早期发生大的功能变更，并有足够的时间进行良好的审查。 |
There was a problem hiding this comment.
“如果开发人员在周期结束时经常提交 CL，只需要进行表面评审就必须“进入”
->
"如果开发组经常在开发周期快结束时才提交代码，审查者也草率的进行代码审查只为了能让代码赶紧提交"
zh-cn/review/reviewer/comments.md
Outdated
|
|
||
| ## 礼貌 | ||
|
|
||
| 一般而言，对于那些正在被您审查代码的人，除了保持有礼貌且尊重以外，重要的是还要确保您（的评论）是非常清楚且有帮助的。你并不总是必须遵循这种做法，但在说出可能令人不安或有争议的事情时你绝对应该使用它。 例如： |
There was a problem hiding this comment.
“你并不总是必须遵循这种做法，但在说出可能令人不安或有争议的事情时你绝对应该使用它。”
->
"我们不强求每一个审查者每次都遵循以上行为规范， 但您还是要避免说出让人感到不适的评论"
zh-cn/review/reviewer/comments.md
Outdated
|
|
||
| ## 解释为什么{#why} | ||
|
|
||
| 关于上面的“好”示例，您会注意到的一件事是，它可以帮助开发人员理解您发表评论的原因。 并不总是需要您在审查评论中包含此信息，但有时候提供更多解释，对于表明您的意图，您在遵循的最佳实践，或为您建议如何提高代码健康状况是十分恰当的。 |
There was a problem hiding this comment.
“并不总是需要您在审查评论中包含此信息，但有时候提供更多解释，对于表明您的意图，您在遵循的最佳实践，或为您建议如何提高代码健康状况是十分恰当的”
->
"您不必每次都做如此详细的解释，但给代码开发者简要说明一下您的想法，或者告诉他们您正在遵从的最佳实践，或者解释一下您的建议是如何帮助提高代码质量等等，对于开发人员还是很有帮助的。"
zh-cn/review/reviewer/comments.md
Outdated
|
|
||
| **一般来说，修复 CL 是开发人员的责任，而不是审查者。** 您无需为开发人员详细设计解决方案或编写代码。 | ||
|
|
||
| 但这并不意味着审查者应该没有帮助。一般来说，您应该在指出问题和提供直接指导之间取得适当的平衡。指出问题并让开发人员做出决定通常有助于开发人员学习，并使代码审查变得更容易。它还可能产生更好的解决方案，因为开发人员比审查者更接近代码。 |
There was a problem hiding this comment.
“但这并不意味着审查者应该没有帮助” -> "但这并不意味着你可以一点忙也不帮"
There was a problem hiding this comment.
“它还可能产生更好的解决方案”
->
“这样做也有助于开发者想出更好的方案”
|
|
||
| 但这并不意味着审查者应该没有帮助。一般来说，您应该在指出问题和提供直接指导之间取得适当的平衡。指出问题并让开发人员做出决定通常有助于开发人员学习，并使代码审查变得更容易。它还可能产生更好的解决方案，因为开发人员比审查者更接近代码。 | ||
|
|
||
| 但是，有时直接说明，建议甚至代码会更有帮助。代码审查的主要目标是尽可能获得最佳 CL。第二个目标是提高开发人员的技能，以便他们随着时间的推移需要的审查越来越少。 |
There was a problem hiding this comment.
“有时直接说明，建议甚至代码会更有帮助”
->
"有时，明确告诉他们怎么做，甚至直接告诉他们代码怎么改会更有帮助"
zh-cn/review/reviewer/comments.md
Outdated
|
|
||
| 如果您要求开发人员解释一段您不理解的代码，那通常会导致他们**更清楚地重写代码**。偶尔，在代码中添加注释也是一种恰当的响应，只要它不仅仅是解释过于复杂的代码。 | ||
|
|
||
| **仅在代码审查工具中编写的解释对未来的代码阅读者没有帮助。**这仅在少数情况下是可接受的，例如当您查看一个您不熟悉的领域时，开发人员会用来向您解释普通读者已经知道的内容。 |
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| 大多数情况下，我们希望开发者能够很好地测试 CL，以便在审查时代码能够正常工作。但是，作为审查者，仍然应该考虑边缘情况，寻找并发问题，尝试像用户一样思考，并确保您单纯透过阅读方式审查时，代码没有包含任何 bug。 | ||
|
|
||
| 当要检查 CL 的行为会对用户有重大影响时，验证 CL 的变化将变得十分重要。例如 **UI 变更**。当您只是阅读代码时，很难理解某些变更会如何影响用户。如果在 CL 中打 patch 或自行尝试这样的变更太不方便，您可以让开发人员为您提供功能演示。 |
There was a problem hiding this comment.
“当要检查 CL 的行为会对用户有重大影响时，验证 CL 的变化将变得十分重要”
->
"如果您正在审查的这个cl会对用户产生重大影响，那么您就很有必要验证CL的效果"
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| 将要求单元、集成或端到端测试视为应该做的适当变更。通常，除非 CL 处理[紧急情况](../emergencies.md)，否则应在与生产代码相同的 CL 中添加测试。 | ||
|
|
||
| 确保 CL 中的测试正确，合理且有用。测试并非用来测试自己本身，且我们很少为测试编写测试——人类必须确保测试有效。 |
There was a problem hiding this comment.
确保 CL 中写的测试代码是正确的，合理的且有用的。我们不为测试代码写测试，因此每个人都要确保自己写的测试代码是对的。
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| 当代码被破坏时，测试是否真的会失败？ 如果代码发生变化时，它们会开始产生误报吗？ 每个测试都会做出简单而有用的断言吗？ 不同测试方法的测试是否适当分开？ | ||
|
|
||
| 请记住，测试也是必须维护的代码。不要仅仅因为它们不是主二进制文件的一部分而接受测试中的复杂性。 |
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| ## 命名 | ||
|
|
||
| 开发人员是否为所有内容选择了好名字？ 一个好名字应该足够长，可以完全传达项目的内容或作用，但又不会太长，以至于难以阅读。 |
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| ## 注释 | ||
|
|
||
| 开发者是否用可理解的英语撰写了清晰的注释？所有注释都是必要的吗？通常，注释**解释为什么**某些代码存在时很有用，且不应该用来解释某些代码正在做什么。如果代码无法清楚到去解释自己时，那么代码应该变得更简单。有一些例外（正则表达式和复杂算法通常会从解释他们正在做什么事情的注释中获益很多），但大多数注释都是针对代码本身可能无法包含的信息，例如决策背后的推理。 |
There was a problem hiding this comment.
“通常，注释解释为什么某些代码存在时很有用，且不应该用来解释某些代码正在做什么”
->
"注释应该解释这些代码为什么存在，而不应该解释这些代码在做什么"
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| ## 注释 | ||
|
|
||
| 开发者是否用可理解的英语撰写了清晰的注释？所有注释都是必要的吗？通常，注释**解释为什么**某些代码存在时很有用，且不应该用来解释某些代码正在做什么。如果代码无法清楚到去解释自己时，那么代码应该变得更简单。有一些例外（正则表达式和复杂算法通常会从解释他们正在做什么事情的注释中获益很多），但大多数注释都是针对代码本身可能无法包含的信息，例如决策背后的推理。 |
There was a problem hiding this comment.
“正则表达式和复杂算法通常会从解释他们正在做什么事情的注释中获益很多”
->
"如果代码是正则表达式或者复杂算法，那它们的注释应该侧重解释代码在做什么"
There was a problem hiding this comment.
“但大多数注释都是针对代码本身可能无法包含的信息，例如决策背后的推理”
->
"多数情况下，注释应该包含代码本身没法包含的信息，比如这段代码背后的决策推理"
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| 开发者是否用可理解的英语撰写了清晰的注释？所有注释都是必要的吗？通常，注释**解释为什么**某些代码存在时很有用，且不应该用来解释某些代码正在做什么。如果代码无法清楚到去解释自己时，那么代码应该变得更简单。有一些例外（正则表达式和复杂算法通常会从解释他们正在做什么事情的注释中获益很多），但大多数注释都是针对代码本身可能无法包含的信息，例如决策背后的推理。 | ||
|
|
||
| 查看此 CL 之前的注释也很有帮助。 也许有一个 TODO 现在可以删除，一个注释建议不要进行这种改变，等等。 |
There was a problem hiding this comment.
比如之前有一个待办项目（TODO） 现在可以删除，又比如之前有一个注释建议不要进行这种改变
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| 如果您想改进风格指南中没有的一些样式点，请在评论前加上“Nit：”，让开发人员知道这是您认为可改善代码的小瑕疵，但不是强制性的。不要仅根据个人风格偏好阻止提交 CL。 | ||
|
|
||
| CL 的作者不应在主要风格变更中，包括与其他种类的变更。它会使得很难看到 CL 中的变更了什么，使合并和回滚更复杂，并导致其他问题。例如，如果作者想要重新格式化整个文件，让他们只将重新格式化变为一个 CL，其后再发送另一个包含功能变更的 CL。 |
There was a problem hiding this comment.
”CL 的作者不应在主要风格变更中，包括与其他种类的变更“
->
"CL的作者不应该在更改语言风格的同时还包含其他功能性的更改
There was a problem hiding this comment.
“让他们只将重新格式化变为一个 CL，其后再发送另一个包含功能变更的 CL”
->
"他们的CL里只能包含有关语言风格的更改，如果作者还想做功能性的更改的话，再让他创建另一个只包含功能性的更改的CL"
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| ## 上下文 | ||
|
|
||
| 在广泛的上下文下查看 CL 通常很有帮助。通常，代码审查工具只会显示变更的部分的周围的几行。有时您必须查看整个文件以确保变更确实有意义。例如，您可能只看到添加了四行新代码，但是当您查看整个文件时，您会看到这四行是添加在一个 50 行的方法里，现在确实需要将它们分解为更小的方法。 |
There was a problem hiding this comment.
“但是当您查看整个文件时，您会看到这四行是添加在一个 50 行的方法里，现在确实需要将它们分解为更小的方法”
->
"但如果您发现这四行是添加在了一个50行的method里，那么是时候让作者把这个大method拆分些成几个小method了"
zh-cn/review/reviewer/looking-for.md
Outdated
| - 测试精心设计。 | ||
| - 开发人员使用了清晰的名称。 | ||
| - 评论清晰有用，且大多用来解释**为什么**而不是**做什么**。 | ||
| - 代码有适当记录成文件（通常在 g3doc 中）。 |
zh-cn/review/reviewer/looking-for.md
Outdated
| - 代码有适当记录成文件（通常在 g3doc 中）。 | ||
| - 代码符合我们的风格指南。 | ||
|
|
||
| 确保查看您被要求查看的**每一行**代码，查看**上下文**，确保您**提高代码健康状况**，并赞扬开发人员所做的**好事**。 |
There was a problem hiding this comment.
并赞扬开发人员所做的好事
->
并对开发人员所做的可圈可点的地方予以表扬
zh-cn/review/reviewer/looking-for.md
Outdated
|
|
||
| 在整个系统的上下文中考虑 CL 也很有用。 这个 CL 是否改善了系统的代码健康状况，还是使整个系统更复杂，测试更少等等？**不要接受降低系统代码运行状况的 CL**。大多数系统通过许多小的变化而变得复杂，因此防止新变更引入即便很小的复杂性也非常重要。 | ||
|
|
||
| ## 好的事情 {#good_things} |
| 查找作为此 CL “主要”部分的文件。通常，包含大量的逻辑变更的文件就是 CL 的主要部分。先看看这些主要部分。这有助于为 CL 的所有较小部分提供上下文，并且通常可以加速代码审查。如果 CL 太大而无法确定哪些部分是主要部分，请向开发人员询问您应该首先查看的内容，或者要求他们[将 CL 拆分为多个 CL](../developer/small-cls.md)。 | ||
|
|
||
| 如果在该部分发现存在一些主要的设计问题时，即使没有时间立即查看 CL 的其余部分，也应立即留下评论告知此问题。因为事实上，因为该设计问题足够严重的话，继续审查其余部分很可能只是浪费宝贵的时间，因为其他正在审查的程序可能都将无关或消失。 | ||
|
|
There was a problem hiding this comment.
“因为事实上，因为该设计问题足够严重的话，继续审查其余部分很可能只是浪费宝贵的时间，因为其他正在审查的程序可能都将无关或消失。”
->
"因为如果对方的设计有严重问题，那继续审查当前CL的其他部分就是浪费时间，该作者后续的CL也变得无关紧要了"
zh-cn/review/reviewer/speed.md
Outdated
| - 审查者确信开发人员将适当地处理所有审查者的剩余评论。 | ||
| - 其余的更改很小，不必由开发者完成。 | ||
|
|
||
| 如果不清楚的话，审查者应该指定他们想要哪些选项。 |
There was a problem hiding this comment.
审查者应该指定他们想要哪些选项
->
审查者应该说明他们到底想要什么样的更改
zh-cn/review/reviewer/speed.md
Outdated
|
|
||
| 如果有人向您发送了代码审查太大，您不确定何时有时间查看，那么您应该要求开发者[将 CL 拆分为几个较小的 CL](../developer/small-cls.md) 而不是一次审查的一个巨大的 CL。这通常可行，对审查者非常有帮助，即使需要开发人员的额外工作。 | ||
|
|
||
| 如果 CL 无法分解为较小的 CL，并且您没有时间快速查看整个内容，那么至少要对 CL 的整体设计写一些评论并将其发送回开发人员以进行改进。作为审查者，您的目标之一应该在不牺牲代码健康状况的前提下，始终减少开发者能够快速采取某种进一步的操作的阻力。 |
There was a problem hiding this comment.
“始终减少开发者能够快速采取某种进一步的操作的阻力”
->
"不要拖延他们开发进度，尽快让他们能够进行下一步的操作"
zh-cn/review/reviewer/standard.md
Outdated
|
|
||
| 因此，我们将以下规则作为 Code Review 中期望的标准： | ||
|
|
||
| **一般来说，审核人员应该倾向于批准 CL，只要 CL 确实可以提高系统的整体代码健康状态，即使 CL 并不完美。** |
There was a problem hiding this comment.
“一般来说，审核人员应该倾向于批准 CL，只要 CL 确实可以提高系统的整体代码健康状态，即使 CL 并不完美。”
->
总体来说，只要CL真的可以提高系统的整体代码健康状态，即使这个CL并不完美，审查者也应该倾向于批准该CL
| **一般来说，审核人员应该倾向于批准 CL，只要 CL 确实可以提高系统的整体代码健康状态，即使 CL 并不完美。** | ||
|
|
||
| 这是所有 Code Review 指南中的**高级**原则。 | ||
|
|
zh-cn/review/reviewer/standard.md
Outdated
|
|
||
| ## 原则 {#principles} | ||
|
|
||
| * 基于技术事实和数据否决意见和个人偏好。 |
There was a problem hiding this comment.
基于技术事实和数据否决意见和个人偏好
->
基于技术事实和数据高于主观意见和个人偏好
zh-cn/review/reviewer/standard.md
Outdated
| ## 原则 {#principles} | ||
|
|
||
| * 基于技术事实和数据否决意见和个人偏好。 | ||
| * 关于代码风格问题，[风格指南](http://google.github.io/styleguide/)是绝对权威。任何不在风格指南中的纯粹风格点（例如空白等）都是个人偏好的问题。代码风格应该与风格指南中的一致。如果没有以前的风格，请接受作者的风格。 |
zh-cn/review/reviewer/standard.md
Outdated
|
|
||
| * 基于技术事实和数据否决意见和个人偏好。 | ||
| * 关于代码风格问题，[风格指南](http://google.github.io/styleguide/)是绝对权威。任何不在风格指南中的纯粹风格点（例如空白等）都是个人偏好的问题。代码风格应该与风格指南中的一致。如果没有以前的风格，请接受作者的风格。 | ||
| * **软件设计方面几乎不是纯粹的风格或个人偏好问题。**软件设计基于基本原则且应该权衡这些原则，而不仅仅是个人意见。有时候会有多种有效的选择。如果作者可以证明（通过数据或基于可靠的工程原理）该方法同样有效，那么审查者应该接受作者的偏好。否则，就要取决于软件设计的标准原则。 |
There was a problem hiding this comment.
软件设计方面几乎不是纯粹的风格或个人偏好问题
－>
软件设计永远不单单是写作风格或个人偏好的问题
|
I finished the reviews for the current docs, nice translation and thanks again for the efforts. |
|
@poponybing thanks! will submit changes this week. |
|
Hi @poponybing , I've addressed the review comments. Also, I add a new commit that reflects the latest changes in the master branch. Could you also take a look? Thanks for your kindly help. |
Yeah, LGTM, thanks! |
|
you can click here |
|
Thanks for the link, it looks great. |
|
Sent from my BlackBerry 10 smartphone. From: poponybingSent: Monday, 18 May 2020 08:37To: google/eng-practicesReply To: google/eng-practicesCc: Subscribed:Subject: Re: [google/eng-practices] Add simplified Chinese translation (#20)
Thanks for the link, it looks great.
—:You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "#20 (comment)",
"url": "#20 (comment)",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
|
An update: we are looking into how best to incorporate this into the repo such that it fits with the existing, automated syncing process. Stay tuned... |
This is a follow-up PR for #8 that adds the simplified Chinese version of eng-practices.
@poponybing and @gavinbird please have a look.
And thanks to @rootsongjc for helping it.