为什么越厉害的程序员，越不喜欢写注释？
在软件测试的日常工作中，我们经常需要阅读甚至调试开发人员提交的代码。一个有趣的现象是：那些架构清晰、bug 极少的高质量模块，往往出自资深程序员之手，但它们的注释却少得“可怜”；反倒是逻辑混乱、需要反复返工的代码，有时会充斥着冗长却无用的注释。于是，测试圈里流传着一个略带调侃的观点：“越厉害的程序员，越不喜欢写注释。”
这个观点是真的吗？如果从软件测试的专业视角来审视，我们会发现，这并非一个简单的态度问题，而是高级开发者在代码抽象能力、设计模式运用以及对“可维护性”的独特理解下，形成的一种工程实践。理解这一现象，对测试人员精准评估质量风险、设计测试策略以及与开发团队高效协作，都具有重要意义。
一、注释的“原罪”：当代码自己会说话
测试人员在执行白盒测试或代码走查时，最头疼的往往不是没有注释，而是注释与代码逻辑不一致。高级程序员深知，注释是代码的“影子”，一旦代码变更而影子未动，就会产生误导。这种误导在测试阶段可能表现为：测试人员基于过时的注释理解业务规则，导致用例设计偏离真实逻辑，从而漏测关键场景。
因此，真正厉害的程序员倾向于让代码本身成为最好的文档。他们通过精准的命名、单一职责的函数、清晰的分层架构，使代码的可读性达到“自解释”的程度。例如，一个方法名为calculateInsurancePremiumWithRegionalDiscount，其意图已经比任何注释都更明确。当测试人员看到这样的代码时，无需翻阅注释就能快速理解业务入口，进而更高效地设计边界值或等价类用例。
从测试视角看，这种“自解释代码”实际上降低了沟通成本。测试人员不再需要追着开发问“这个 if 判断到底想干嘛”，因为代码本身已经给出了答案。这也解释了为什么高级程序员对注释格外“吝啬”——他们追求的是代码与逻辑的绝对同步，而注释很难做到这一点。
二、抽象层次的跃迁：从“怎么做”到“为什么”
普通程序员写注释，往往是在解释“这段代码做了什么”，比如// 循环遍历列表，找到第一个匹配项。但高级程序员关注的是更高维度的抽象，他们只在关键决策点写注释，用来解释“为什么要这么做”，而不是“做了什么”。
对于测试人员而言，理解“为什么”比理解“怎么做”更有价值。例如，在一段复杂的计费逻辑中，如果出现if (userType == 3 && orderAmount > 0.01)这样的条件，没有注释的代码会让测试人员困惑：为什么是 0.01？是防止浮点数精度问题，还是某种业务豁免？而高级程序员留下的注释可能是：“因监管要求，对小微商户的单笔交易免收手续费，0.01 元为系统最小计量单位，用于豁免判断。” 这样的注释直接揭示了业务规则，测试人员可以据此设计出覆盖监管合规性的专项用例，而不是仅仅验证代码分支。
所以，高级程序员并非完全不写注释，而是将注释的“浓度”降到极低，只保留那些无法从代码中直接推导出的业务背景、设计意图或临时权衡。这种“惜字如金”的注释，对测试的价值反而更高，因为它直接指向了测试的薄弱点——业务逻辑的隐含假设。
三、重构与测试的共生：注释是重构的敌人
高级程序员是重构的忠实实践者。他们频繁地通过重构来消除技术债务，保持代码的健康度。而大量的注释会严重阻碍重构：当你重命名一个方法或移动一段逻辑时，相关的注释很容易被遗忘，从而变成“谎言”。为了保持敏捷，他们宁愿删除那些可有可无的注释，只保留经过深思熟虑的少数几条。
从测试的角度看，这其实是一种风险转移。当代码缺乏注释时，测试的自动化回归和契约测试就变得至关重要。高级程序员往往也是测试的坚定支持者，他们会编写充分的单元测试和集成测试来替代注释的功能：测试用例本身就是最好的、可执行的文档。一个完善的测试套件，能够比注释更可靠地描述代码的行为边界。
因此，测试人员在面对“零注释”代码时，不应本能地认为这是质量缺陷，而应首先检查其测试覆盖率和测试用例的可读性。如果一段代码没有注释，但它的单元测试清晰地描述了各种输入输出、异常场景和业务规则，那么这段代码的可维护性其实是相当高的。高级程序员正是通过这种“测试即文档”的实践，将注释的负担转化为了测试资产。
四、协作模式的进化：从“防同事”到“信团队”
初级程序员有时会把注释当作一种“自我保护”的工具，故意把代码写得晦涩难懂，以此增加自己的不可替代性。而高级程序员早已跨越了这个阶段，他们追求的是团队整体的高效协作。他们相信，在代码审查和结对编程的机制下，任何晦涩的代码都会被指出并优化，而不是靠注释来补救。
对于测试人员来说，这种协作模式意味着质量保障的前移。当开发团队推崇代码审查和集体所有制时，测试人员可以更早地介入需求评审和设计讨论，而不必等到代码提交后才从注释中猜测逻辑。高级程序员不喜欢写注释，部分原因正是因为他们更倾向于通过面对面的沟通、设计文档或技术决策记录来传递复杂信息，这些方式比注释更丰富、更及时，也更容易被测试人员吸收并转化为测试策略。
五、测试人员如何应对“零注释”代码？
既然越厉害的程序员越倾向于少写注释，那么测试从业者应该如何调整自己的工作方式？
提升代码阅读能力：将“读代码”作为测试技能的一部分。熟悉常用设计模式、领域驱动设计中的术语，以及团队约定的编码规范。当你能够像开发一样流畅地阅读代码时，注释就不再是必需品。
关注测试用例本身：在代码评审中，将单元测试和集成测试视为最重要的“注释”。检查测试是否覆盖了核心业务场景、边界条件和异常路径。如果测试写得清晰，那么代码的意图就是明确的。
推动活文档文化：与团队一起建立“活文档”意识，即用可执行的规格说明（如 BDD 风格的 Gherkin 文件）或自动化测试来替代静态注释。这些活文档既是测试用例，也是业务需求的可执行版本，永远不会过时。
建立风险对话机制：当遇到既无注释、又无测试、且逻辑复杂的代码时，测试人员应将其识别为高风险区域，并与开发沟通，要求补充必要的解释或重构。这不是对“厉害程序员”的挑战，而是对质量负责的表现。
结语
“越厉害的程序员，越不喜欢写注释”这一现象，本质上反映的是软件工程实践从“手工业”向“工业化”的演进。高级程序员通过提升代码的可读性、用测试替代注释、聚焦于“为什么”而非“做什么”，实现了更高效、更可持续的质量保障。作为测试从业者，我们不应将“零注释”等同于“低质量”，而应理解其背后的工程哲学，并调整我们的测试思维，与开发团队共同构建一种以代码和测试为核心的、动态的文档体系。毕竟，在追求高质量软件的道路上，测试人员与程序员从来都不是对立的，而是同行的伙伴。