轻量级开发的成功秘诀，第 5 部分: 在保守公司进行敏捷开发

核心提示： 在编码之前不断寻找更简单的解决方案，您想要您的代码复杂性仅仅是您必需的，轻量级开发的成功秘诀，第 5 部分: 在保守公司进行敏捷开发(4)，首先编写测试用例，并且只编写足以让测试用例通过的代码，然后，我们将探讨为特定类型的问题提供极好的生产率的框架，彻底重构和自动化测试如果您致力于简单编码，您的

在编码之前不断寻找更简单的解决方案。您想要您的代码复杂性仅仅是您必需的。

首先编写测试用例，并且只编写足以让测试用例通过的代码。

彻底重构和自动化测试

如果您致力于简单编码，您的简单抽象有时会一下子出现。当出现这种情况时，您需要重构您的代码。但如果您害怕破坏一些东西，您就不愿意重构，尤其是在迭代末尾。重构与自动化测试是携手并进的。

在比较大的公司里，当管理人员发现开发人员正在进行自动化单元测试时，他们通常会阻止。准备好为实践辩护。为此，最好的方法是指出您的测试用例有助于限制您编写的生产代码的数量，允许您在 bug 第一次出现的时候就捕获它们，而且修复 bug 的成本比较便宜（从时间和金钱上来说）。按照我的经验，测试驱动的活动通常与其对应物一样多产。

获得反馈

创建优质产品的一部分是制作您认为您要制作的东西。自动化测试可以帮助您。更为重要的是，质量意味着制作您的客户想要的东西。您必须频繁地从用户那里获得反馈。以下技巧可以帮助您：

每周为您的客户安排演示。为他们展示所有的新功能。

当看不到进展时，用户和管理人员就会受挫。一定要记住，直到您可以在屏幕上看到成果，否则就不算完成。如果您正在制作管道，可以通过用户界面 —— 可能是管理面板 —— 来查看管道。

邀请更高的管理人员来观看您的演示。他们喜欢参与其中，而且，当他们可以看到稳定的进展时，您就有更大的机会让他们站到您这边来。

关注业务需求而非成块的功能，并且将最高优先级的单项特性放在第一位。如果每个编码任务实现有形的业务价值，则可以停止任一点的迭代，并向您的客户交付最重要的特性。

好的反馈不是偶然发生的。而是需要您去询问。

独木舟和皮船

敏捷流程和保守公司未必像油和水（或独木舟和皮船）。为大的保守公司开发软件不一定会将您降到传统流程，您不必声明您在做敏捷或极限编程。您可以通过集成新的敏捷实践来获得巨大的价值。

在本系列后面的几篇文章中。我将向您展示一些 Java™ 技术的备选方法。我们将学习 Java 编程语言本身中可能损害您的生产率的问题。然后，我们将探讨为特定类型的问题提供极好的生产率的框架，比如 Ruby on Rails。