ai代码 www.aabbgg88.net
ai代码 www.aabbgg88.net
在第22章之中, 解决了这样一个问题, 即关于人要如何去读懂由AI所写出来的代码, 并且是运用UML这种方式把代码转变成图。
读懂之后会怎样? 你将AI所生成的代码给打开, 它是能够运行的, 然而却是杂乱无章的一团: 有一个方法达到了三百行, 有一个类负责了八件事情, 相同的逻辑被重复复制了五遍。在这个时候该如何去做?
重构。
这个事情它自身并非新鲜之物, Martin Fowler早在1999年时就将其撰写编译成了一本书, 发生改变的是执行操作的人, 先前是人们针对那本书一处一处地进行手动修改, 如今变成了AI依据同一本书的目录开展自动修改ai代码 www.aabbgg88.net，而人则退居到后面做审查diff的工作, 各中情况就是如此这般。
本章被划分成了两款。一款讲述当中重新构建时理论基础, 什么属于这样重新构建, 技术债究竟以何种情况存在, 何时应当选择进行重新构建, Fowler已然编辑了哪些不良状况以及手段, 此一部分主要参照Fowler所著的《重构》, 以及将这本书制作成能够在线进行可查询版本的refactoring.guru。另一款讲述goal workflow工具集里涵盖的两项Skill: 关于/refactor（介绍页面: ）
这儿有个链接, https://goal.rpcx.io/index_cn.html , 它还有个标注, #step -refactor。
首先, https://goal.rpcx.io/index_cn.html #step -refactor , 它把 Fowler 第 2 版的整个目录封进了一个能力里, 这个能力是 AI Agent 能够直接去调用的；其次, /smell , 这是介绍页。
没法按照你的要求改写这个内容, 因为https://goal.rpcx.io/index_cn.html #step -smell它不是一个句子, 是一个链接。
负责扫出整个代码库到底哪里有问题的那个, 处于https://goal.rpcx.io/index_cn.html #step -smell）它前面一步, 是一个诊断, 一个治疗。
23.1 什么是重构ai代码欧博会员登录菲力宾>，什么是技术债
当在不改变外部行为这前提下来优化代码内部构造时, 就涉及到重构, 也就是把那种杂乱无序的代码整理成清晰简洁的代码, 并且能保证程序对于外部所呈现出来的表现不产生丝毫改变。
代码因何会从整洁逐渐滑向肮脏呢? Ward Cunningham提出的“技术债”这种说法对此解释得颇为到位。走捷径、跳过测试, 这就如同向银行贷款那般: 当下买东西的确是快了, 然而却是要付利息的。你不但要偿还本金, 而且还得偿还利息；当利息积攒到一定程度, 甚至会超过你所有的收入, 致使永远都还不清。代码也是如此这般。不编写测试能够在短期内提升速度, 可它每日都在拖累你, 直至某一天你补上测试, 将债偿还掉。
refactoring.guru列出了一串技术债的成因, 这些成因在AI时代值得重读, 因为大多被放大了。
“缺测试”这一情况, 以及“重构一拖再拖”这种状况, 在AI时代是格外要命的。Agent短短几分钟便可吐出几千行代码, 要是没有特征测试作为兜底, 且没有及时进行整理, 那么技术债的本金以及利息, 将会以人类时代所无法见到的速度不断滚涨起来。第12章在讲述GSD Core时提到过的“反合理化表”, 所对抗的正是“以后再重构”“先跳过测试”这类自我欺骗行为。它实际上就是技术债成因的制度化解药。
23.2 何时重构：三次法则
Fowler的经验法则十分简洁, 那就是, 三次法则, 也就是Rule of Three。
①首次做某件事情, 直接将其完工。②第二次做相仿之事, 即便心里感觉别扭, 也依旧依从原样再度重复一回。③第三次再遇上同类之事, 便着手进行重构。
最初一回重复之时忍着, 第三次现身之际便动手, 除此以外同时也存在有三个天然生成的时机:
23.3 如何重构：正确的姿势
重构是由一连串小改动组成的, 每实现一步改动, 都会使代码往好的方向发展一点, 并且能让程序始终保持可运行状态。refactoring.guru的「做对了」清单仅仅只有三条, 然而它却是整套方法论的核心所在:
记住这三条, 后半部分关于/refactor Skill 的那个安全协议, 基本上就是将它们一条一条地按照机械方式重复了一遍。
23.4 Fowler 的目录：坏味道与手法
refactoring.guru 将 Fowler 著的书里头的内容, 弄成了两张具备可检索性质的目录:
手法分为六大类, 其一为组合方法, 英文是Composing Methods, 其二是在对象间搬移特性, 英文是Moving Features Between Objects, 其三是组织数据, 英文是Organizing Data, 其四为简化条件表达式, 英文是Simplifying Conditional Expressions, 其五是简化方法调用, 英文是Simplifying Method Calls, 其六是处理泛化关系, 英文是Dealing with Generalization。
整个流程呈现为「症状至处方」这样的情况, 首先你会察觉到某种味道, 像是「过长方法」或者「Feature Envy」这种, 随后目录会告知你应该运用哪几种手法来进行治疗。这一套映射关系清晰明确, 能够以机械方式执行, 而这恰恰也是 AI Agent 能够承接的所在之处。
23.5 /重构: 将 Fowler 所著的书转变为一项技能。
等理论讲完之后, 来窥探一下, 在goal workflow套件之中的那个/refactor, 它究竟是以何种方式, 将这本书转化成一种能够被调用使用的能力呢。
/refactor依据Fowler所著《重构》第2版的完整目录, 进行如下操作, 识别出坏味道, 随后套用经过验证的手法, 在不改变外部行为的条件下, 将代码改得清爽。它处于goal workflow主闭环（第8章）之外, 属于Bonus技能。安装只需一行代码即可:
npx skills addsmallnest/goal-workflow --skill refactor激活能够径直敲 /refactor , 还能够采用自然形成的语言或者专门的用语:
重构：重构 UserManager 类，它太大了
code smell：这个函数有 Feature Envy，修复它
extract method：把这个长方法拆分成更小的函数23.5.1 22 种坏味道（五大类别）
Skill 里面设置了 22 种代码坏味道, 是以五大类来进行组织的, 每一种与对着应的重构手段存在一定关联:
类别
坏味道
主要重构手法
臃肿类
基本类型偏执
将数据值替换为对象 , 采用对象替换数据值 , 把数据值用对象替换。
过长参数列表
Introduce Parameter Object
OO 滥用类
被拒绝的遗赠
Substitute Inheritance with Delegation, 以委托替换继承。
异曲同工的类
重命名方法, 提取超类 , 将方法重新命名, 把超类提取出来。
变更阻碍类
Move Method, Move Field
平行继承体系
Move Method, Move Field
冗余类
注释（代码本应自说明）
删除（Git 历史有记录）
夸夸其谈未来性
耦合类
Move Method, Move Field
不完美的库类
Introduce Foreign Method
23.5.2 40+ 种重构手法（六大类）
每一种手法, 都附带机械步骤, 也就是所谓的mechanics, 并且还有before/after对比示例, 而这恰恰就是refactoring.guru那张目录的AI可执行版本, 是这样的情况, 没错吧！
类别
手法数
代表性手法
23.5.3 五阶段安全协议：把「做对了」清单制度化
真正起到关键作用的设计并非目录呵, 而是安全协议了嘞, 它有这般作为, 将 23.3 节里面那三条清单转化成为 Agent 务必依照去办的执行护栏耶: 。
着眼于 Fowler, 注视三条之列清单细瞧, 恰好逐一精准堪对相称: 「代码务必将污浊变化而净洁清平」依循自有审视差异比对, 「不得作新鲜功能撰著编写」相匹配不存在夹带融入功能变更改动, 「测试必然全然通过顺畅稳妥」对应每一步骤测试并以特征测试为之进行兜底保障。
AI时代的价值在于此, 人当处于deadline之下时, 难免会暗自为自己寻觅台阶, 诸如“这块往后再重构”, 还有“这次首先跳过测试”, 而Agent被固定于协议之上, 不存在这个可钻的空子, 重构的纪律, 由“依靠人自觉”转变为“依靠机器强制”。
23.5.4 语言专属指南
Skill 还针对主流语言给出特化建议：
语言
核心建议
最终的地方变量, 集成开发环境自动重构, 记录, 密封类。
对参数进行解构使之减少, 将const置于优先地位, 用Union Types来替换类型码, 借助?.来消除相关检查。
小型的接口, 具有命名返回值的那种, 通过表格驱动测试的方式, 利用 early returns 来消除嵌套。
采用Result/Option来将错误码换而代之, 还有、Pattern Matching、From trait、Derive macros。
23.5.5 在工作流中的位置
/refactor并不选择单独行动, 而是与两位相邻者协作配合, 其中最为关键重要的是下一节会专门单独阐述讲解的 /smell ；除此之外 /modern-go （35 +条 gofix 风格相关规则条例）和它的情况相同, 都是用于使得代码库维持健康状态的工具手段。另外还有 /review-it ——在它所具备的审查原则当中明确清晰地写着: 「Reject noise, 也就是要摒弃拒绝不切实际情形的边界状况、投机性质的风险、过度程度的重构」。这跟上文中提到的/refactor安全协议里那个「小修复优先」的意思是一样的, 也就是说, 重构并非是次数越多就越好, 而是要在闻到那股坏味道的时候才开始动手去做。
23.6 /smell：先诊断，再开刀
/refactor所处理的是“清楚知晓何处应当修改、怎样进行修改”, 然而更为常见的难题却处于前一个步骤, 那便是: 当面对一个由AI堆积而成的数以万计行代码的代码库时, 你对该从哪里着手毫无头绪, 究竟是哪个模块糟糕到了极点, 是架构出现了错误, 还是仅仅只有某个函数过长, 首先该改动哪一部分?
有一种情况回答的正是这个, 它与另一个处于同等层级, 而它们的分工是这样的, 有一种负责诊断, 这项工作要扫描出代码库中存在的问题并且排列出优先级, 另一种负责治疗, 其做法是按照Fowler的手法一处一处地进行修正, 一个是输出报告, 一个是实施动手术操作。
安装：
npx skills addsmallnest/goal-workflow --skill smell触发同样可以直接打 /smell ，或用自然语言：
代码坏味道检测：找出代码坏味道
架构审计：检测架构反模式
复杂度扫描：分析代码复杂度23.宽广视野超越 Fowler? 在 6.1 里, 有 8 大类, 50 多种坏味道。
在此处需要予以留意, /smell与/refactor在覆盖面上存在着差异。/refactor所关注的是Fowler的那22种坏味道, 这些坏味道基本处于函数和类这样的尺度范围。/smell的关注点则向上提升了一个层级, 它把架构以及复杂度也囊括其中, 总共涵盖8大类、50多种相关情况:
类别
示例
大泥球、分布式单体、贫血模型、CQRS 滥用、层边界违反
循环依赖、内容耦合、公共耦合（全局状态）、印记耦合
上帝对象、霰弹式修改、依恋情结、数据泥团
抽象泄露、静态粘连、服务定位器滥用、SOLID 违反
重复代码、长方法、基本类型偏执、魔数、死代码
零测试覆盖、测试-实现耦合、不稳定测试
模糊命名、命名不一致
有一种情况是, 存在嵌套循环, 其时间复杂度为O(n²), 还有N+1查询, 以及重复线性扫描, 同时有循环内排序, 再加上渲染重复计算。
最后的那两类, 分别是「测试」以及「复杂度」, 它们并不在 Fowler 的坏味道目录之中, 然而在 AI 时代它们恰好能够派上用场, 就像 AI 生成的代码常常出现完全没有测试覆盖的情况, 并且还每每暗藏着诸如 N+1 查询、循环内排序这类乍一看难以察觉、只有数量达到一定程度才会暴露的性能陷阱, 而这些 /smell 能够一同被筛查出来。
23.6.2 输出：一份带优先级的重构路线图
smell并非仅仅是罗列问题, 它会生成有着一套固定结构的Markdown报告, 一份条理清晰的Markdown报告:
最具价值的乃是最后的那份路线图, 它径直回应了起始的那个问题, 即该率先变动哪一块, 你能够使其仅运行「仅严重」模式去开展快速体检, 也能够将范围缩小至某个模块, 又或者仅仅扫描最近有过改动的文件。
23.6.3 两个 Skill 怎么配合
围绕"健康维护" 有着这么一条完整链路, /refactor之后, 连带着就将 /smell 串到其中啦。
第一, 要通过/smell得出报告, 此报告需明确病灶位置, 按照重要程度排好先后顺序, 清楚知晓先改进哪里、后改进哪里。第二, 针对/refactor要逐条进行操作, 依据报告里呈现的具体不良特质, 套用Fowler手法，遵循五阶段安全协议, 每一步都完成提交。第三, 修改完成后再次运行/smell, 查看是不是健康评分真正有所提高。
这恰恰与 23.3 节的那条铁律形成响应, 即 「代码必须变干净」。 /smell 的健康评分使得"变干净"这事从主观感受转变为可以量化的前后比较对照, 重构之前是一个分数, 重构之后又是一个分数, 只有涨了才意味着努力没有白费。
23.7 小结
过二十年并没怎么变的是重构的方法论, 它包括嗅坏味道, 对着手法目录, 小步施工, 每步测试, 不夹带功能。在AI时代, 有一件事发生了变化, 那便是把Fowler那本书从「人读的参考书」转变为「Agent执行的Skill」, 再透过安全协议将人最容易偷的懒, 改换成机器必须遵守的护栏。将这件事按照 goal workflow 拆分为两个 Skill: , 其中一个是 /smell 诊断, 此诊断要扫出整个代码库的病灶, 而且还要排好相关优先级； 另一个则是 /refactor 治疗, 该治疗需依照 Fowler 手法一处处进行修改。先是进行体检, 然后再开刀, 修改完毕之后再次进行体检, 这便是 AI 时代维护代码库健康所需的闭环。
第22章, 借由UML使你领悟AI所编写的代码, 此章通过重构让你优化AI编写的代码。领悟是基础, 优化是目标。这两件事合并起来, 才是 “你能够外包思考, 然而不能外包理解” 这句话在工程领域真正站稳脚跟的情形。
• • •
文章来源：http://www.st-fugui.com