清算AI生成的那些多余代码

寂静回声

大部分时候AI生成的代码都附带着各种各样的注释，给人一种买一斤送一斤赚到的错觉。

注释当然有用，但前提是它是一则好的注释。
程序员写的注释，从心态上来说，注释被大部分程序员拿来当作给代码“擦屁股”的工具——例如这个变量名或者函数名我不知道改如何取，或者这个函数的职责太多以及数过于复杂，再或者我实在没辙了，那我就用注释解释一下吧——在这一类场景下对代码进行重构比写注释更能达到效果。
“写注释”这件事的本质其实是沟通技巧的一种显现，如果这个人平时和同事沟通都费劲那么也别指望着他注释能够写的多好。
更何况注释是一种将技术语言用非技术语言呈现的手段，本身就颇具难度。
要把注释写好也是需要技巧的，试想一下用几句话就把几行代码的用途、上下文解释清楚其实是不简单的。
而程序员更擅长沟通还是写代码？显然是后者。
为什么AI热衷于添加日志，因为本质上它是一种平均意志的体现。
如果用于训练AI模型的代码库总是穿插着各种各样的注释，那么我们又怎么能指望AI生成的代码会完全摒弃注释呢。
AI生成的注释还有另一个风险：注释通常是函数第一次被创建时自动生成的，后续如果有其他开发者接手了代码库的维护工作并修改了实现，可能他会忘记也同时对注释中的内容也进行对应的修改。

AI特别喜欢将交给它重构的代码抽离为静态方法，如果是真正有C#背景的程序员来负责这部分代码的重构，他绝不会选择这样的方式，常见的模式是：
他会创建一个client角色类型的类来封装这部分代码。在编码中client通常承担外部服务的调用职责。例如访问数据库、发送网络请求等等
在实现上述client类时，会遵循“接口”-“实现”的模式。

AI习惯于生成大量的单元测试，简单来说，AI会例举出HttpRequestException衍生出每一种情况并针对性的写出测试。所以会看到了它模拟接口返回404、500、400状态码的情况。但这完全是没有必要的，因为catch代码块里并没有针对不同的状态码给予不同的处理逻辑，生成更多的测试用例既无法减少代码的出错概率，也无法提升各种代码覆盖率。
如果你现在的编码模式已经彻底转变为“AI生成、AI验证、AI修复”这类由AI端到端的交付模式，这其实不算什么坏事。毕竟额外生成的测试也不费成本，测试出错了还是由AI买单，人可以彻底置身事外。但如果在你的开发模式中人依然处于主导地位，那很明显AI生成的测试会加重维护成本——例如程序员需要对AI生成的代码进行review的理解和时间成本就增加了。盲目的追求测试覆盖率会让大量时间花费在小概率事件上，性价比极低。单元测试是一门平衡的艺术，过多的投入是浪费，过少投入会带来风险。

从实现上来说，AI把日志代码封装的非常好，它自动为你在日志语句中注入了类的名称以及调用方法的名。
如此生成出来的日志会让开发者调试代码变得更难，从而违背了日志出现的意义。可以想象如果开发者在线上环境看到PostgresClient Query method called字样的日志输出后，他是无法通过简单的复制粘贴的全局搜索到这条日志所在的代码位置的，因为该日志一个拼接后的结果。他只能将日志按单词拆解，再按照排除法来确认日志究竟是在什么位置出现。