《重构:改善既有代码的设计》读后感

重构:改善既有代码的设计

重构:改善既有代码的设计

作为一名以面向过程为主的开发人员,翻看《重构:改善既有代码的设计》的过程中总想去查阅一下《设计模式:可复用面向对象软件的基础》,因为书中提到了太多次的 Gang of Four GoF,很多重构方法都是利用了面向对象的基本特性,或封装,或继承,或多态。

确切地说,如果熟知 GoF,在设计实现代码时可能就已经避免了一些书中提到的坏味道;对已有代码做重构时,或添加新功能迭代开发时,可能就会顺其自然地使用书中总结的一些重构方法,即使不曾意识到这一点。所以,重构代码更多地依赖开发人员对面向对象的理解。当然,对于面向过程编程来说,本书也有很大的参考价值,在很多地方上思想或者思维方式是相通相似的。

书中提到的重构方法很多都是互斥的,比如有的重构方法需要合并参数/函数,而下一个重构方法就是拆分参数/类……虽然每个重构方法都解释了何时何地需要这种方法,但可能更多地是需要在实际开发/重构过程中慢慢体会,什么时候需要合并类,什么地方需要拆分……

在本书的末尾说到重构面临的阻力,这是很现实的问题,估计没有哪一个产品经历/项目经理/老板/甲方会说“给你们三年时间重构这个系统”,在当前环境下,可以在添加新功能,改进模块时慢慢地,逐步地重构一部分代码;改的多了,重构的多了,下次概要设计时就会避开更多的坏味道,只能是一个循序渐进的过程。

幸运地是,我在刚参加工作时参与了一个较大的重构项目,负责其中一个小功能的维护开发工作,在此分享一下。

当时公司有十几条产品线,不同的产品线面向不同的应用场景/领域,但底层的操作系统和基础功能都是类似的,都是使用Linux内核,都需要内存管理/锁机制/路由管理等基础功能;每个产品线都各自维护自己的操作系统和基础功能,造成了资源浪费,虽然公司内部知识共享,但总会出现bug修订不同步不及时的情况。因此组建新的部门——基础平台部,专门负责操作系统和基础功能的维护开发工作,并尝试把各产品中很成熟的模块/功能移植到基础平台中;该基础平台测试稳定后再慢慢向产品线推广使用,新产品线则优先选择使用该基础平台。

重构/移植的过程涉及了x86、mips等平台的差异性,Linux内核版本不一致,需要从杂糅的业务逻辑中摘出模块的基本功能,并提供简单易用的对外接口。但这不是最费心的事情(估计“废”了大牛们的心),最费心最麻烦的是基础平台的推广,基础模块功能的推广,我负责的模块的推广 Σ( ° △ °|||)︴

当时有一个产品线已经基本完全迁移到了基础平台(提供了Linux内核,内存管理、锁处理等),当我去试图推广我的小功能时受到了较大的阻力:

  • 我的部门经理的敦促
  • 该产品线负责此功能测试的人员:本来已经稳定不需要测试的东西还要再测,你看还有问题
  • 该产品线的产品经理的询问
  • 因为该功能原本已经稳定,所以没有专人负责了;我去推广,然后我就成了该功能的负责人:需要处理客户反馈的bug

再深入下去就是项目管理方面的东西了,按下不表;接着说重构。当初公司专门调出几个人来做基础平台,做重构/移植,确实是明智之举,后期也不断得到了印证;有时候我会收到产品线部门同事的QQ,咨询某个功能的使用/测试方法,也有同事夸我们做的基础平台用起来很方便。

最后,希望世界和平,没有 bug

如无特殊说明,文章均为本站原创,转载请注明出处
源自: 王明军的博客
本文链接地址: 《重构:改善既有代码的设计》读后感
广告

2 replies

发表评论

This site uses Akismet to reduce spam. Learn how your comment data is processed.