开发人员很容易迷恋上工具，因为工具通常比较实用，而且具备明确定义的行为，比起学习最佳实践或方法，学习工具更为简单。然而，工具仅仅为解决问题提供协助，他们并不能自行解决问题。
![]/14004175-eaa991ecfe12f86c.JPG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
一位理解问题实质的开发人员能够使用工具提高生产率和质量，而拙劣的程序员从来不投入时间或精力去理解如何更好的编程和如何避免缺陷，他们会花时间学习如何使用工具，但这种学习方式脱离了对工具目标以及如何高效使用的正确理解。
在某种程度上说，这其中有一部分是工具供应商的错，他们嗅到了为一些普遍问题提供支持是一条财路，比如说：
*缺陷追踪器，帮助你进行缺陷追踪管理
*版本控制系统，管理源代码更改
*敏捷开发支持工具(Version One, JIRA)
*调试器，帮助你寻找缺陷
市面上有很多工具，但在这里我仅仅浏览一下下面的列表，同时指出在哪些地方开发人员和组织正在经受挑战。记住，以下所有的统计数据都来源于40多年间的超过15000个项目。
缺陷跟踪器
一些公司还没有用过缺陷跟踪软件，不管你信不信，我反正是信了，我遇到过这样几个奇葩公司，你一定觉得难以置信吧。没有缺陷跟踪软件的结果是相当杯具的，我们有证据证实。
不充分的缺陷跟踪方法：生产率 -15%，质量 -21%
就此我们达成了高度共识，那就是我们需要进行缺陷跟踪，并且我们都清楚，离开了这类工具，管理大量缺陷是不可能的。
自动化缺陷跟踪工具：生产率 +18%，质量 26%*
先说一个问题，开发人员总是爱争执哪个缺陷跟踪系统最好，这里的根本问题在于，几乎每个缺陷跟踪系统设置不好都会导致糟糕的结果。实际上，如果每个缺陷跟踪系统都能进行合理配置的话，结果都会大有裨益。这里最常见的误区是：
*在缺陷生命周期状态中引入了不相关属性，即创建诸如”延期“, ”无法解决“或 ”已设计的功能“这样的状态。
*无法指出问题是否已被修复。
*无法理解谁负责解决缺陷。
工具的供应商非常乐意继续提供这些缺陷跟踪器的新版本，然而要高效地使用缺陷跟踪器，更多的是取决于如何使用好这个工具，而非选择哪一种工具。
很多公司都在设法解决的一个最基本的问题是：如何定义缺陷？缺陷通常是指代码没有遵照规范工作，但是假设我们没有规范或规范很烂，那又会如何？你可以看一下《It’s not a bug, it’s…》获取更多信息。
聪明的公司知道，是否理解缺陷跟踪器的工作方式会带来很大不同，你可以在《Bug Tracker Hell and How to Get Out》中找到更多缺陷跟踪系统的周边知识。
另一个普遍的问题是，公司通常会尝试在缺陷跟踪系统中管理新功能和需求，毕竟无论是需求还是缺陷都会导致代码变动，那么为什么不将所有信息都放到缺陷跟踪器中呢？你可以在《Don’t manage enhancements in the bug tracker》中学到为什么在缺陷跟踪系统中管理需求和新功能是愚蠢的。
版本控制系统
和缺陷控制系统一样，大部分开发人员都将版本控制视为是一个必须的“保健”过程，如果离开它，你就可能换上严重疾病（在最不合适的时间）。
不充分的变动控制：生产率 -11%，质量 -16%
其实，所有的程序员都不喜欢版本控制系统，并且他们会相当直言不讳地指出版本控制系统所不能做到的事情。如果你很不幸，需要拍板最后用哪个版本控制系统，那么就宽慰一下自己吧，你的背后一定会有成群结队的家伙在诅咒你。
版本控制只是个开始，与选择哪个版本控制系统相比，理解如何组织代码、集成持续构建技术、确保缺陷对应正确的版本，这些也同样重要。
敏捷开发支持工具
很抱歉，对于Version One和JIRA，至简的真理是，使用敏捷开发工具并不能让你变得敏捷，看这里。
当你真正理解敏捷开发的时候，你才能将这些工具的作用最大化，我有一个最高效的敏捷开发实现仅仅用到了Google Docs而已。
毋庸赘言。
调试器
我已经写了大量的文章，说明为什么调试器不是跟踪缺陷的最好工具，所以这里我会换一种说法！
在软件工程领域，最经久不衰的比率是1：10：100。也就是说，如果在测试前就能跟踪缺陷（即QA前）的成本为1的话，那么在QA阶段发现缺陷的成本就是10倍，如果在部署的时候被你的客户发现了，成本就是100倍，而大部分调试器在整个过程的10倍至100倍阶段才会被使用。
这并不是说我不喜欢调试器，我只是相信所谓的预先测试消除缺陷策略，因为它的成本很低，又能保证高质量，预先测试消除缺陷策略包括：
规划代码，即PSP
测试驱动开发，TDD
契约式设计，DbC
代码审查
对复杂代码段进行结对编程
你可以在下面找到更多信息：
Defects are for Losers
Not planning is for Losers
Debuggers are for Losers
Are debuggers crutches
很少用到的工具
以下这些工具能够带来巨大的不同，但是很多开发人员却不用它们：
自动化静态分析：生产率 +21%，质量 +31%
自动化单元测试：生产率 +17%，质量 +24%
自动化单元测试经常在测试驱动开发（TDD）或数据驱动开发中引入，同时伴随着持续开发技术。
自动化功能点分级：生产率 +17%，质量 +24%
自动化质量与风险预测：生产率 +16%，质量 +23%
自动化测试覆盖率分析：生产率 +15%，质量 +21%
自动化部署支持：生产率 +15%，质量 +20%
自动化圈复杂度计算：生产率 +15%，质量 +20%
还没有工具支持的一些重要技术
我们还有一些软件开发的重要技术存在，但是那些工具供应商还没有找到赚钱的方式。这些技术往往被大多数开发人员忽略，即便它们能在生产率和质量上带来巨大改变。
个人软件过程和团队软件过程是由Watts Humphrey建立的，他是致力于构建高质量软件产品的先驱。
个人软件过程：生产率 +21%，质量 +31%
团队软件过程：生产率 +21%，质量 +31%
代码审查的重要性可以在下面两篇文章中找到：
Inspections are not Optional
Software Professionals do Inspections
代码审查：生产率 +21%，质量 +31%
需求审查：生产率 +18%，质量 +27%
正式的测试计划：生产率 +17%，质量 +24%
功能点分析（IFPUG）：生产率 +16%，质量 +22%
总结
肯定是一大群开发人员认为使用工具能够使他们变得更给力。
但现实是，如果你脱离了对所要解决问题的实质的学习，仅仅去学一门工具的话，那就像你觉得你能够在篮球场上赢下乔丹，仅仅因为你拥有一双好的跑鞋。
学习工具并不能取代学习如何把一件事情做好。
真正给力的开发人员会持续学习那些能带来更高生产率和质量的技术，无论这门技术是不是有工具支持。