摘要: 你曾听说过一名专业软件开发人员应该掌握一种驱动方法吗？这些驱动方法可能是：领域驱动设计（Domain-Driven Design）、测试驱动开发（Test-Driven Development）、行为驱动开发（Behavior-Driven Development） ...
| 有什么替代的选择？ 诚然，开发者的各类驱动认证似乎是有吸引力的团队开发策略。对此我不下结论。这是一个策略选择的问题，如果它带来预期的结果，也没什么好说的。接下来我将介绍一些也许你会认为有价值的替代选择。 打好基础 如果让我用三个词总结整个软件工程，我认为是：职责、封装和组合。每个词都能写成一篇独立文章甚至一本书。遗憾的是，当我们挣扎于各类驱动方法时，我们忘记了这些词可能才是我们应该关注的最重要的概念。我们常常问自己，该使用什么模式？选择什么心理框架？相反，我们应该问：这个方法、类和模块的职责是什么？职责、封装和组合是每一种软件工程技术的基础。 如果你已经很熟练地运用这些概念，模式将会水到渠成。如果你忽略这些概念，你很快将要结束一个糟糕的软件工程。与此同时，这些概念非常通用，与你的经验无关，你始终可以在更深的层次上去理解它们。 因此，你的第一阶段应该是集中精力打好基础。当你掌握这些概念后，你可以继续往前到一些更复杂的任务，包括： 使用职责、封装和组合； 以接口的视角思考，即“人们如何使用我的组件？”； 使用相关技术写好代码，包括可读性、信息性、简洁、自描述，尽量避免显式地使用模式； 有能力回答特定业务的“本质”；“本质”是一个模型，但不意味着类和方法，它意味着回答问题“这个业务如何真正地工作？” 有趣的是，按照这些规则写的代码也许不是“最佳”的，但它一定是“易于重构”的。我们能够以相对容易的方式修改其结构。这与那些难以重构，甚至当发生变化时，有时候要完全重写的代码形成了鲜明对比。 技能管理 在开发过程中，另一种比痴迷于各种驱动方法更有效的策略是团队中技能的告知管理（Informed management of skills）。很久以前，你要进入雇主-熟练工的关系才能得到一份工作。它最新的名字叫做老师（教练）-学徒。现在，每个开发者在起步阶段，都有一堆文档，简单、重复的工作要做。有些人数月、数年的时间都投入其中。某些情况下，这减少了他在就业市场中的成功机会。我要大胆地声明，这份新工作抹杀了他的潜力，对其开发毫无帮助。从技能开发管理的角度来看，如果说每一个专业人士都能够被一定数量的学生取代，那么也就等同于说每一个CEO都能被一定数量的顾问取代。 通过以下行动，组织能够管理好开发者的技能： 教会有经验的工程师成为老师和教练； 为新员工指定一个关心并帮助其提升技能的人； 为开发者提供机会，让他们有可能工作于各种不同的项目、技术、客户和同事（当然，不是同时）； 对员工设定额外的技术设定，不匹配的人不能录用； 一旦录用了某人，就认为他具有开发的潜力； 与开发者构建双向信任。 可替代的人力资源 至少一或多种方法是与技能开发管理背道而驰的。也许这是开发者最不欢迎的方法。公司不明说，却在实际使用的方法。这就是为什么它很重要，我要在这里进行说明的原因。它的主要目标是建立一个架构，让公司能够以快速、廉价的方法替换大多数开发者。这样的组织会做以下事情： 雇用一定数量具有丰富经验的工程师，剩余的开发者则只需要普通技术水平和平均薪酬； 一小组开发者构建系统架构，使得后续开发能以重复的模式进行，从而将执行成本降到最低； 系统架构的调整由开发专家进行，关键变化和创新变革始终由那些具有丰富经验的专家团队和高薪工程师完成。 总结 正如之前所说的，本文并非要批评任何人或任何事。它只是谈论优先级并寻求平衡。首先关注于我们的基础技能，这能够帮助正确地使用某种驱动方法，特别是在未知的上下文环境中。我真的感谢所有这些心理框架，他们做了非常棒的工作。但我认为如果软件开发是由某种东西驱动的话，这是股东的需求和我们的简单认识。被任何其它东西驱动都可能会影响简单性。 |
