一个小小的感悟

最近在看「重构与模式」,这本书最核心的一个观点是“重构产生模式”,意思是通过持续不断的重构,逐渐提高代码质量,以此避免设计不足和过度设计的问题

就观点本身而言没有什么问题,然而在中国大多数的互联网团队中,实践起来会遇到很多难点,以我个人经历而言,一个功能模块从写完那一刻起是什么样的,直到它被抛弃或者重写之前基本不会变,原因是:

  1. 忙着应付业务需求,基本没时间
  2. 就算有时间了还要分配给学习新知识、休息娱乐、社交活动等等,基本没想到去 review 曾经写过的代码
  3. OK 就算有时间 review 了,也不见得能重构出更好的代码(重构是需要很好的嗅觉,以及对设计模式深入理解的)
  4. 就算真的打算重构了,发现根本没有写单元测试,谁也不能保证重构后不会发生灾难
  5. 最根本的一点,在企业里,自上至下很少有人能真正理解重构的意义,我曾经很多次向领导层反映,需要一定的时间周期来偿还技术债务,结果得到的都不是我希望的答案

在如此重重阻碍之下,编写优美的代码这个小小的心愿变得过于理想化,昂贵不切实际,认为重构根本推行不起来

我曾经对此深信不疑,直到我开始读书,我发现了我的一个致命的错误,就是认为代码一定是一开始就是“设计”出来的,认为重新设计一番后,一定可以会更优秀,项目的进步是在无数次毁灭重生中提升的,大错特错!重写只不过是每次犯错后从头再来,愚蠢而且低效,单细胞生物不可能跳过亿万年的进化直接变成人类,写代码亦是如此,大多数伟大的项目并非一人一时之作,持续不断的“演进”,遇到错误及时修正,反复敲打代码,大到架构,小到一个变量的命名,任何点都是可以的改进的,一步一步,不停歇的持续优化,才是真正的重构之道

荀子曰:不积跬步,无以至千里;不积小流,无以成江海,不是一定要“大破大立”才算重构,可能花个5分钟随手就能完成一次简单的重构,这么一想,这项工作也不是那么难

做人又何尝不是这个道理呢