命名
采取描述性名称
命名需要具有描述性，描述性的信息需要覆盖到代码。读者能够见名知意，看到函数名就能推测出函数大概的行为 这样就算是一个有描述性的名字。
名称应与抽象层级相符
名称需要能反映出类或者函数的抽象层级关系。
比如说 有个函数功能是连接调制解调器，大部分情况都是拨号连接 所以可能会取名为getConnectedPhoneNumber(). 这样乍一看没啥问题 但实际上 也有通过线缆值连的情况。 函数功能层级是连接调制解调器，选择连接方式是下一层的层级的事情。 所以更合适的命名是 getConnectedLocator()
尽可能使用标准命名法
比如存在既定约定或者用法，就比较容易理解，比如说模式，或者团队中中命名标准 都属于标准一部分
无歧义的名称
使用不会有歧义的名称。比如说doRename函数里面还有renamePage() 如果不了解业务的话 很难知道有什么区别，所以为了消除这种歧义 如果这个函数被调用的地方不多的话 可以通过取更长的名字的方法优化 比如将doRename 改为 renamePageAndOptionallyAllReferences。
为较大作用范围选用较长的名称
名称的长度应该和作用的广泛度相关。对于较小的作用范围 可以用短的名称，而对于较的作用范围就用长的名称。
比如 i 这种变量名 对于五行以内的情形使用，但是如果函数很长了，就还是取更有含义的名字。比如说rollCount之类的。
（我认为这里作者主要针对的是变量的命名，如果是函数的命名的话 应该按照无歧义的名称原则来，理论上应该是作用范围越小 名字越长）
名称应该说明副作用
副作用指的是函数的其他逻辑作用，比如说作者举得getOos（）例子。这个函数做了非空判断，如果取到就返回取到的值，如果没有就创建一个空的对象，那这里的副作用就是创建新的空对象。这里的函数名应该写作createOrReturnOos()
测试
测试不足
测试应该覆盖所有的范围，所有的代码和情况都应该都被覆盖到。
使用覆盖率工具
覆盖率工具能汇报你测试策略中的缺口。使用覆盖率工具可以快速找到未检测过的if或者catch语句。
（对于前端来说 Jtest 可以一试）
别略过小测试
小测试简单，还能提供文档价值
被忽略的测试就是对不确定的事物的疑问
如果某个需求的细节不确定，可以对测试代码进行注释，这时候也能提醒我们这部分是不确定的。
测试边界条件
不要忘记边界条件的测试
全面测试相近的缺陷
如果一个函数测出来了一个bug，最好对这个函数全面测试。很可能不止一个问题。 （哈哈，这个确实是）
测试失败的模式有启发性
观察一下测试失败的案例，可能会发现其中有一些规律，通过这些规律 可以对定位问题和解决问题会有一定的启发性，所以我们要将测试用例写全面一些。
测试应该快速
如果测试比较慢 就不容易被运行，时间一久 就被抛弃了。所以需要让测试用例执行的快一点。
（整体流程测试时这个确实很重要。而且为了速度 可以只测试一些主流程）
