不要成为您的工具的奴隶

开发人员会Swift附加工具，因为它们是具体的并且行为明确。 学习工具比学习最佳实践或方法要容易得多。 工具只能帮助解决问题，而不能自己解决问题。

了解问题的开发人员可以使用工具来提高生产率和质量。 可怜的开发商不投入时间和精力来了解如何正确的代码，避免缺陷。 他们花时间学习如何使用工具，而不了解工具的目的或如何有效使用工具。

在某种程度上，这部分是工具供应商的错。 该工具厂商认为有机会基于一个共同的问题，如提供支持，使$$$$$：

• 缺陷跟踪器可帮助您管理缺陷跟踪
• 版本控制系统来管理源代码更改
• 支持敏捷开发的工具（第一版，JIRA）
• 调试器可帮助您发现缺陷

这里有很多工具，但是让我们浏览一下这份清单，指出开发人员和组织面临的挑战。 请注意，以下所有统计数据均来自40多年来的15,000多个项目。 ^1个

缺陷追踪器

信不信由你，某些组织仍然没有缺陷跟踪软件。 我遇到了其中一些公司，您不相信为什么。 没有缺陷跟踪系统的影响非常严重，并且有证据证明这一点。

缺陷跟踪方法不足：生产率-15％，质量-21％

因此，我们几乎都同意 需要进行缺陷跟踪。 我们都知道，如果没有某种系统，就不可能管理多个缺陷。

自动化的缺陷跟踪工具：生产率+ 18％，质量+ 26％
问题在于，开发人员不同意什么可能是最好的缺陷跟踪系统。 真正的问题是，几乎每个缺陷跟踪系统的设置都较差，导致结果不佳。 实际上，每个正确配置的缺陷跟踪系统都会带来巨大的好处。 最常见的陷阱是：

• 将不相关的属性引入缺陷生命周期状态，即，创建诸如deferred ， not fixes或按设计功能运行之类的状态
• 无法确定是否已修复某些问题
• 不了解谁负责解决缺陷

工具供应商乐于继续提供新版本的缺陷跟踪器。 但是，有效使用缺陷跟踪器与如何使用该工具而不是选择哪个工具有关。

组织所要解决的最基本问题之一是缺陷 ？ 仅当代码不符合规范时，才存在缺陷。 但是，如果没有规格或规格不好怎么办？ 有关更多信息，请参见这不是错误，而是…… 。

精明的组织知道，使用缺陷跟踪器的方式将带来最大的不同。 在Bug Tracker Hell中发现如何从缺陷跟踪系统中获得更多收益，以及如何离开 。

另一个常见的问题是组织尝试管理缺陷跟踪系统中的增强功能和需求。 毕竟，无论是需求还是缺陷，都会导致代码更改 ，那么为什么不将所有信息放入缺陷跟踪器呢？ 在不管理Bug跟踪器中的增强功能中，了解为什么在缺陷跟踪系统中管理需求和增强功能是愚蠢的。

版本控制系统

像缺陷跟踪系统一样，大多数开发人员都知道版本控制是必需的卫生程序。 如果您没有这种疾病，那么您很可能会染上一种严重的疾病（至少在最方便的时候）。

变更控制不足：生产率-11％，质量-16％
几乎所有开发人员都不喜欢版本控制系统，并且对他们无法使用版本控制系统大声疾呼。 如果您是不幸的人，最终决定使用哪种版本控制系统，那么请了解他们是成群的开发人员 在背后骂你。

版本控制只是故事的第一章。 了解如何有效地对代码进行分块，与连续的构建技术集成以及确保缺陷跟踪器中的缺陷引用正确的版本与选择版本控制系统一样重要。

支持敏捷的工具

对不起版本1和JIRA，一个简单的事实是，使用敏捷工具不会使您敏捷，请参阅此 。
当您真正了解敏捷开发时，这些工具最有效。 我最有效的敏捷实现之一只是在实现中使用了Google文档。

说够了。

调试器

我已经写了很多有关为什么调试器不是跟踪缺陷的最佳主要工具的文章。 因此，我将在这里尝试其他方法！

软件工程中最持久的比率集之一是1：10：100 。 也就是说，如果跟踪缺陷预测试的成本（即在质量检查之前）为1 ，则如果质量检查发现缺陷，则成本为10倍 ，而如果客户在部署中发现缺陷，则成本为100倍 。 当成本函数位于流程的10倍或100倍时，将调用大多数调试器。

并不是我不喜欢调试器-我只是相信使用测试前缺陷消除策略，因为它们成本更低并且可以提高代码质量。 测试前缺陷消除策略包括：

• 计划代码，即PSP
• 测试驱动开发，TDD
• 合同设计（DbC）
• 代码检查
• 配对编程以处理复杂的代码段

您可以在以下位置找到关于此的更多信息：

• 缺陷是给失败者的
• 不为失败者计划
• 调试器适合失败者
• 是调试器拐杖吗

很少使用的工具

工具可能会产生很大的变化，但许多开发人员不使用它们：

• 自动静态分析：生产率+ 21％，质量+ 31％
• 自动化的单元测试：生产率+ 17％，质量+ 24％
  自动化的单元测试通常涉及将测试驱动开发（TDD）或数据驱动开发与连续构建技术一起使用。
• 自动调整功能点大小：生产率+ 17％，质量+ 24％
• 自动化的质量和风险预测：生产率+ 16％，质量+ 23％
• 自动化的测试覆盖率分析：生产率+ 15％，质量+ 21％
• 自动部署支持：生产力+ 15％，质量+ 20％
• 自动圈复杂度计算：生产率+ 15％，质量+ 20％

无需工具的重要技术

软件开发中有许多可用的技术，工具供应商尚未找到一种获利的方法。 这些技术往往会被大多数开发人员所忽略 ，即使它们可以在生产率和质量上产生巨大的差异。

个人软件过程和团队软件过程由Watts Humphrey开发，Watts Humphrey是构建高质量软件的先驱之一。

• 个人软件流程：生产率+ 21％，质量+ 31％ ²
• 团队软件流程：生产力+ 21％，质量+ 31％ ³

检查的重要性涵盖在：

• 检查不是可选的
• 软件专业人员进行检查

• 代码检查：生产率+ 21％，质量+ 31％ ⁴
• 需求检查：生产率+ 18％，质量+ 27％ ⁴
• 正式的测试计划：生产率+ 17％，质量+ 24％
• 功能点分析（IFPUG）：生产率+ 16％，质量+ 22％

结论

肯定有大量的开发人员认为使用工具可以胜任 。

现实情况是，学习工具而不学习解决问题的根本原理就好比假设您拥有出色的跑鞋就能打败出色的迈克尔·乔丹一样。

学习工具不能代替学习如何有效地做某事。

有能力的开发人员正在不断学习能够提高生产率和质量的技术，无论该技术是否受工具支持。

资源资源

• 吉尔伯，汤姆和格雷厄姆，多萝西。 软件检查
• ¹琼斯，雀跃。 评分和评估软件方法，实践和结果 。 2008。
• 琼斯，雀跃。 软件质量经济学 。 2011年
• Radice，Ronald A. 高质量
• ²瓦，汉弗莱。 个人软件过程简介
• ³瓦，汉弗莱。 团队软件流程简介

翻译自: https://www.javacodegeeks.com/2014/06/dont-be-a-slave-to-your-tools.html