充满激情的程序员的性格特征(traits)

在开始讨论行为设计模式之前，我们先来谈谈作为开发人员的行为。在本书的前半部分，我已经谈到，开发失败往往是不良管理实践的结果。

让我们设想两种情况：

一家公司引入了Scrum作为一种方法论（或其他缺乏技术知识的敏捷方法论），但其代码不够敏捷，无法承受代码的变化。在这些情况下，当添加代码时，它往往被草率地放置，而且代码的实现肯定会比没有技术债务的情况下花费更长的时间。这导致了开发速度的降低。
或者，一家公司遵循严格预定义的过程，该方法是一成不变的。这些过程往往是不合理的，但开发人员往往遵循它们，因为他们没有受过更好的过程教育，不想进入官僚纠纷来改变它们，甚至可能害怕因试图改进过程而受到纪律处分。

在这两种情况下，不良流程都是问题的核心。即使你处理的不是遗留项目，这也会因为整个属性中需求的变化而成为问题。软件的一个良好特性就是能够改变，甚至改变软件本身的设计（我们将在最后一章 "重构" 中讨论这个问题）。

Alastair Cockburn 认为，软件开发人员通常无法适应预定义的生产线流程。人类是不可预测的，而当他们成为任何特定流程中的关键角色时，流程也会变得不可预测。人是容易出错的，在一个预先定义的流程中，人的行为不会完美无缺，而在软件开发过程中，出错的可能性却很大。从根本上说，这就是敏捷宣言中所说的 "人必须先于流程" 的原因。开发人员必须先于流程。

一些管理层的人想要购买一种叫做敏捷的东西。他们会雇佣一个咨询师，而这个咨询师并不了解如何真正使软件开发取得成功，而是实施一个荒谬的过程，作为销售敏捷的摇钱树操作的一部分。我相信 Scrum 是这方面最糟糕的例子（部分原因是课程和伪资格的不准确数量），但毫无疑问，其他敏捷过程也可以被用作摇钱树。

我曾多次接触到一些经理或 Scrum Master，他们声称 Scrum 说我们应该做……或敏捷说我们应该做 ….。这种说法完全不合逻辑，应该避免。当你这样说的时候，你从根本上没有理解敏捷方法论是基于敏捷性原则的，因此，人必须高于流程。

让我们再回顾一下第一种情况。请注意，争议主要源于缺乏开发质量，而非项目管理流程。Scrum 未能实施开发流程，因此，通过 Scrum 尝试的项目往往会失败。

极限编程（XP）包含这些开发规则，而 Scrum 却缺乏这些规则。下面是一些例子：

编码标准（在 PHP 中，您可以选择我们在前面章节中讨论过的 PSR 标准）
首先编写单元测试，然后编写代码以使其通过测试
所有生产代码都是结对编程
专用集成服务器，仅进行一对集成一次编写代码，频繁集成代码
使用集体所有权；代码库的任何部分都不受其他开发人员的限制

所有这些都是在 XP 出现故障时进行修复的背景下完成的，从而使改进流程成为开发工作的常规部分。

要引入技术标准和开发规则，既要有已有的开发知识，又要有学习更多知识的热情；为此，逻辑严密、以证据为导向的思维过程至关重要。这些都是成为一名优秀软件工程师的关键要素。

结对编程不能成为一种指导工作，也不能成为一种师生关系；双方开发人员都必须愿意提出想法并接受批评。事实上，能够相互学习是至关重要的。

在敏捷关系中，每个人都必须愿意理解并参与规划过程，因为沟通是一项重要技能。同样，相互尊重也是关键；从客户到开发人员，每个人都值得尊重。开发人员在很多方面都必须勇敢，尤其是在进度和估算方面要实事求是，同时还要适应变化。我们必须在处理或驳回收到的反馈之前，先设法理解这些反馈。

这些技能不仅仅是开关，而是我们必须努力保持和锻炼的开放式技能和知识库。有些事情会出错；通过使用反馈，我们能够确保我们的代码在部署之前具有足够高的质量。