精益求精与深渊

Daniel Terhorst-North 最近关于软件精益求精的博客文章引发了许多博客讨论（如果您有兴趣，我将在下面总结）。其中有很多内容，但其中一个主题特别引起我的共鸣，因此有了这篇文章。

然而，在谈到这一点之前，我想先把一个元素放到一边。我一直认为，关于软件开发隐喻的争论是乏味的。虽然隐喻式提问有其作用，但我从根本上对软件开发究竟是手艺、艺术、贸易还是甜点配料并不感兴趣。

对我来说，重要的是不是精益求精的隐喻，而是过去几年涌现的这一运动的一个特征。从我的局外人角度来看，为软件精益求精社区注入活力的主要力量是对敏捷运动变化的反应。在敏捷病毒的早期，占主导地位的菌株是极限编程，它对技术实践有很多话要说。现在，占主导地位的敏捷菌株是Scrum和精益，它们对编程并不关心——因此，那些主要将自己认定为程序员的人感觉他们生活中很大一部分在敏捷世界中不再重要。

因此，软件精益求精世界是一个可以再次将编程置于中心位置的地方。人们可以谈论测试、如何学习和使用函数式语言、良好设计的原则等等。然后，管理和分析问题可以留给衰弱的敏捷社区。我对此有很多共鸣。我接受设计耐力假设，它表明如果你想有效地开发软件，你需要关注良好的技术实践。因此，一个关注这些问题的运动很重要。但这里也存在一个危险，那就是过度关注技术问题会导致精益求精运动低估客户沟通同样重要的作用。

我非常喜欢 Kent 的作品的一点是，他在客户关系和执行我们这半部分交易所需的技能之间取得了真正的平衡。我记得他在敏捷宣言会议上说过，他使用极限编程的主要目的是弥合软件开发人员与其客户之间的鸿沟。这种鸿沟，我和 Dan 称之为“令人不寒而栗的深渊”，是软件开发中最重要的问题之一。

深渊的很大一部分责任在于组织习惯，这些习惯建立在程序员和客户是如此不同的生物，以至于他们无法沟通（也不应该尝试）的观念之上。但许多程序员似乎也乐于扩大深渊。几年前，我被 Eric Evans 的观察所震惊，他发现随着开发人员变得越来越资深，他们往往更关注技术问题，而不倾向于参与了解他们正在工作的领域。领域驱动设计正是试图改变这一点——尽管它通常似乎陷入关于如何在存储库上使用依赖注入等主题的讨论中。（我自己的职业生涯也因此受到影响。随着我成为一名通用的软件开发专家，我再也不能从事领域建模了——尽管这始终是我最喜欢的软件开发部分。）

因此，正如 Scrum 和精益通过忽视技术技能加剧了这个问题一样，我担心精益求精反过来可能会通过忽视关系技能而使深渊变得更糟。我理想中的程序员不仅精通编程技巧，而且还乐于通过与领域专家沟通来了解领域，以便她能够参与寻找最佳方法来帮助客户在他们所做的事情上取得成功。用 Dan 的话说，软件不应该成为程序员世界的中心，相反，程序员应该关注软件应该提供的益处。

博客讨论

（包括针对此条目发布的项目。）

• Daniel Terhorst-North 的原始帖子
• Liz Keogh 解释了她对软件精益求精宣言的不适。
• Gil Zilberfeld 将软件精益求精与 alt.net 进行了比较。
• Jason Gorman 希望我们避免陷入标签的泥潭。
• Michael Feathers 希望我们在工作中进行更刻意的练习。
• George Dinwiddie 提供了一个物理示例，说明为什么高质量的工作对客户很重要，以及认证和许可如何无济于事。
• Daniel Terhorst-North 扩展并澄清了他之前的一些观点。
• Bob Martin 说软件精益求精只是关于那些厌倦了编写垃圾代码的程序员。
• Bob Martin 认为我的担忧毫无根据（我希望他是对的）。