重构

image.png

每次重构后都会写比之前更少的代码。或者说,每次重构的目标都应该是 “在完成同样目的的情况下,写更简练的代码”。

我自己的感受就是这样的。需求要赶着上线的时候,没有办法对细节做太多的考虑,就导致不得不在短时间内写出来很多晦涩的代码,只要能 work,可以快速上线赶上 ddl 就行。随着后续维护项目的时间越长,对内部结构更加地了解,这个时候再进行重构的话,应该有信心可以写出来更加干练,简洁的代码才对。

越重构,越精简;可读性越高,健壮性越好。经常在生死磨练的状态下搏斗,人就应该越发敏锐和强大。

PMO 和其他工作里头“只关心结果不关心内容”的角色可能会觉得重构毫无必要。只要需求上线了,能够稳定运行,就说明是“好”的代码;重构反而可能会引入不必要的风险。如果只是为了提高代码质量而进行重构,从项目的角度来说是没有好处,而且反而有隐患的。这么说也确实没错。

所以重构必须要师出有名。《重构》一书里提到的,重构最好的时机,就是在需要在原来的基础上进行新代码编写的时候。要完成新的需求,必须改造旧的代码,这个时候进行重构就最合适不过了。(大意如此,细节记得不大清了)