不要轻易重构

在项目维护的过程中,由于工程师水平的参差不齐,很多需求时间紧、任务重,或又因前几任工程师离职没做好交接,导致了大量的可读性差、效率低下的代码,这时候,在职的工程师最想做的恐怕就是重构代码,将那些垃圾代码舍弃,按照自己良好的设计重新实现一遍。

在工程师看来,重构之后有非常多的好处:

  1. 代码更简洁,可读性、可维护性更强
  2. 实现新的需求效率更高
  3. 新人的学习成本更低

重构之后丢弃了过往的累赘,往往也会丢弃了过往的经验。尽管过去的代码十分丑陋,但它们确确实实可以正常地运转。如果要重构,能保证新的代码不会像过去团队的代码一样,慢慢变丑陋吗?依然会面临同样的风险,而且,过去团队已经付出的时间成本,还要再次付出一遍。

我所负责的项目就经历过这样一次重构,带来好处的同时也带来了很多伤害,主要有以下几点:

1. 用户很长时间看不到产品的变化,容易对产品失去信心

按照原本的开发计划,团队每周会响应客户反馈的 2 个改进意见,修正 4+ 个 bug,约两个月推出一个重点功能…用户每周都能感受到产品在改进,这会让用户更加喜爱你的产品,重构意味着舍弃了正常进度的产品更新,而需要花大量的时间来重新组织代码,而这所有改进,用户完全感知不到,一旦在某些功能上落后于竞争对手,可能就直接导致用户流失。

2. 以前遇到的坑基本会再踩一遍

工程师往往会低估重构的难度和所要消耗的时间,以前遇到的坑基本会再踩一遍。比如,在过去的版本中,导出的数据是带有公司 logo 和精美样式的 EXCEL 文件,重构时就没有考虑到这一点,结果又花了大量的时间去调整导出文件的样式。

为实现某个特殊需求,旧版写了很多丑陋的代码,在重构的时候,依然没有想到优雅的办法,但是用户已经严重依赖这个功能,又必须实现,后来重构的版本依然通过非常别扭的方案实现这个需求。

3. 技术上没有包袱了,但产品上的包袱更重

如果重构涉及到前端用户看到的部分,则面临的压力会更大。在过去的版本中,用户体验被打磨的非常细致,甚至很多你想不到的地方都被用户熟练掌握,一旦交互上有稍微大的改动,就会影响到他们的正常使用。

重构的版本还很难使用敏捷的方式快速迭代,一旦推出了新版的最小可行化版本,用户会吐槽比旧版差远了,为啥要用这个,如果要测试成熟再推出,用户等待的时间则会更加漫长。

4. 竞争对手利用这段时间可能已经走很远了

在重构的这段时间,你的竞争对手在马不停蹄的开发新的功能,拓展新的客户,而自己的产品对于客户来说却停滞不前。在重构之前,一定不能只从工程角度考虑问题,还要想想公司的生意。



不要轻易重构》上有3条评论

评论已关闭。