《重构 改善既有代码的设计》读书笔记一

两个项目经历

16年年底跟进了一个旧项目的维护工作,由于该项目开发时间较早,各种写法你懂的!在熟悉代码和在跟进某些具体任务时,常常会发现些代码不利于阅读理解和添加新功能,如果只有一两行代码,我就直接改了,但有些较长的代码,由于时间关系希望尽快交付,决定等后面有空了再试试,最终的结果却是一直都没有动。

我最近跟进的一个app项目,其中使用了cordova-plugin-carmea插件来实现拍照和选取手机图片的功能。在对拍照功能添加新的功能时发现在多个地方重复实现,我在修改拍照功能时就不得不在整个项目中搜索该插件的方法,防止有遗漏的。

为何要进行重构

  1. 既有代码不利于理解和修改

为何没能推动重构

  1. 风险,代码已经运行7、8年了,各种资料、测试环境都没有,改动的风险太大
  2. 利益,改动代码需要花费时间、投入人力,但对部门却没有增加收入

关于重构的两种解释

重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本

重构(动词):使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构

重构的目的

使软件更容易被理解和修改

重构的高压线

不改变软件可观察的行为—重构之后软件功能一如既往

重构的前提

需要有一套可靠的测试机制,以此检测我们的改动是否带来了bug

就我个人而言,写单元测试有利于推动后续的重构,否则总有些顾虑而延迟或无法推动重构(但大部分公司还是利益驱动而非质量驱动)

重构的对象

重构的最小单元是执行相同功能的代码段

常用的操作

Extract Method(提炼方法)
Move Method(移动方法)

何时重构

  1. 添加新功能时
  2. 修改错误时
  3. 复审代码时
    对我个人而言,重构的冲动常发生在添加新功能时,当然最理想的是只要代码有重构的需要就进行重构操作

擦掉窗户上的污垢,使你看得更远
我不是个伟大的程序猿,我只是一个有着一些优秀习惯的程序猿
任何一个傻瓜都能写出计算机可以理解的代码,唯有写出人类容易理解的代码,才是优秀的程序猿

你可能感兴趣的:(水滴石穿)