在接手以前的项目做开发的过程中，我们经常会遇到因为既有代码理解困难，导致代码难以删改，问题难以排查的情况。一份富含技术债的代码，不论对于当下的问题解决，还是未来的需求开发，都会形成累赘。因此，本文就分享一些通用的代码优化和治理经验。
首先我们需要从工作的角度去看待代码优化这件事情。需要捋清楚几件事情：
- 当前工作需要研发什么内容？未来可能研发什么内容？
- 历史的代码存在什么问题？有哪些优化的方法？
- 从历史代码到研发的内容，中间我们需要补充什么？是否确实有必要优化历史的代码？
比起为技术而技术地去做代码重构甚至重写，锚定当前的目标，按需优化才是最好的选择。如果历史代码存在比较严重的问题，影响了核心的业务，那么必须强行去做修复，不论代码实现是否符合自己的审美。如果历史代码写的不那么美观，但线上跑的还比较稳定，那么也不建议直接做优化，更多的优先级应该放在新研发的内容上面。
一般我们觉得写的不好的代码，可能存在以下几类问题：
- 命名不规范，没有明确表示代码背后的业务/领域含义
- 没有按最小的粒度做条件判断，理论上无法覆盖所有的corner-case
- 业务流程缺乏拆分，缺乏模块化
- 没有按照语言特性做目录或文件组织
这几类问题都有对应的优化方法。首先命名问题，这个较为好解，了解一段功能的代码实现之前，自己心中要对预期的实现逻辑有数，这样碰到疑似没有说清楚的逻辑，也可以较好推断这些逻辑具体要做什么，当然如果是改命名的话还是建议慢慢改；其次是判断不清问题，主要的关注点是未覆盖的corner-case在线上什么情况下可能复现，风险怎么样，排个优先级去修，不建议一次性全部修完；再者是逻辑拆分问题，推荐是仅当在需要扩充内容的情况下才动既有逻辑，否则如果自己熟悉整个流程的逻辑，不拆也可以；最后是文件组织问题，笔者也经历过一个Golang项目，里面按照python写法来组织go代码，这个问题的解法只能是把新的逻辑放到新的目录，非必要不动旧逻辑。
虽然说代码本身存在问题，理论上必须要优化，但结合项目排期，工作的优先级，不可能说一个项目的代码要每时每刻都尽善尽美。在多人协作的研发场景下，比起写出最美的代码，不如写出足够稳的代码。治理代码问题也是如此，要结合具体的工作情况和代码稳定性做好平衡。