前言

一年要过去四分之一了,年初定的多看书小目标实现了吗? 最近翻了翻放了很久还买了两本的《重构2》(参考封面图,JavaScript 编写的那本)。随手做了一些小总结和摘录分享一下,希望对大家有帮助。

PART 1 · 章节提炼

第一章

以一个非常普通的 Demo 开始,通过逐步的重构,使代码变得越来越好。不多说,相关 demo 已书写上传至 Github,有需要的同学可以直接点击查看(建议配合原书一起食用)

第二章 - 重构的原则

重构的原则:主要讲解了什么是重构,重构的目的,什么时候重构,什么时候不应该重构之类的问题,具体可见下图。

补图:重构目的中的提升编程速度,有一个「设计耐久性假说」,通过精力改善内部设计,我们增加了软件的耐久性,从而可以更长时间地保持开发的迅速。

另外还有一个关键点,怎么跟经理(客户)说?毕竟这是一个被大多数人认为是不增加价值的无用功。书中的两点建议: 如果经理懂技术,能理解「设计耐久性假说」,那么说明重构的意义应该不会很困难。这样的经理应该会鼓励日常的重构,并主动寻找团队日常重构做得不够的征兆。(虽然“团队做了太多的重构”的情况也的确发生过,但比起做得不够的情况要罕见多了) 如果经理和客户不具备这样的技术意识,会有一个比较有争议性的建议:不要告诉经理。软件开发者都是专业人士,我们的工作就是尽可能的快速创建出高效软件。我领这份工资,是因为我擅长快速实现新功能,我认为最快的方式就是重构,所以我重构。

第三章 - 代码的坏味道

代码的坏味道:通常我们说重构的时候都会伴随着吐槽代码写得不好,那什么是不好的代码呢?我们平时开发的时候应该怎么避免。该书归纳出了 24 条场景供大家参考:

  • 神秘命名、重复代码、过长函数、过长参数列表、全局数据
  • 可变数据、发散式变化、霰弹式修改、依恋情结、数据泥团
  • 基本类型偏执、重复的 Switch、循环语句、冗余的元素(原文冗赘的元素)、夸夸其谈通用性
  • 临时字段、过长的消息链、中间人、内幕交易、过大的类
  • 异曲同工的类、纯数据类、被拒绝的遗赠、注释

对于一些不好理解的词汇具体的定义和解决常见的解决方法可见下图:

就看了三章,后续的总结后续后面再慢慢连载,接下来贴一些个人认为还不错挺有道理的 15 条语句

PART 2 · 摘录

如果你要给程序添加一个特性
但发现代码因缺乏良好的结构
而不易于进行更改
那就先重构那个程序
使其比较容易添加改特性
然后再添加该特性

重构技术就是以微小的步伐修改程序
如果你犯下错误
很容易便可以发现他

傻瓜都能写出计算机可以理解的代码
唯有能写出人类容易理解的代码的
才是优秀的程序员

对于重构过程的性能问题
总体建议是
大多数情况下可以忽略它
如果重构引入了性能损耗
先完成重构
再做性能优化

编程时
需要遵循营地法则
保证你离开时的代码库一定比来时更健康

好代码的检验标准就
是人们是否能轻而易举的修改它

为了保持代码库的健康
就需要时刻留意现状与理想之间的差距
然后通过重构不断接近这个理想

如果有人说
他们的代码在重构的过程中有一两天不可用
基本上可以确定
他们在做的事不是重构

三次法则
第一次做某件事的时候只管去做
第二次做类似的事会产生方案
但无论如何还是可以去做
第三次再做类似的事情
你就应该重构

初步的重构就像扫去窗上的尘埃
使我们得以看到窗外的风景
在研读代码时
重构会引领我获得更高层面的理解
如果知识阅读代码很难有次领悟
有些人以为这些重构只是毫无意义的把玩代码
他们没有意识到
缺少了这些细微的整理
他们就无法看到隐藏在一片混乱背后的机遇

肮脏的代码必须重构
但漂亮的代码也需要很多的重构

每次要修改时
首先令修改很容易
(警告:这件事有时候会很难)
然后再进行这次容易的修改

重构的唯一目的就是让我们开发更快
用更少的工作量创造更大的价值

重构的意义不在于把代码库打磨得闪闪发亮
而是纯粹经济角度出发的考量
我们之所以重构
因为它能让我更快—添加功能更快
修复 bug 更快

大多数人会觉得
有一大笔遗产是件好事
但从程序员的角度来看就不同了
遗留代码往往很复杂
测试又不足
而且最关键的是
是别人写的

PART 3 · 尾

本来想着摘抄类别的文章,应该相对写起来能轻松一点。

然而为了上图摘抄能整得好看点,特意去撸了段代码做了个图片生成的小工具,也真的是应了自我介绍,很能折腾了。