重构代码遇到的坑点（一）

一、修改的代码拥有足够的测试

我得确保即将修改的代码拥有一组可靠的测试。这些测试必不可少。尽量遵循重构手法可以避免绝大多数引入bug的情形，但是我毕竟是人，毕竟有可能犯错。

• 离线测试环境：
• 在线灰度环境：
• 线上回归测试：搭建了kafka落日志进行测试

二、长长的函数：

算法同学喜欢堆叠代码，即使不用的代码也不删。曾经仅仅是在一个结构体删除了一个没有用到的指针，竟然使内存空间节省了近一半。因为这个结构体是模型的一个基础单元。加载模型是内存的消耗大户。

2.1 提炼函数

函数/function对应面向对象语言的方法/method，或者过程/procedure，或者子程序/subroutine。

所需要做的事情就是浏览一段代码，理解其作用，然后将其提炼到一个独立的函数中，并对这段代码的用途为这个函数命名。

2.2 何时将代码放进独立的函数，有很多不同的观点

有的观点认为从代码的长度考虑，有个从复用的角度考虑，认为只要被用过不止一次的代码，就应该单独放进一个函数，只用过一次的代码则保持内联状态（inline）。但这里认为最合理的观点是将“意图和实现分开”。如果需要花时间浏览一段代码才能弄清它到底在干嘛，那么就应该代码提炼在一个函数中。一眼就能看到函数的用途，大多时候不需要关心函数如何达到用途。

一旦接受了这个准则，就养成一个习惯：写非常小的函数，通常只有几行。

有人担心短函数会造成了大量调用影响性能。但其实现代编译器已经非常罕见了，而且短函数更容易地被缓存。