编写代码时如何避免浪费

通往质量的漫长道路充满了曲折、错误的开始和弯路。质量的敌人是浪费，因为浪费从来都不是 desirable 的。没有人会花钱来交付浪费。我们有时会容忍浪费作为制造有用和 desirable 的东西的过程的一部分，但是我们在制造东西的同时越能减少浪费，就越好。

在软件工程中，浪费可以用以下几种方式表达：

1. 缺陷
2. 闲置和等待
3. 过度生产
4. 过度处理
5. 任何其他没有直接将价值传递到用户手中的活动

让我们来检查一下这五种类型的浪费。

缺陷

在软件行业似乎有一种普遍的观点，即错误（缺陷）是不可避免的。不是是否会发生，而是何时以及有多少错误会进入生产环境。

你可以通过提醒软件工程师，每一个错误都是人为编写的来对抗这种失败主义情绪。错误不会自发产生。它们是由我们人类创造的，我们尽最大努力进行软件开发。但没有人是完美的。当然，我们不是故意制造错误，但它们确实会发生。它们通常是赶工的结果，或者可能是由于教育和培训不足。

无论原因如何，错误都是导致的，这意味着我们可以通过解决导致错误的问题来消除错误。

闲置和等待

我们的业务合作伙伴为我们的软件开发工作提供资金，他们倾向于将我们不生产可交付代码的时间视为闲置时间。我们为什么闲置？我们在等待什么？如果考虑到他们可能每小时支付数千美元来维持团队的运转，那么这是一个合理的问题。

闲置是浪费。它对盈利没有贡献，可能是一个混乱的信号。如果团队说他们正在等待某人休假归来，这表明组织技能很差。任何团队都不应该把自己逼到墙角，并且遭受单点故障的困扰。如果团队成员无法参与，其他成员应该介入并继续工作。如果不可能，你正在处理一个非常脆弱、不灵活且不可靠的团队。

当然，团队闲置还有许多其他可能的原因。也许对当前最高优先级存在困惑，因此团队正在等待了解正确的优先级。

还有许多其他的 闲置的合理原因，这就是为什么这种浪费似乎最难解决。无论如何，成熟的组织会采取预防措施，以最大限度地减少潜在的闲置和等待时间。

过度生产

通常被称为“镀金”，过度生产是最隐蔽的浪费形式之一。软件工程师以其热衷于构建功能和精巧功能的倾向而臭名昭著。而且因为软件顾名思义是非常灵活和可延展的，所以对于膨胀的冲击几乎没有反抗。

这种可怕的膨胀会产生大量的浪费。对抗膨胀是谨慎的软件工程学科的全部意义所在。

过度处理

软件工程中最大的问题之一被称为 Geek-At-Keyboard (GAK)。一个常见的误解是软件工程师的大部分时间都花在编写代码上。这与事实相去甚远。除了参加会议之外，大部分时间都花在与编写代码无关的键盘活动上：摆弄配置和环境，手动运行和导航应用程序，键入和重新键入测试数据，单步调试等等。

所有这些活动都是浪费。它们对交付价值没有贡献。减少非生产性 GAK 时间的最有效补救措施之一是 测试驱动开发 (TDD)。在编写代码之前编写测试是避免过度处理的行之有效的方法。先测试方法是消除浪费的一种非常有效的方法。

其他没有将价值传递到用户手中的活动

在我们这个行业的早期，价值是通过单位时间（每天、每周、每月等）产生的代码行数来衡量的。后来，这种衡量价值的相当无效的方式被抛弃，转而支持可工作的代码。代码行数与可工作的代码之间没有令人信服的相关性。一旦可工作的代码成为价值的衡量标准，代码行数就变得无关紧要了。

今天，我们认识到 可工作的代码 也是一个没有意义的指标。仅仅因为代码可以编译、构建和工作，并不意味着它正在做任何有价值的事情。成功运行的代码可能正在进行愚蠢的处理，例如从 0 计数到 10，然后再返回到 0。更重要的是关注满足最终用户期望的代码。

帮助最终用户在使用你的软件产品时实现他们的目标是衡量价值的唯一标准。任何其他没有贡献于该价值的活动都应被视为浪费。