不要成为工具的奴隶

开发人员很容易迷恋上工具，由于工具一般比较实用，并且具有明肯定义的行为，比起学习最佳实践或方法，学习工具更为简单。然而，工具仅仅为解决问题提供协助，他们并不能自行解决问题。

![]/14004175-eaa991ecfe12f86c.JPG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

　　一位理解问题实质的开发人员可以使用工具提升生产率和质量，而拙劣的程序员历来不投入时间或精力去理解如何更好的编程和如何避免缺陷，他们会花时间学习如何使用工具，但这种学习方式脱离了对工具目标以及如何高效使用的正确理解。

　　在某种程度上说，这其中有一部分是工具供应商的错，他们嗅到了为一些广泛问题提供支持是一条财路，好比说：

　　*缺陷追踪器，帮助你进行缺陷追踪管理

　　*版本控制系统，管理源代码更改

　　*敏捷开发支持工具(Version One, JIRA)

　　*调试器，帮助你寻找缺陷

　　市面上有不少工具，但在这里我仅仅浏览一下下面的列表，同时指出在哪些地方开发人员和组织正在经受挑战。记住，如下全部的统计数据都来源于40多年间的超过15000个项目。

　缺陷跟踪器

　　一些公司尚未用过缺陷跟踪软件，无论你信不信，我反正是信了，我遇到过这样几个奇葩公司，你必定以为难以置信吧。没有缺陷跟踪软件的结果是至关杯具的，咱们有证据证明。 欢迎加入全栈开发交流划水交流圈：582735936
面向划水1-3年前端人员
帮助突破划水瓶颈，提高思惟能力

　　不充分的缺陷跟踪方法：生产率 -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%

　总结

　　确定是一大群开发人员认为使用工具可以使他们变得更给力。

　　但现实是，若是你脱离了对所要解决问题的实质的学习，仅仅去学一门工具的话，那就像你以为你可以在篮球场上赢下乔丹，仅仅由于你拥有一双好的跑鞋。
学习工具并不能取代学习如何把一件事情作好。

　　真正给力的开发人员会持续学习那些能带来更高生产率和质量的技术，不管这门技术是否是有工具支持。