现在的软件系统开发难度主要在于其复杂度和规模，客户需求也不再像Winston Royce瀑布模型期望那样在系统编码前完成所有的设计满足用户软件需求。
“整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。”
01
去重
去除重复，在项目中，不可避免的会出现重复代码。但是如果不好好去处理这些重复代码，那很有可能就会给你很多“惊喜”。
从最浅显的层次来看， 相同即是重复。在我们上面的代码中，每一个组件中都有这么一行代码：
如何去重
对于上面这种引入型的代码，类似移动文件，修改文件名这种操作。IDE 就能很好的帮你处理，比如 WebStorm 如果你使用重构相关的功能去重命名，那么它会找出所有 “疑似”引用的代码片段，你可以选择所有相关的引用同时修改。这是一种手段，很好的解决了上面这些问题。
让我们来看看另一个重复代码的问题：
class RequestSender {
static GetBlogList() {
return axios.get('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/list');
}
static Publish(data) {
return axios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/publish', data);
}
static Login(data) {
return axios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/login', data);
}
static Signup(data) {
return axios.post('https://451ece6c-f618-436b-b4a2-517c6b2da400.mock.pstmn.io/signup', data)；
}
这些重复有一部分是语法，有一部分是调用。这些都是不可避免的，因此这些重复代码并不在我们需要重构的范围内。那么，究竟是哪段代码呢？
它并不算是代码。而是“硬编码”，从整体代码上来看，这是目前所有后台接口的域名
在开发过程中，一般来说至少是会有两个环境存在：开发环境、线上环境。而它们两的后台接口域名一般而言又不会重复，难道每次发布前都手动改一下域名么？
我们先来列举一下可能会出现的问题：
开发环境、线上环境域名不一致
团队协作中，开发者之间的开发域名不一致
当线上/开发 环境中的域名需要修改时
可以看到，当遇到上述问题时，项目中所有硬编码了域名的地方都是需要修改的，
最根本的目的是：
保持唯一性
如果有两段/多段代码它们表示的含义完全一致，并且从目的上来说也是一致的。那么就应该尽可能将其只保留一处定义。
那么对于这个域名我们怎么处理呢？首先将其提炼出来：
这样，引用的地方就可以这么写：
这样，当发现修改的时候，是不是只需要修改 Host 这么一个地方就好了呢？、
但是这样还存在问题，如果要发布，或者是在 git 、 svn上协作的时候呢？每个人、每个环境都需要修改这个变量，并且还要在提交代码时移除掉自己的修改以避免冲突。
02
可配置化
Host 的例子是非常常见的，当我们需要发布、团队协作的时候，环境不同是非常常见的，有可能在自己电脑上 Host 是 localhost:8080，换在另一个人电脑上就是 localhost:9099了。那么线上环境有可能又是xxx.xxx.com 、xx.xxx.com/api诸如此类。
解决方案
将与环境相关的硬编码提炼成可配置项放入配置文件
配置文件模板化
配置模板文件多样化
真正的配置文件是不会被提交上去，只有一个模板文件。由于配置文件并不会被提交，所以开发者之间的环境差异就可以忽略了，大家根据自己的环境修改配置文件即可。
那么对于线上环境、测试环境等等，建立对应的配置文件模板即可。当发布时，使用对应环境的发布配置文件模板作为配置文件即可。
新建配置模板文件 config.js.template:
接下来复制粘贴模板文件，并重命名为 config.js:
接下来修改一下 requestSender.js:
好了，现在不管是在任何一个环境下，都可以游刃有余的切换域名了。
03
封装
封装，就是整理。
代码当然需要整理，但是这个整理是需要有合适的方式方法。
这里的 init函数，当这个组件实例被挂载时会被触发。而里面的逻辑是：
向接口发起请求然后将返回值赋给当前组件作用域中的 list 变量
这个地方本身就是一个函数，为什么还需要封装呢？
这里我们暂时只关注一下 init 函数中的代码，这里其实包含了两部分逻辑：
发起 ajax 请求
请求完成后将返回的数据赋值给组件内的变量
上面我们提到的整理一词，为什么要整理呢？因为混乱！我们才会要整理。如果本身就整整齐齐的，那我们为什么需要去整理它呢。
这一段代码中包含了两部分逻辑，它已经有点混乱了，因此我们需要整理它！
关于为什么将其分析为 两部分这一点若羽会在接下来的博文中单独一篇来进行讲解。
那么这里我们如何对其进行封装呢，最简单的办法就是将发起请求的部分封装起来，让 init 函数看不见它，并不知道它干了什么事情。
这里我们在 src 目录下新建一个test.js 文件：
都 0202 年了，我们当然要用上最最最新的语法啊！（就是习惯写后端了呗）
这里我们定义了一个 Test 的类，并且将请求的代码封装到了一个静态函数里。
然后让我们继续重构一下 List.vue中的代码：
此时有没有觉得变得清爽一点呢？很好，清爽了就说明我们的目的达到了一半。
剩下一半就是不爽了~
距离我们成功重构这一小块就差这临门一脚了。
命名的标准很简单，但也很难完全做到：
词对其意，文对其题，码对其逻辑
那么这里我们是用来发送 ajax 请求的，这该怎么起名字？对于这个问题，一百个人里面大概有好多个答案，这里若羽的习惯是对其行为进行命名。因此这里若羽的命名是：
RequestSender ， 请求发送者
函数的命名：
GetBlogList，获取博文列表
让我们来完成这临门一脚：
test.js 重命名为 RequestSender.js，代码：
这里小小的表扬一下 Jetbrains 系列的工具，在 WebStorm 中先点击类名，然后按下 shift + f6 即可享受重命名功能：同时修改文件名及文件中引用的地方。
接下来继续重构一下 List.vue 文件：
