每个系列一本前端好书，帮你轻松学重点。

本系列来自前ThoughtWorks首席科学家马丁福勒所编写的  《重构：改善既有代码的设计》（第二版）

关于烂代码，每个人都有一箩筐的话可说：

• 不知用途的变量
• 无脑复制的方法
• 莫名改变的状态
• 碰一下就出问题的逻辑
• 一不留神就漏改的取值

如果开个吐槽大会，能吐一整天。吐槽这些问题时，我们都会问：这是谁写的？

可能得到如下回复：

1、不是我写的，我也不知道谁写的

2、好像是我写的，但已经很久了，我也忘了

3、当时这样写是因为产品提了一个很“恶心”的需求，既要这样，又要那样

4、当时做的时候只有两种情况

5、是另一个人写的，他已经离职了，没有注释，没有文档

起源

笔者很“幸运”，所在公司常有新产品开发，所以常常创建新项目，新项目没有任何历史包袱，写起来那叫一个爽，想怎么来怎么来，大家都爱。

但经验告诉我，不行，如果真的放任自由，很快它就会变得不干净，多快？两年？一年？不，两个月就够了。

所以，第一优先的事是定项目架构和编码规范，把某类事情要怎么做写清楚，大家都按规矩来。

这样就没问题了？大家是人，不是机器，规范定了要遵守，人的天性就是不受束缚，规范中总有一些规则与个人习惯相冲突，这时候按哪个来？人往往会按自己的来，反正“不会”出事。

久而久之，规范就形同虚设，同项目的小伙伴之间，你写你的，我写我的，遇到问题了，都得互相询问“你这段代码是什么意思，为什么这样写”，人在职还好说，如果不在，只能靠猜。

虽然现在都倾向于组件化、模块化开发，但人与人之间的代码完全没有关联是不可能的，一旦产生关联，就带来了复杂度，如果疏于设计和维护，复杂度只会越来越高。

最终，没有哪个人敢说自己对项目代码完全清楚和有把握。改不敢改，加不好加，即便有问题需要调整和优化，也谨小慎微地进行，一不小心就出线上bug，这显然违背了大家的初衷。

该归责于谁？同事？别人是你的同事，你也是别人的同事，“雪崩的时候没有一片雪花是无辜的”。

解药

可有解药？有，但有前提。

一、开发人员需要具备足够的编码素养，持续学习和更新自己对于好代码的认知，并对自己有高要求，能够写出高可读性、维护性、拓展性的代码。

二、不论水平多高的程序员，面对多变的需求和场景，也不可能一次性把代码写得很完备，调整和修改是开发日常，所以，一个正确的“编程观”是：改代码不是被迫而为之的苦差事，而是保持项目代码健康度所必需做的事。

三、为他人，也是为自己。很多人认为，代码自己写了能解决当下的问题就可以，以后的事先不管，这是不负责任的做法，退一步看，可能以后真的不需要你管了，但别人很可能也是这样想的，你去接手别人的代码时，就会被“坑”，你吐槽别人不好好写，别人也在吐槽你。

识别与行动

我们提倡一次把事情做对，如果不能，就要具备识别错误的能力，也要具备改正错误的能力，更需要把控好改正错误的时机和节奏。

《重构》这本书，就是作者根据自己多年的开发经验，所总结出的一套通用的，可行性强的方法。

如果你是新手，别认为跟你没关系，还记得上面的“两个月”言论？你很快就会和“烂”代码相遇。

如果你是老手，相信已经积累了一些重构的方法和技巧，不妨作为重新的整理和补充。

之所以将本书作为前端开发书籍来解读，是因为在本书的第二版，示例当中采用了JavaScript语言的版本，也是少有的讲通用编程技巧使用JavaScript语言的书籍，这对前端开发者是好事，但使用其他编程语言的程序员也不必担心，本书涉及代码不多，不难懂（想想我们是怎么看那些java代码的吧），其技巧和方法是通用的，所以欢迎大家转发给同样陷在“烂”代码泥潭的同行朋友们。

我们下篇见。

欢迎关注公众号：前端说书匠。好文第一时间接收不迷路！~