审代码不是挑错别字
很多人第一次审代码，以为就是找哪里写错了、缩进对不对。其实真正的代码审查，要回答三个完全不同的问题：这段代码能不能跑对、以后好不好改、符不符合团队的规矩。
这三层从下往上，一层比一层抽象，也一层比一层难判断。
第一层：能不能跑对
正确性是地基：逻辑对不对、边界情况有没有处理、异常会不会让程序崩。这一层错了，代码再漂亮也是废的。
def average(nums):
return sum(nums) / len(nums)
# 传进来一个空列表会怎样？
average([]) # ZeroDivisionError！第二、三层：好不好维护、合不合规矩
可维护性关心的是半年后的你和同事：变量名能不能看懂、函数是不是太长、有没有重复代码。代码现在能跑，但读不懂、改不动，就是欠下的债。
团队约定是最上面一层：注释怎么写、文件怎么命名、用不用某个库——这些没有绝对对错，只有「这个团队是这么定的」。
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
代码审查的三个层级，从下到上正确的顺序是？
答案：正确性 → 可维护性 → 团队约定
地基是「能不能跑对」，往上是「好不好维护」，最上层才是「符不符合团队约定」。
「这个函数没处理传入空列表的情况」属于哪一层的问题？
答案：正确性
空列表是典型的边界情况，处理不当会导致程序出错，属于「能不能跑对」的正确性层。
「变量名 `a`、`b`、`tmp2` 满天飞，别人读不懂」属于哪一层？
答案：可维护性
代码能跑，但起名糟糕会让以后改起来很痛苦，属于「好不好维护」这一层。
判断：「团队规定每个公共函数都要写一行文档注释，这段代码没写」——这属于团队约定层。
答案：正确
注释格式这类「团队这么定的」规矩，没有绝对对错，属于团队约定层。
判断：相比「程序跑没跑对」，「这个名字起得清不清楚」更难完全交给机器自动判断。
答案：正确
跑对与否可以用测试自动验证，而命名是否清晰往往需要人结合上下文判断，越往上越难自动化。
代码审查三层中，作为地基、必须最优先保证的是____性。
答案：正确
正确性是地基，代码连跑对都做不到，可维护性和团队约定都无从谈起。