感谢《持续交付2.0》的粉丝 冯俊晨 帮助审校本文。
往期链接：
本期要点：
1. 减少嵌套，降低复杂度
2. 互相尊重的CR，才是有用的CR
本文内容译自谷歌测试博客
https://testing.googleblog.com/
∎ 1 ∎
减少嵌套，降低复杂度
嵌套过深的代码，对可读性是一种伤害，而且代码也容易出Bug。
请在下面两个版本的代码中试着找一找bug：
答案："wrong encoding"和"unauthorized" 这两个Error Message写反了。
在重构后的版本中，这个bug更容易被发现，因为代码中，直接进行检查后就可以处理Error了。
上面展示的重构技术被称为 卫语句。通过“卫语句”来检查某一条件，如果不满足就直接快速失败。
卫语句将核心计算逻辑与合法性检查逻辑分离了。
它通过消除错误检查和处理之间的认知差距，它释放了工程师在读写代码时的认知负担。
这个重构后的版本更容易读懂，也更容易维护。
下面是一些减少嵌套代码的原则:
尽量让条件语句块短小。将内容限制在局部，有利于增加可读性。
当循环或分支超过两层深度时，就要考虑重构它了。
可以将嵌套逻辑抽取到另一个函数中
假如你需要从一个列表中取出每一个元素，而每个元素又都是一个列表（例如，一个协议缓冲区中还有重复的字段），你就可以定义一个函数来处理每个对象，而不是使用双嵌套循环。
减少嵌套会使代码更易读，从而更容易发现可能存在的错误，更快的开发迭代，以及更高的稳定性。只要允许，就进行简化！
∎ 2 ∎
互相尊重的CR，才是有用的CR
虽然代码评审被认为是提高软件项目质量的一个有价值的工具。
但是，如果反馈评论被认为描述不清晰，或者是过于苛刻，都可能会产生不良后果，如：慢吞吞的评审、被阻滞的代码评审，负面情绪，或其他贡献者或同事的负面看法。
请考虑以下这些技巧，以相互尊重的方式代码评论。
作为评审人或代码作者
应当：假设有能力。一个作者的实现或者一个评论者的推荐可能是由于另一方与你有不同的背景。先问问题以获得理解。
应当：提供基本原理或上下文，如最佳实践文档、样式指南或设计文档。这可以帮助其他人理解你的决定或提供指导。
应当：考虑如何解释评论。要注意不同的方式，夸张的笑话和情绪化可能被感知。
不应当：批评或指责个人。相反，要就代码进行讨论。甚至，在评论中由于指代具体人（例如，由于使用了“you”或“your”）也会偏离改进代码的目标。
不应当：用过于严厉的语言。带有否定和反问语气的代码评论不太可能有什么好作用。例如，先前的研究发现，57%的作者认为非常负面的评论是有用的，而79%的作者认为更中性的评论是有用的。
作为评审人
应当：提供具体可行的反馈。如果你没有具体的建议，有时询问作者为什么做出决定是有益的。
应当：使用前缀（如“Nit”或“optional”）清楚地标记“”nitpick和“可选”的注解。这使作者能够更好地评估评审人的期望。
作为作者
应当：在回复反馈时，要对代码目的进行澄清，或回复评审人提出的意见。如果不这样做，可能让人觉得缺乏对实现代码改进的意愿和能力。
（未完待续）
