工具的供应商非常乐意继续提供这些缺陷跟踪器的新版本，然而要高效地使用缺陷跟踪器，更多的是取决于如何使用好这个工具，而非选择哪一种工具。 很多公司都在设法解决的一个最基本的问题是：如何定义缺陷？缺陷通常是指代码没有遵照规范工作，但是假设我们没有规范或规范很烂，那又会如何？你可以看一下《It’s not a bug, it’s…》获取更多信息。 聪明的公司知道，是否理解缺陷跟踪器的工作方式会带来很大不同，你可以在《Bug Tracker Hell and How to Get Out》中找到更多缺陷跟踪系统的周边知识。 另一个普遍的问题是，公司通常会尝试在缺陷跟踪系统中管理新功能和需求，毕竟无论是需求还是缺陷都会导致代码变动，那么为什么不将所有信息都放到缺陷跟踪器中呢？你可以在《Don’t manage enhancements in the bug tracker》中学到为什么在缺陷跟踪系统中管理需求和新功能是愚蠢的。 版本控制系统
和缺陷控制系统一样，大部分开发人员都将版本控制视为是一个必须的“保健”过程，如果离开它，你就可能换上严重疾病（在最不合适的时间）。
其实，所有的程序员都不喜欢版本控制系统，并且他们会相当直言不讳地指出版本控制系统所不能做到的事情。如果你很不幸，需要拍板最后用哪个版本控制系统，那么就宽慰一下自己吧，你的背后一定会有成群结队的家伙在诅咒你。 版本控制只是个开始，与选择哪个版本控制系统相比，理解如何组织代码、集成持续构建技术、确保缺陷对应正确的版本，这些也同样重要。 敏捷开发支持工具很抱歉，对于Version One和JIRA，至简的真理是，使用敏捷开发工具并不能让你变得敏捷，看这里。 当你真正理解敏捷开发的时候，你才能将这些工具的作用最大化，我有一个最高效的敏捷开发实现仅仅用到了Google Docs而已。 毋庸赘言。 调试器
我已经写了大量的文章，说明为什么调试器不是跟踪缺陷的最好工具，所以这里我会换一种说法！ 在软件工程领域，最经久不衰的比率是1：10：100。也就是说，如果在测试前就能跟踪缺陷（即QA前）的成本为1的话，那么在QA阶段发现缺陷的成本就是10倍，如果在部署的时候被你的客户发现了，成本就是100倍，而大部分调试器在整个过程的10倍至100倍阶段才会被使用。 这并不是说我不喜欢调试器，我只是相信所谓的预先测试消除缺陷策略，因为它的成本很低，又能保证高质量，预先测试消除缺陷策略包括： 规划代码，即PSP 你可以在下面找到更多信息： Defects are for Losers 很少用到的工具 以下这些工具能够带来巨大的不同，但是很多开发人员却不用它们： 自动化单元测试经常在测试驱动开发（TDD）或数据驱动开发中引入，同时伴随着持续开发技术。 |
