卢浮宫还是蓬皮杜艺术中心

卢浮宫

是世界上最古老、最大、最著名的博物馆之一。位于法国巴黎市中心的塞纳河北岸(右岸),始建于1204年,历经800多年扩建、重修达到今天的规模。 如今博物馆收藏目录上记载的艺术品数量已达400,000件,分为许多的门类品种,从古代埃及、希腊、埃特鲁里亚、罗马的艺术品,到东方各国的艺术品;有从中世纪到现代的雕塑作品;还有数量惊人的王室珍玩以及绘画精品等等。迄今为止,卢浮宫已成为世界著名的艺术殿堂。--摘自百度百科

乔治·蓬皮杜国家艺术文化中心

坐落在巴黎拉丁区北侧、塞纳河右岸的博堡大街,当地人常也简称为“博堡”。文化中心的外部钢架林立、管道纵横,并且根据不同功能分别漆上红、黄、蓝、绿、白等颜色。因这座现代化的建筑外观极像一座工厂,故又有“炼油厂”和“文化工厂”之称。大厦的支架由两排间距为48米的钢管柱构成,楼板可上下移动,楼梯及所有设备完全暴露。东立面的管道和西立面的走廊均为有机玻璃圆形长罩所覆盖。大厦内部设有现代艺术博物馆、图书馆和工业设计中心。它南面小广场的地下有音乐和声学研究所。中心打破了文化建筑所应有的设计常规,突出强调现代科学技术同文化艺术的密切关系,是现代建筑中重技派的最典型的代表作。 --摘自百度百科

缘起

我不想介绍法国的艺术中心,图片和wiki摘录是为了更加直观的对比。之所以把他们放在一起,是源于前些日子跟Forrest聊天中,将这两座建筑放在一起,作为隐喻,用来比喻开发中的两种软件设计风格。这个话题引发了我的深度思考,多日过去,我并没有想出一个可以接受的结论,甚至怀疑压根就不可能有结论。把一些思考的点点滴滴记录在这里,也许日后回顾起来也是一种价值。

不可否认,我的软件设计偏好受到Rails的影响,倾向于将复杂的细节小心封装在表面之下,并尽量以一种优雅,简洁,略带一点Magic得方式在上层编码,组织业务逻辑。就好像卢浮宫,从外表看,极尽奢华,但其内部的细节构造呢?至少从表面,不会轻易让你一窥究竟。

与卢浮宫成为鲜明对比的是蓬皮杜艺术中心,这座建筑曾经引起极大的争议,由于一反巴黎的传统建筑风格,一度让很多人无法接受。其实蓬皮杜艺术中心暴露在外面的复杂管线是有规则可寻的,空调管线是蓝色,水管是绿色,电力管线是黄色,自动扶梯是红色... 将所有管线排布在室外则换取了更大的室内空间,使用极为方便,而且管线维护容易,成本更低。

这次讨论得核心是,我应该采用哪一种设计编码风格?如果放在具体环境中,比如我现在工作的公司Factual.com,答案是第二种。在Factual,要求实现设计尽量简单,在满足需求得情况下,更多得考虑性能。代码表现力,代码美感,都不是首要的考量标准。这的确是一种讲究实效,工程师文化主导得选择结果,对此我非常理解并欣然接受。

可是到底哪种软件设计方式是更好,我个人得建议是,最好不要试图完整全面回答这个问题,哪怕在一个具体得环境中,每种设计方法学都有其长处和短板。所以深刻理解用需求和用例故事,以性能指标作为尺度来权衡是最佳实践,尽管看起来这是一种中庸得方式,不过得到的结果不会差到哪里去。

刚刚开始探讨这两种设计思路的利弊时,我内心深处竖起一道坚实的壁垒,不可否认卢浮宫是我的追求,这种先入为主的意识占了上风,至少,如果蓬皮杜得做事方式是正确的,那么不就是对自己之前的一种否认?因为Ruby得关系,以及长期浸淫在Rails得世界,不敢说自己写得代码算得上优雅,或多或少却知道一点什么样的代码才是具有审美意境,以及如何编码,才算得上是干净。或者说一切都不能违背DRY(Don't Repeat Youself)原则。后来立即明白,并不是要自我否认,而是在原来得基础上接受另外一种风格,让自己更加灵活,不要被与目标无关得这些taste层面得东西给牵绊,套上心理枷锁,先把事情作对,再把事情做好。想到此处,问题就变成了如何做才能两者兼顾,写出干净得代码,清晰表现自己得意图得同时,兼顾高效快速完成工作?答案是:唯有在项目中有不断打磨,锻炼,总结,慢慢就会有心得了......

做软件开发得人,几乎人人都知道GOF,都知道设计模式,很多人能将23种经典设计模式倒背如流,甚至肌肉反射式得将模式定义以及UML图表画出。说实话,这种事情我也干过,而且不止一次,设计模式原版是基于C的,后来有了Java版本,再后来Ruby版本得也出了。这些书我通通都看过,对我来说,在设计模式上耗费得心血,都以失败告终。于是我得出一条重要得结论:学习设计模式不难,难在知道什么时候用,以及用哪一个。这需要长期实践,总结并积累。这跟上一段得出的结论貌似如出一辙,不是么?

其实谈理论总显得有些空洞,我之所以偏好卢浮宫,偏好敏捷设计实践,跟我个人在软件开发学习成长得经历有关,这里我最先想到得是一个例子:年初我用Rails开发了一款web game,最开始时一切都进展得很好,不过我们想法太多,想要在游戏之上构建一个web game engine,并通过这个engine生成最终游戏。于是乎走了一条很长的弯路,陷入一种过度设计得状态。追求最灵活得设计方案,往往会导致实现变得复杂晦涩难懂,迫于项目进度压力,为了快速迭代,我们同时做了一些很疯狂得事情。打个比方,就好像你有了一个优雅得原型设计,然后把它弄乱,让它腐败,代码种开始充斥着各种臭味道。开发过程变得越来越笨重,修改变得越来越困难,另人沮丧得是对于这一切感到有心无力... 听起来是不是很熟悉?这种状况其实是司空见惯,且不停得被一遍一遍重演。

好的设计是修改出来得,修改代码有修改代码得“道”,我个人比较推崇Bob大叔在《Agile Software Development Principles, Patterns, and Practices》中提出得那些建议,似乎Bob大叔得这本书整本都在讨论如何解决这个问题。那么是不是看完这本书,就知道如何搞定一切了?答案仍然是否定的,这本书我粗看过一遍,发现很多东西我看不懂,看懂得部分没有悟透,仍然需要一遍接着一遍得看下去,直到永远~

这里到底我想要说什么?没有银弹(我不懂如何证明为什么没有银弹,至少我相信没有)。好几年前我跟南京一个快印店老板聊天时,谈到这样一种情景,我不记得是他还是我说的:那些一心只朝一个方向前进得人,未必能走得很远,有时心中装着截然不同,甚至相互矛盾观点得人,往往走得更远。因为他会不断停下来重新审视自己,不断思考并修正自己,就会越来越接近成功。回到最初得问题,到底是卢浮宫还是蓬皮杜?没有答案,也不需要,心理装着这两种思路,不断尝试,不断思考,不断总结,坚持下去,这就靠谱了。

后记,这篇文章是通过Ecto写得,发现用Ecto真不错,让写Blog变得轻松,效率高了不少 :-)