在代码审查/请求请求中寻找什么？

#1 楼

这是我在代码评论中检查的前37条内容
所有代码评论

DRY代码
代码已测试
正在使用棉绒
英语可读代码
行不太复杂
拼写和语法上的错别字
方法简短（<= 5行是理想的）
模拟单元测试的依赖项
类是短（如果可能，请少于100行）
未删除的调试语句
很少的参数，通常不超过两个
未删除的打印调试语句
行不能太长，通常<100-120个字符
安全问题，例如Web窗体中的sql_injection
使用或适当遵循设计模式
好名字（类，方法，变量，常量等）
将通用设置/拆解提取到帮助者之前/之后
>评论。尝试删除或更改方法/对象名称
对于没有部落知识的未来团队成员来说显而易见的代码
日期。确保任何日期计算在所有运行日期上均一致工作


所有自动化代码评论（以及以上所有内容）

存在断言，并且仅需true == true

测试描述语言很有意义，并且在测试实际失败时很有用。
数据。确保不使用真实的个人身份识别数据（PHI / HIPPA / GDPR）
避免使用缩写词和部落知识，除非通用，例如DOB，SSN和ID
所有示例的测试类型标签都应包含以下内容： / sad，可选和特定于域的
提取和DRY的代码通常将抽象级别限制为一或两个级别


UI特定的自动化代码评论（加上所有上述内容）

尽可能使用CSS定位器而不是xpath
将页面对象用于所有用作选择器的DOM元素
使用数据进行搜索的示例使用所需的最少文本
测试主要依靠框架（例如capybara）来处理等待问题
没有静态值固定的睡眠（任何睡眠都使用在系统范围内设置的值）
在轮询等待元素/事件时没有固定的（显式）睡眠
（隐式）可以使用
页面对象足够具体独特但又足够健壮（平衡）
避免使用复杂的数据管理结构，而采用简单的硬编码内联值
避免使用长元素定位符，因为它们易碎，因为它们与当前布局
在可能的ID，类和容器元素优于div和span结构的情况下，
适当地确保存在1个冒烟，1个快乐，多个可悲和0+个可选的测试类型示例

对于请求请求，我还会寻找

变更的紧迫性
其他人在说什么
还有谁批准了公关
如果评论已得到解决
/>代码与业务需求相匹配
PR已经存在了多长时间
根据反馈进行了哪些更改

#2 楼

“应该编写程序供人们阅读，并且只能偶然地使机器执行。”
-Abelson和Sussman撰写的“计算机程序的结构和解释”

UI自动化代码只是另一段“代码”，因此所有代码最佳实践都以相同的方式应用。
如果我必须选择一件事，我会说代码不应该像代码一样读，应该在更高层上像业务域（DSL）中的自然语言一样进行读取（自动化框架中的测试脚本/页面对象公共方法）。
函数内的所有语句应处于相同的抽象级别。 br />示例：

class AddAttendeePage 
  def add_attendee_with_details    
     fill_in('user_email',with:'test@gl.com')
     fill_in('user_first_name', with: 'test')     
     fill_in('user_last_name', with: 'test')
     fill_order_form 
     click_add_attendee
  end    
        
  def fill_order_form
     # ...
  end
  def click_add_attendee
     # ...
  end
end

这里的add_attendee_with_details方法使规则失效。
fill_in(‘order_user_email’, :with => ‘test@gmail.com’)的部分比fill_order_form的部分更详细，因此add_attendee_with_details内的代码在不同的抽象级别上编写。
所有基本的“代码”语义（循环/ if / switch）应深深地埋在框架的最底层。
如果否T，对我来说，这些是最明显的代码味道之一，因为在框架的不同层中代码结构不正确，长期来看，由于多个级别的多种原因，使得代码维护变得很麻烦。

#3 楼

如果没有多本书，则代码复审中覆盖的区域也应包含一本书的章节。首先，请不要忘记测试自动化与软件工程的其他分支没有什么不同，所以让我引用Gergely Orosz（强调我的观点）的一般建议：


好的代码回顾着眼于变化本身以及它如何适应
代码库。他们将通过标题的清晰性和
描述以及更改的“原因”。它们涵盖了代码的正确性，测试范围，功能更改，并确认它们遵循了编码指南和最佳实践。他们将指出明显的改进，例如难以理解代码，不清楚的名称，注释掉的代码，未经测试的代码或未处理的极端情况。他们还会指出何时将太多更改塞进了一次审阅，并建议
将代码更改用于单一目的或将更改分为更多的重点部分。

更好的代码审阅查看较大的系统上下文中的更改，并检查更改是否易于维护。他们
可能会问有关更改的必要性或更改如何影响系统其他部分的问题。他们研究引入的抽象以及它们如何适合现有的软件体系结构。他们注意到可维护性观察，例如可以简化的复杂逻辑，改进了测试结构，消除了重复以及其他可能的改进。工程师Joel
Kemp描述了出色的代码审查，是在进行
初始，轻量级通过之后进行的上下文遍历。


然后有一些特定于测试自动化的事情。代码审查应特别指出：


测试自动化反模式
倒置测试金字塔真的反模式吗？
为什么有一些示例明确说明睡眠语句？不好吗？

我需要引用整个SQA Stackexchange才能使答案完整。

最后，让我们不要忘记代码审查在教育中扮演着重要的角色。这是使新团队成员了解特定于团队和项目的代码准则的好方法。这也是向初级程序员教授编程的好机会（这在测试自动化团队中经常发生）。