周末聊些轻松的话题，身为程序员的你，是怎么看待「美」的？代码美不美？架构美不美？什么样的美才是技术的美？欢迎留言讨论。

写在前面

我们大概都阅读过或听说过类似于编程之美或架构之美或数学之美的著作，那么，代码到底美不美呢？如果是美的，是怎样的美呢？又该怎样理解和欣赏这种美呢？不妨把问题向美学或艺术的稍深层次的内涵稍稍推进一步，姑且把程序员视为艺术家，那么，代码有可能作为他们审美情感 (Aesthetic Emotion) 的对象吗？程序员可以像艺术家那样工作吗？

如果这一切都是否定的，那么，Donald E. Knuth 的煌煌巨著又何以称为计算机程序设计艺术 (The Art of Computer Programming) 呢？这些问题涉及到艺术和技术的关联，都是很大的问题，以我对艺术的粗浅认识以及对程序的有限了解，既不敢也不能给出确定的答案，这里只是谈谈自己阅读的感受和体会。

何谓艺术？

从产出的作品和结果的表面形式来看，代码和艺术作品的相似性也许无从谈起。从创作或创造的过程来看，程序和艺术，程序员和艺术家的差别似乎并没有想象中那么大。有关艺术的最经典的和最古典的理论莫过于 Clive Bell 在他的著作《艺术》(Art) 中提出的假说，atv，即可视艺术如绘画的本质属性是有意味的形式 (Significant Form)。所谓形式即颜色和线条的组合与关系，之所以有意味，是因为在作品的形式中注入了艺术家的情感。对艺术作品敏感的人，正是因为发现了艺术作品中的有意味的形式，激发了和艺术家共鸣的情感，才被深深打动。这一假说被誉为最令人满意的现代艺术理论，所以，我们假设它是合理的，真实的，可信的。

那么，按照这种理论，在构思作品时，艺术家是怎样获得要表达的情感呢？有意味形式的灵感火花又是从哪里来的呢？比较客观的回答是八仙过海，各显神通，不能一概而论。但是不可否认，确实有这样的艺术家，他们基于客观的物质对象或想象的虚拟对象的形式的理解和体验，在电光石火的刹那灵光乍现，茅塞顿开。他们的诀窍和天赋在于观察物质世界和构想虚拟世界时，统统地把所有的对象看作纯粹的形式，即线条，颜色，和形状，以及它们的关系，而完全忽略对象的功利性的标签。

比如房间中有一把椅子，普通人首先给这东西贴上椅子的标签，然后想到的是它的世俗的功用，可以坐在上面读书，吃饭，聊天。当然，调皮的熊孩子们对椅子使用的想象力就更不用说了。若考虑地更远一点，也许还会联想到座次名位，如水浒中的头把交椅，聚义厅，忠义堂，替天行道，朝廷招安等等。而富于天赋的艺术家仅仅忘情于椅子的纯粹的形式, 而椅子是什么，叫什么和用做什么根本不在于艺术家的思维光谱中。

从美学角度上看，只有纯粹的形式才能揭示出物质的本质属性和终极现实 (Ultimate Reality)，用一个形而上学的术语，即物自体 (The Thing in Itself )。物质的本质属性和终极现实不就是哲学家孜孜不倦地追求和探索的终极目标和终极真理吗？这岂止是有意味啊，物质对象经由纯粹的形式升华到形而上学的终极真理，恐怕世上再没有比这更伟大更有意义的事业了。无论是艺术家还是鉴赏艺术的观众，伟大的艺术作品象纽带一样牵引着世俗的我们去体验美学的出世的终极真理和终极现实，心中的情感和快感像火山一样激烈澎湃，情不自禁，难以自己。

程序员是怎样看的？

回过头来，看看程序员是怎样观察物质世界的。从面向对象的角度分析，我们把给定的问题域或应用域内的所有的一切都看作对象和对象之间的关系。对象中包括成员变量和方法，继承、组合和关联是对象之间最普遍的关系。对象和对象的关系也是面向对象的编程语言所能处理的全部。所以，需求可以千变万化，万变不离其宗，把需求描述的问题域或应用域抽象成对象和对象的关系，是以不变应万变的唯一的解决之道。因此，反过来讲，面向对象的方法为程序员提供了一种观察世界，或更具体地讲，描述应用域和问题域的抽象框架。

那么，程序员是怎样做到把问题域或应用域抽象为对象和对象的关系的呢？较为客观的回答是八仙过海，各显神通，不能一概而论。并没有确定的，机械的，可操作的流程把需求转换成对象和对象的关系。否则，一旦这一转换过程掉入邱奇图灵论题可计算的范畴，程序员的工作马上就可以被机器取而代之了。某些程序员在某些项目上做的好一点，某些程序员在某些项目上做的差一点，还有些所谓的程序员在所有项目上都做的一团糟。这种不确定性不就是程序创作的艺术性吗？