优秀的代码是一件艺术品？或者软件工艺宣言言过其实了？成为一名“优秀”的程序员，有什么要求？

　　设想你雇佣了一名水管工，让他更换地下室的旧管道。这个家伙在工作之前、之中、之后，他就没有停止过谈论他的管道工艺的艺术美。

“看看那根管道的角度。看看它与墙壁对齐是多么地美？如果你问我，那么它就是一件艺术品。”

　　这和程序员没什么区别。没有什么比 不可一世的程序员把他或她自己的代码看做是艺术品 更糟糕的了。这个类推借用了”敏捷麻烦制造者”和BDD【注1】创立者Dan North的一篇广受赞誉的文章，Dan North激烈地批判了软件工艺宣言，论证了“编程不是艺术”。

　　软件工艺宣言

　　宣言的作者Kevlin Henney、Bob Martin、Corey Haine和Glenn Vanderburg揭示了下面几项将通往软件工艺的大门：

• 不仅是可运行的软件，而且是精心设计的软件。
• 不仅响应变化，而且稳步增加价值。
• 不仅个体与交互(Individuals and Interactions)，而且是专家社区。
• 不仅仅是客户协作，而且是有生产力的合作伙伴。

　　North的问题在于，软件开发者的自尊经常妨碍其成为优秀的软件项目。North谈到，用“精心设计的软件”这种荣耀的概念进一步加压到自尊上，是达不到预期的。Webservice和J2EE就是最近的项目例子，软件艺术性的崇高诠释部分地导致了项目的失败。

　　优秀的编程

　　你或许已经知道了来自于小型IT项目的这种问题。某个开发者主张使用特定技术是因为审美（而非务实）的原因。从此就每况愈下了。

　　根据North的观点，代码优美是因为它能有效地运行，而不是因为审美上有吸引力。不应该太计较代码看起来怎么样，而是看代码在从A点到B点带来的一段信息是多么可靠、高效。

“一个技术娴熟的编程团队可以在非常短的时间里交付让人惊奇的业务结果。一名真正的专家——真正的工匠——将理解埋葬在、比如我们把企业软件称作的杂乱里的、优雅的简单，并整理清楚。” ——Dan North

　　但是悲哀的是，甚至那些优秀的程序员经常忘记优秀软件的核心职能——软件工艺宣言的过分强调往往是祸因。

“软件从业者—特别具有讽刺意味的是优秀的软件从业者—经常忘记这一点。他们爱上了软件本身，开始把他们自己看做软件工匠。”——Dan North

　　开发者需要多大的才能？

　　这里有个引起整个争论的问题：软件工程是一种艺术形式吗？焦点集中在 对他们的工作充满激情的有热情的专家 和 只为薪水工作的程序员 之间的挣扎上。

　　据说性能和效率在软件行业的差异正在缩小，但是就成为优秀开发者的条件定义而言，没有达成一致或被认可的方法。Dan North说，“一名真正伟大的程序员胜过数百个为钱做事的程序员，在数小时或数天就可以交付，而普通程序员要用数周或数月。”

“做为软件解决方案的买家，难道你不想知道你的系统是被大师级工匠而非拿薪水的人开发的？你支付了钱，你有权保持某种信心。让我们搞清楚怎样提供这种软件。”——Dan North

　　North声称，“架构之美”无助于我们区别好坏。任何程序员都能把他或她自己称作软件工匠，滔滔不绝、高谈阔论软件架构的“美”。North对我们说，他将“乐于看到有人根据结果导向和取悦客户来重写软件工艺宣言。”

　　地下室与代码

　　房主不关心他们的水管看起来如何，只要它们不漏水就行。软件同样如此。客户和用户都不关心它是如何运转的，尤其不关心它内部看起来是否“美”。

　　“同样，我想让专家级电工而非新手给我的屋子布线，我想让专家级程序员涉足我的业务，”North对我们说。“然而，我不想要一个坚持谈论管道系统优雅与审美的、恃才傲物的管道工。”

• 原文地址：http://jaxenter.com/programming-art-and-software-craftsmanship-112123.html
• 注1：行为驱动开发（缩写BDD）是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。BDD最初是由Dan North在2003年命名，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。在过去数年里，它得到了很大的发展。http://zh.wikipedia.org/wiki/行为驱动开发

[转]优秀编程的“艺术”