当在软件领域出现了这种复兴运动后，其结果就是我们往往会淡化手艺（craR）、工程和创作之间的界限。另外，在软件开发中，还要去参与了解问题领域（problemdomain）的内容，这就难怪会在工作中把所应关注的问题与其他问题纠缠在一起了。但讨论这些的用意何在呢？
专业的软件从业者，会在多个层次上进行编码、设计、架构、测试、度量和分析。这其中的一些内容，很明显就是工程。进行设计和由他人进行验证也很显然就是工程。但不管怎样切分，编码的行为，就是匠艺的行为，就是做出来的行为。当我们的手指在键盘上敲击的同时，我们或许是在并发地做一些“工程”，但这还是在做一门手艺。
1．2匠艺在首次优质中的作用
匠艺蕴含着技巧。在编码中所使用的技巧，决定着编码的结果。无论对软件做了多少架构、设计或构思的工作，一个差劲的实现就能够破坏掉所有这一切。
作为传统，我们过去会依赖这样的验证，即通过自己的注意力或一个质量保证小组来手工确保软件行为的正确性。一位开发人员曾对笔者说：“我先编写代码，然后再训练它做正确的事情。”虽然他那种最终实现正确性的用意值得称颂，但是此话也表露出他对最初就把产品做好缺乏意愿和关注。当他花了l周时间在一个复杂系统中修改了一些核心代码后，令人哭笑不得的事情发生了，他又要求花3周时间来测试修改的结果。
精益制造是运作在将优质构建到产品中的原则之下的。返工是一种形式的浪费，需要从系统中消除。j而先编写软件以待将来发现bug时再重写或修补，就是返工。
测试那种本应正确的软件，就可以被看作是一种浪费。由于尚未找到创建没有缺陷的软件的方法，所以在编程之后进行测试在一定程度上是必需的。然而，当软件缺陷被发现、修复和重测时，对该软件所做的多于一次的测试显然是低效的。
另一种形式的浪费是库存，可以将其视为机会成本。在修复bug上所花费的时间，也正是该软件中那些被正确编写的部分无法交付给客户或提供商业价值的时间。这个时间同时也是开发人员原本可以做包括职业发展在内的其他有价值的行为的时问。
提升工作中的匠艺水平，能为个人和公司带来成倍的回报。它能令人用更少的时间和更少的浪费，来交付更多的价值，并带来更多的个人满足感。
关于方法的一点看法
首先需要事先声明，笔者是软件开发中敏捷和精益方法的热衷者。然而，笔者也坚信，世界上不存在一个或一组方法，能够适合每个团队、公司、项目或产品的情况。笔者从事过同时使用敏捷和瀑布开发方法的相当标准的软件项目，也把敏捷开发过程嵌入到瀑布式开发过程中，甚至在很大程度上，把敏捷技术运用到涉及实时控制和有关人身安全的产品上，还曾经雄心勃勃地以整个组织转型为目标，把敏捷和精益方法运用到前沿的Web开发上。
无论使用哪种方法，项目中可能都已经有了某种形式的自动化测试，哪怕就是为了省却自己去按下按钮的麻烦。而更有可能的是，为了频繁地运行单元测试、集成测试、系统测试、组件测试、功能测试和其他形式的测试，项目已经拥有了某种形式的持续集成系统。
只要有测试自动化的地方，就会有人编写代码来测试其他的代码。对于这种情况，本书所讨论的技术将会很有用。对于单元测试或隔离测试（iso1ationtesting），本书所讨论的几乎所有技术都适用。而对于更大范围的测试，或许可以选择来运用的技术就会少很多。一些技术只适合于某些编程语言，而其他技术则可被用于几乎任何编程语言或编程范型（progl‘ammingparadigm）。
笔者会提及一些敏捷软件开发中常见的测试方法。即使有些方法不合某些人的开发口味，也不要让这一点成为去尝试它们的拦路虎。无论是实践测试驱动开发、测试先行、尽早测试或者测试后行（testafter），都仍然需要驯服被测代码。祝读者有一个快乐的测试！
……
展开
