# 山月教你如何维护自己的测试代码
大家好，我是山月。
在我大学乃至刚毕业的两三年，在本地维护一个文件夹，维护所有的示例代码，用以新技术调研及学习一些新的 API 之类。
然而代码维护不成规矩，很多示例代码杂乱无章，写了之后再不会看第二眼。随着离职，示例代码文件夹被归为无意义且无用的代码一类，被一键格式化了。
今天，我总结下如何更好地维护自己的示例代码，不至于如同鸡肋一样食之无味弃之可惜。
# 分类维护
对于 CSS 一类，可交由在线编辑器 codepen 进行分类维护。
对于 React 与 Vue 一类，随着前端工程化发展，在本地写一个示例显得繁琐与麻烦，此时可交由在线编辑器 codesandbox 进行分类维护。
对于前端一类，在线浏览器仅仅提供存储服务，而代码执行仍在当前浏览器，可以很方便地再浏览器中进行执行与调试。
但 node.js 因与操作系统环境相关，在线编辑器将会把代码推送到他们服务器中的沙盒进行执行，由于安全性问题，一部分功能受到限制，另一方面，由于网路传输，将会有网络延迟的问题。
因此，对于 node.js 此类，可在本地进行维护。
# 本地维护服务端语言的代码示例
- 如何维护文件？
- git
- 目录结构
- 注意添加注释
- 文件如何写？
- 使用块级作用域避免命名冲突
- 使用函数作用域避免命名冲突
# 使用块级作用域
对于一些同步的函数很有用处，如 Buffer 之类
{
// 示例一
}
{
// 示例二
}
{
// 示例三
}
但对于一些异步函数而言，就有乱入的情况出现了。如示例一跑着跑着，突然蹦出来了示例二的输出结果，很容易出现迷惑性。此时可以看下一条
# 使用函数作用域
通过一些函数来构造作用域，并且按照函数分割示例。真实示例可以参照我的 Readable Stream Code (opens new window)
const f1 = () => {}
const f2 = () => {}
const f3 = () => {}
f1()
但是 f1 示例多了，调整顺序再改名字就很难了，那此时应该如何处理？请看以下代码
let f
let run
// 示例一
f = () => {}
// 示例二
f = () => {}
// 在需要运行的示例前
run = f
// 示例三
f = () => {}
run()
最后一定要把代码托管到 Github，比如我的 node-examples (opens new window)。
# 总结
以下大概是我维护的所有代码示例:
- 山月的 codesandbox (opens new window)
- 山月的 codepen (opens new window)
- 山月的 Node Examples (由 Github 托管) (opens new window)
那你们的测试代码是如何维护的，欢迎留言。