持续更新中|关于重构的一点简单的思考
当前工作的组内，由于业务开启的时间正好处于集团php-》go技术栈全面迁移的时间点，组内语言技术栈存在：php、go两套。
因此需求开发过程中通常要考虑两套技术栈的逻辑，一些基础的逻辑也没有办法复用。
在这样的背景下，技术栈从php迁移到go这样的重构是一个时不时就会提起的话题。
为什么要重构
一言以蔽之：提高项目后续维护/开发的效率。
随着项目的持续开发，项目复杂度会越来越高，开发效率会越来越低，如下图，而且不仅开发效率越来越低，出bug的概率也越来越大。我们重构的目的就是让图中的的黑色曲线的斜率平缓一些。
我们要明白 重构（refactor） != 重写（rewrite），重写是重构的一个子集，每一次对代码质量提升而产生的修改都可以称之为重构，小到一个函数或者变量的改名。
实践向：怎么进行重构
这里不高谈阔论一些战略，从战术角度来讲述一些方法论。
平时|小型重构
-
重构无论大小，看见能顺手重构的地方就及时顺手重构。这里列出来一些常见的可以顺手重构的地方：
- 函数更改更合适的名字
- 不同逻辑收敛到一个地方统一处理（抽象），比如：不同地方的同样功能的函数，公共枚举值。
- 将“巨型”函数拆成合适的小函数
-
开发过程中就分配时间进行重构：如果不是特别紧急的需求，建议预留10%~20%的时间留给重构工作。
专项大型重构
当项目的架构对开发效率造成了严重的阻碍，此时可以考虑一个专项对项目专门排期进行重构。
- 对重构的顺序按照下面等级排序：（优先考虑价值、其次考虑成本）。
- OKR管理，指定好目标：1.现状整理（到底有哪些技术债）；2.制定好具体目标：收敛哪几个功能能力，收敛配置统一到某个地方等等；3.人员分配和排期。
题外话|荒唐走板
- 写代码的时候注意保护好自己：无论是哪种重构，只要对代码运行可能造成隐患的，都建议通知对应功能的负责人，让其对代码的修改进行cr等工作，防范重构引入的风险。
- 重构不是目的，只是手段：重构代码的目的是为了提高代码质量，提升团队的开发效率。在平时的工作中，团队最好达成共识，一起对代码质量做好监控相关的工作。
