无AI编程：一种革命性的新工作方式

许多团队在代码审查上拖延、敷衍或在每个PR上陷入无休止的来回争论。让我们探讨背后的原因。

谬误一 常见误解：代码审查之所以困难是因为它枯燥且PR太长。事实：代码审查困难是因为它重复了编程的认知工作，却缺少所有中间步骤。工程师往往不喜欢审查代码，但这不应被简单地视为工作的一部分，而应探究其原因。

实际上，PR长度并非关键。一些团队发现建立小型PR的规范能加快审查速度、减少精神疲劳，但这并不仅是因为PR变短，而是因为小型PR迫使作者在提交时进行更多的组织和文档说明。例如，一个1000行的理想改动需要拆分为多个200行以下的PR，每个PR必须独立有意义，这要求作者进行更多的“叙事”——解释每个步骤的目的。小型PR易于审查，是因为它们让作者更清晰地逐步解释自己，而缺乏这种解释时，审查者必须费力重构所有推理和上下文，这种抽象猜测游戏可能比实际编写代码更耗费精力。

缩小信息差距有多种方法：将大PR拆分为小PR（可针对功能分支）、提前文档化问题和解决方案、在PR中添加注释解释思路、采用结对编程或群体编程、使用交互式变基等。这些都能让代码审查变得更轻松。

谬误二 常见误解：代码审查的主要目的是阻止不良代码进入应用。事实：代码审查的主要目的是团队对齐。虽然发现错误很重要，但代码审查最核心的价值在于确保团队理解变更内容与原因，并能承诺维护这段代码。对齐≠同意——团队成员可能不同意解决方案，但若对问题有共识，就能承诺推进。其次，代码审查也是一种指导方式，通过评论分享技术、扩大知识面。

这种心态简化了代码审查：审查者的首要任务是理解“是什么”和“为什么”，这可在高层完成；其次是指导和提升；最后才是捕捉错误——这是最困难但最不重要的任务，且与其他角色和工具共享。

谬误三 常见误解：代码审查是软件质量的终极把关。事实：代码审查在作为形式时效果最佳，单独依靠它保护代码库永远不够。PR不应是惊喜，团队应提前知悉即将到来的变更。即使如此，代码作者与审查者之间仍存在知识差距，这种差距由信任填补。信任不是盲目的，但过度怀疑会降低效率。如果代码作者不诚信，再好的审查者也难以阻止代码质量下滑。终极把关取决于问题类型：生产环境bug多需加强QA，功能不符需产品经理改进协作，安全漏洞需做威胁建模或聘请渗透测试员。

谬误四 常见误解：正确进行代码审查能解决很多问题。事实：代码审查对所有有意义的结果都是补充性的，它本身并非足够强大的工具。试想如果代码审查被禁止，团队可能会更多采用结对编程、提前计划、处理技术债务、与QA和产品更紧密协作、加强文档、培训新人、增加自动化测试和静态分析。这些做法比代码审查更有效。代码审查的多功能性是其优点，但也是低效的根源——对大多数问题，都有更高效、更省力的监控方式。找到这些方式是技术领导者的工作。

总之，代码审查可以不必令人筋疲力尽，只要各方尽职：作者提供充分上下文，审查者明确优先级，团队投入有效防护措施。随着流程改进，代码审查将变得更快速、更容易。