第1章：重构团队协作——代码评审中的重构、任务分解与估算、沟通策略与文化建设
大家好，我是老赵。今天咱们聊聊团队协作中的重构。
很多人觉得重构是技术活，写代码嘛。其实不然。重构更是一个协作活。你想想看，一个团队里，有人想改，有人怕改，有人改了不说，有人说了不改。这怎么玩？
我见过太多团队，代码烂成一锅粥，没人敢动。为什么？不是技术不行，是协作出了问题。今天我就把这几年的经验掰开揉碎，跟你聊聊。
代码评审中的重构
代码评审，说白了就是给代码“体检”。重构呢，就是“治病”。但很多人把评审搞成了“批斗会”。
我个人习惯，在评审中看到需要重构的地方，会先问三个问题：
- 这段代码现在能跑吗？——能跑，说明功能没问题。
- 它容易改吗？——不容易，说明需要重构。
- 改了之后会不会影响别人？——会，那就得小心。
我在项目中遇到过一件事。有个同事提交了一段代码，逻辑没问题，但嵌套了五层if。我一看，头大。但我没直接说“你写得太烂了”。我问他：“如果下个月要加一个新功能，你打算在哪加？”他想了想，自己也笑了。
这就是评审中的重构技巧——不要直接说“改”，而是引导对方自己发现问题。
评审重构的核心原则：
- 先肯定功能，再谈结构
- 用问题代替命令
- 每次评审只聚焦1-2个重构点
- 给出具体的重构建议，而不是空洞的“优化一下”
嗯，这里要注意。评审中不要试图一次改完所有问题。我曾经犯过这个错，一次提了十几个重构建议，结果对方直接崩溃，最后什么都没改。后来我学乖了，一次只说最重要的那个。
重构任务分解与估算
重构最怕什么？怕“一改改三天，改完出bug”。
为什么会这样？因为很多人把重构当成一个“大任务”。大任务意味着高风险、难估算、难验收。
我建议的做法是：把重构拆成小任务。
举个例子。假设你要重构一个订单模块，别想着“重构订单模块”这个任务。拆开：
- 提取订单状态枚举
- 拆分订单创建方法
- 抽取价格计算逻辑
- 统一异常处理
每个小任务，估算时间不超过半天。超过半天的，继续拆。
| 任务 | 估算时间 | 风险等级 | 依赖 |
|---|---|---|---|
| 提取订单状态枚举 | 0.5h | 低 | 无 |
| 拆分订单创建方法 | 2h | 中 | 枚举完成 |
| 抽取价格计算逻辑 | 1.5h | 高 | 无 |
| 统一异常处理 | 1h | 低 | 无 |
你看，这样一拆，每个任务都清晰可控。估算也准了，风险也小了。
我的小技巧：估算时，把实际时间乘以1.5。为什么？因为重构总会遇到意外。我吃过这个亏，说好2小时，结果搞了4小时。从那以后，我学会了“保守估算”。
重构的沟通策略
重构最大的障碍，往往不是技术，而是人。
你想想看，你说“这段代码需要重构”，对方可能觉得你在说他“代码写得烂”。这是人性，没办法。
我总结了一套沟通策略，分享给你：
- 用“我们”代替“你”——“我们这段代码未来可能会遇到问题”，而不是“你这段代码有问题”。
- 用“未来”代替“过去”——“为了以后加功能更方便”，而不是“以前写得不好”。
- 先问需求，再谈重构——“这个功能接下来有什么变化计划吗？”对方说“下个月要加XX”，你顺势说“那我们现在调整一下结构，到时候就方便了”。
我曾经遇到一个团队，技术负责人直接跟组员说“你写的代码太烂了，重写”。结果组员当场辞职。这不是技术问题，这是沟通问题。
避坑指南：千万不要在公开场合批评别人的代码。我曾经在代码评审会上直接说“这段代码设计有问题”，结果那位同事一个月没跟我说话。后来我改成私下说“这块逻辑我有点看不懂，你能给我讲讲吗？”效果完全不一样。
重构的文化建设
文化这东西，听起来虚，其实很实在。
一个团队有没有重构文化，看几个细节就知道了：
- 代码评审时，有没有人主动说“这块我觉得可以重构”？
- 排期时，有没有给重构留时间？
- 重构出bug了，是追责还是复盘？
我见过最好的团队，他们有个规矩：每次迭代，至少留20%的时间做技术改进。包括重构、优化、文档等。刚开始业务方不同意，觉得浪费时间。但半年后，他们的交付速度反而比别的团队快了一倍。
为什么？因为代码质量好了，改bug的时间少了，加功能的速度快了。
文化建设，说白了就是三件事：
- 给时间——别指望用业余时间做重构，那不可能持续。
- 给安全感——重构出问题了，不要追责，要复盘。
- 给榜样——技术负责人带头重构，别光说不练。
我的经验：文化不是喊出来的，是做出来的。你连续三次在评审中提出合理的重构建议，并且帮团队解决了实际问题，大家自然就跟着做了。别着急，慢慢来。
最后，我想说一句。重构不是目的，是手段。我们的目标不是写出“完美的代码”，而是写出“能持续交付的代码”。
好了，这一章就聊到这。记住，重构的起点不是代码，是人。