为什么需要代码评审

代码评审（Code Review）是指由其他开发人员对已编写的代码进行检查和评估的过程。它是一种重要的软件开发实践，可以帮助开发人员发现和纠正代码中的错误、漏洞和不良实践，并提高代码的质量和可维护性。以下是几个代码评审的重要原因：

提高代码质量：代码评审可以帮助开发人员发现代码中的错误、缺陷和不良实践，并提供改进建议。通过及早发现和修复这些问题，可以提高代码的质量和可靠性，减少后期维护成本。

促进知识共享：在代码评审过程中，开发人员可以了解其他人编写的代码，了解其他人的编码习惯和最佳实践。这有助于促进知识共享和团队合作，提高整个团队的技能水平。

提高安全性：代码评审可以帮助发现潜在的安全漏洞和攻击面，例如 SQL 注入、跨站脚本攻击等。通过及早发现和修复这些漏洞，可以提高应用程序的安全性。

降低风险：代码评审可以帮助开发人员发现和修复潜在的性能问题、可伸缩性问题和可靠性问题，从而降低项目失败的风险。

需要询问的基本问题：

是否应用了项目的格式化风格？
小型任务 - 是否遵循了约定的命名规范？
是否符合DRY原则？
以便日后进行更改 - 代码是否足够“可读”（方法长度等）？
是否所有测试都通过？
代码 - 新功能是否经过了合理的测试？
是否测试了边缘情况？ - 是否尽可能使用单元测试
必要时使用集成测试？
是否存在针对NFR（非功能性需求）的测试，例如性能？

测试需要询问的问题：

是否为新功能编写了合适的文档？
是否涵盖了相关类型的文档：README API文档；用户指南，参考文档等？
文档 - 文档是否容易理解，是否有显著的拼写错误和语法错误？

聚焦于实现需要询问的问题：

审查工作 - 是否满足原始需求？
在这里！语义 - 是否逻辑上正确？

是否没有不必要的复杂性？ - 是否稳健（无并发问题，适当的错误处理等）？是否具有良好的性能？
API语义 - 是否安全（例如，没有SQL注入等）
是否可观察（例如，度量，日志记录，跟踪等）？ - 新添加的依赖项是否有用？它们的许可证是否可接受？

需要询问的问题：

以便日后进行更改 - 尽可能使API尽可能小，但足够大？

是否有一种方式来完成一件事，而不是多种方式？
是否一致，是否遵循最小惊奇原则？ - 是否干净地分离了API/内部，没有内部泄漏到API中？用户界面部分（API类，配置指标，日志格式等）是否存在破坏性更改？ - 新API是否普遍有用且不过于具体？

代码审查金字塔模型

代码审查金字塔-出自bytebytego

代码审查金字塔（Code Review Pyramid）是一种将代码审查分解为不同级别的方法，以便更好地管理和执行代码审查过程。根据不同的代码审查金字塔模型，其级别和内容可能会有所不同。以下是一些常见的代码审查金字塔级别：

工具级别审查：这一级别的审查通常是由自动化工具执行的，例如静态代码分析器和代码格式化工具。这些工具可以检测代码中的语法错误、潜在的漏洞和代码风格问题，并提供改进建议。
代码级别审查：这一级别的审查通常是由其他开发人员执行的，他们将代码与编码标准进行比较，并查找潜在的问题和错误。这些审查通常涉及代码质量、可读性、可维护性和最佳实践等方面。
设计级别审查：这一级别的审查通常由架构师和高级开发人员执行，他们将代码与整体软件设计进行比较，并查找潜在的问题和错误。这些审查通常涉及软件架构、设计模式、性能和可扩展性等方面。
业务级别审查：这一级别的审查通常由业务专家和产品经理执行，他们将代码与业务需求和用户期望进行比较，并查找潜在的问题和错误。这些审查通常涉及功能完整性、用户体验、安全性和法规遵从等方面。

代码审查金字塔是一种将代码审查分解为不同级别的方法，以便更好地管理和执行代码审查过程。根据不同的金字塔模型，其级别和内容可能会有所不同。通常，较低的级别审查会涉及代码质量和可维护性等方面，而较高级别的审查则会涉及软件架构、性能和业务需求等方面。

shell中的代码评审

当进行 Shell 脚本的代码审查时，常见的一些高频问题和代码写法如下：

变量名和注释：变量名应该具有意义，并且应该使用注释来解释脚本的目的和行为。

# 不好的变量名和注释
a="123" # 设置变量a为123
echo $a   # 打印a变量

# 好的变量名和注释
count=123  # 设置计数器为123
echo $count  # 打印计数器

错误处理：脚本应该能够处理错误和异常情况，并在发生错误时提供有用的错误消息。

# 不好的错误处理
grep "pattern" file.txt || echo "grep failed"

# 好的错误处理
if ! grep "pattern" file.txt; then
  echo "grep failed"
  exit 1
fi

命令参数：应该使用合适的命令参数来增强脚本的安全性和可靠性。例如，应该避免使用递归删除文件夹时使用 -rf 参数。

# 不好的命令参数
rm -rf /tmp/*

# 好的命令参数
rm -i /tmp/*

脚本结构：应该使用函数和模块化编程来减少代码的复杂性，并确保脚本结构清晰。

# 不好的脚本结构
for file in *.txt; do
  if [ -f "$file" ]; then
    cat "$file"
  fi
done

# 好的脚本结构
function print_text_file {
  if [ -f "$1" ]; then
    cat "$1"
  fi
}

for file in *.txt; do
  print_text_file "$file"
done

安全性：脚本应该具有安全性，包括避免使用不安全的命令和参数输入检查等来防止潜在的安全漏洞。

# 不好的安全性
eval "$command"

# 好的安全性
"$command"

可靠性：脚本应该具有可靠性，包括处理错误和异常情况，并确保脚本在意外退出时可以进行清理和恢复。

# 不好的可靠性
function cleanup {
  echo "Cleaning up"
}

trap cleanup EXIT

# 好的可靠性
function cleanup {
  echo "Cleaning up"
}

trap cleanup EXIT INT TERM

进行 Shell 脚本的代码审查时，需要关注变量名和注释、错误处理、命令参数、脚本结构、安全性和可靠性等方面，并提供改进建议和最佳实践。

代码审查的一些原则