Super Mario Bros. from Andreas Heikaus on Vimeo.

德国一名动画艺术家Surfap近日展示了一部自己制作的视频，在这部视频中，《超级马里奥》的游戏画面被搬到了路边的护栏上，而且与电视画面不同的是，游戏场景的宽度大大增加。

没有了电视屏幕的限制，整个关卡的全部情景都在长长的护栏上展现出来，而且下水道、水底等附加场景也被展示在路面上，与墙角的地面部分的画面连接在一起，给出了《超级马里奥》单个关卡的全部场景。

Surfap介绍称这是自己在汉诺威制作的，是学士学位论文的一部分，主要讨论应用科学与艺术以及尝试将游戏画面脱离电视转移到户外环境中，并且能够让人与游戏和环境进行互动。

视频的效果非常出色。优酷上应该能搜索到，不过清晰度实在是不敢恭维……推荐还是从原始视频来源看吧。因为作者好像用的是德语，偶看不懂。估计应该是在后期合成处理的。AE和Maya应该能做到这样子吧。不过如果能有这样的增强实境游戏，也非常不错！

说来惭愧，整个项目做下来，自己没写过代码。学习Java平台下的Web开发计划打了水漂。不过项目管理方面的经验倒是积累了一些。所以也没吃亏，毕竟软件项目管理方面还是有很多互通的东西，以后的其它项目也能用上。

==========================================
关于需求

需求分析大概是所有软件项目都会最先面对的过程。关于需求的话题也足够写几本大部头的书了。需求分析也是几乎所有软件开发人员最头痛的过程，归纳起来，需求分析的时候无非是这么几种对话：

版本A
开发员：您对于这个系统有什么具体的要求？
客户：…我还没想好。你们看着做吧。
开发员：~!@#$%^&
（基本上是最常见的情景。如同每次吃饭时总有人要求带饭又不知道想吃什么…）

版本B
开发员：您觉得系统应该有什么功能？
客户：XXX做的不错，就按那个样子做。你们直接把他们的东西拷过来吧。记得要有多点触摸。
（算是比较强悍，好歹还会＂拷＂这么专业的词汇。问题是此时客户看上的其实就是个界面。）

版本C（系统初始版本做好后）
开发员：您看，我们的系统可以完成XX功能…
客户：等等，不是让你们做YY吗？还有怎么NN功能也没实现？另外这个界面太难看了。
开发员：您当时没说要做YY…
客户：不可能，我记得很清楚这个地方绝对说过！
（估计做开发的都遇到过这种情景…只恨自己不是机器猫，没有时光机）

当然各位童鞋还可以把这个列表无限地延长，变成一首字母歌。关于需求分析的各种故事或着说笑话层出不穷，但林林总总下来可以归纳为两点：一、用户需求不明确。二、用户需求变化。

关于这两个问题，短短一个月的时间已经被我们无数次地体会。当然很多人也提出了解决的方案。例如，很多做需求的人在调研的时候会要求客户签字确认。也有许多公司会耗费大量的时间与客户打交道，以更深如地了解需求。

但是，我得说，如果你所在的项目能够做到以上两点，那你实在是幸运异常，强烈建议您抓紧时间买张彩票。因为，我的经验是：客户不知道自己真正的需求；即使知道了他们也说不出来；即使他们说出来了你也听不懂。惨吧？

所以，软件项目开发中，需求不明确才是一种常态。看到周围的很多人为此长吁短叹，想想看实在是自寻烦恼。因为这种需求的不明确有时候恰恰是一种优势。换句话说，如果客户的需求真的明确了，那估计整个产品的设计也只剩下体力活了。如同送女友生日礼物：送之前你并不明确知道她想要什么，正是绞尽脑汁费尽心机的思索，才让我们的礼物显得格外珍贵，所谓礼轻情意重（Errr可能是礼贵情意重，贵重贵重！）。

其实，多数软件产品的需求是需要开发人员来明确的。需求分析时与客户的交流固然重要，但是多数时候这种交流的效率未必会很高。要知道客户也有自己的工作要忙，他们真正关心的才不是你的软件做的好不好。所以有时候就是需要开发人员按照自己的理解对客户的需求加以合理的推断，然后制作原型，为客户演示。

演示的过程也是一种交流，但是这种交流就要比单纯的需求分析讨论高效得多。其实往往是到这个时候，客户会恍然大悟般地说：“对对对，这个东西就应该是这个样子！”

因此，很多需求，让客户直说未必能说得出来。但是让他面对着一个看得见摸得着的东西，他就会有明确的目标。好比东西已经有了一个骨架，再在这个骨架上进行装点就要比空中楼阁容易得多。

但是这一切都有一个基础，就是对客户需求的合理分析和推断。这一点非常不容易。为了做到这些，软件开发人员必须设身处地地为客户考虑，并尽可能了解客户所在行业的一些现状。比如说，为政府部门开发办公系统，就应当了解政府日常办公的基本业务（多说一句，政府的日常办公最基本的东西就是公文流转，所以如果能把公文流转和权限控制做好，那基本上这个政府的软件系统就有了成功的基础）。如果是为学校做系统，那就得了解学校日常的一些教务或者办公活动是怎么开展的。这非常不容易，有时候确实需要软件开发人员进行实地考察。所谓隔行如隔山，在很多行业内部觉得理所当然的东西可能对于开发人员来说就是闻所未闻的事情。其实软件开发又何尝不是这样，我们觉得很正常的数组、数据库之类的东西，可能对于外行来说会觉得非常神秘。所以，还得记住，用最平常的心态来和人交流，切莫使用术语！

但是，这不恰恰是软件行业的乐趣之一吗？通过做软件开发，可以了解那么多行业的奇闻异事，多么有趣！

==========================================

用心于交互设计

需求分析做的差不多了，就可以开始进行系统的交互设计了。其实这个步骤可以提前到需求分析刚刚有个眉目的时候开展，这样我们可以拿着交互（界面）设计的草稿与客户交流，大大提高需求分析的效率。

说到交互设计，大部分人都会想到界面，然后说到界面，大部分人都会想到色彩和布局。

我说，这是不对滴。

软件系统界面的色彩和布局固然重要，但是交互设计所涵盖的范围比这要广泛得多得多。在我看来，这个阶段的交互设计最重要的是确定以下几件事情：

1. 明确在某一个界面元素上用户可以进行什么操作（单击、双击、多点触摸等等），这些操作可以带来什么结果。

2. 明确用户可以通过某一界面得到什么信息。

3. 明确数据的呈现形式（表格、列表还是图片等等）。

4. 如果有精力，就吧色彩和布局确定下来吧……

以上几条，其实是完完全全地围绕着需求设计来进行的。系统的交互设计阶段在整个软件的开发中应该起到一个承上启下的作用：能够将用户的需求变成一种看得见摸得着的东西，让客户明白这个系统做好以后会是个什么样子；同时，能够让写代码做数据库设计的人明白，他们需要实现的功能具体是个什么样子。

举例来说，如果是开发Web系统，那么可以在这个阶段先明确几个主要的功能页面，同时明确这几个大的功能页面之间应该如何跳转如何组织。之后，可以考虑为了实现某一功能，还需要哪些子页面。在每个页面上，应该有哪些“表单”，或者说得直白一点，哪里应该有图片，哪里应该有按钮，哪里应该有文本框等等。此时，完全不用急着把页面的色彩和布局完全确定下来，这些东西都是可以在后续的步骤中一点点改进的。这个时候，其实完全不需要什么电脑来设计，铅笔和白纸会是最好的设计工具。把界面上该有的元素画在纸上，旁边标注这个元素应该如何与用户交互，操作以后会有什么结果等等。开几次会，集思广益，同时让大家都明确最终的产品应该是个什么样子。

当页面中包含的内容基本确定之后，大概就可以要求美工人员进行制作了。这个时候就得上电脑了。用Photoshop之类的东西设计页面的样式，这样比较方便最后直接截取相关图片用于网页的生成。这个过程中一定多与客户交流，明确他们喜欢什么风格的东西不喜欢什么风格的东西。页面到底应该是中庸一点还是活泼一点还是要酷酷的感觉。

感觉上，现在的很多开发人员都有点忽视甚至是鄙视做美工的。诚然，美工这个行当没有磊代码那么高深，加上艺术家们往往以见不得人的模样招摇过市，让大家都觉得做美工的仿佛都是些无足轻重的愤青一般……实际上，在几乎80%的项目中，美工的好坏直接决定了客户的“领导”是否喜欢项目的成果。此时，各位程序员们往往会酸溜溜地说一句“他们不懂”。

美工真的不重要吗？我觉得美工，或者说交互体验恰恰是一个系统最重要的部分。为什么？因为美是人类最最基本的需求。我们每天穿衣打扮，为的不就是让自己好看一点（当然冷急了或者热坏了也顾不得那么多了）？看看大家买的笔记本电脑就知道，其实绝大多数人买电脑一不看性能二不看指标，她们（是的，多数是女孩子）只关心外观和价格。很多搞计算机的看到这儿肯定不服气，但是这个结论是我的几个IT行业的同学说的，人家天天就是卖电脑，市场数据说明一切。

所以一个成功的公司必然会在交互设计上狠下功夫，也必然会为自己的产品设计漂亮实用的界面。想想吧，看到苹果的那种设计，你难道没有那么一下下的购买冲动？

==========================================

确定数据库/数据结构

基本上，经过需求分析和交互设计，软件就可以正式进入开发阶段了。对于多数产品来说，尤其是Web开发项目，首先需要确定的就是数据库结构或者数据结构。

数据库方面lqhk的经验实在不多，也确实没经历过多么复杂的SQL语句的摧残。看看编码的童鞋们写出的那些SQL语句实在是让人觉得发指……

说到数据库，不得不提，今年恰好是关系型数据库诞生40周年。从当年E.F.Codd提出的概念，经过40年的发展，关系型数据库早已成为众多大型系统的基础，并支撑着我们这个世界的运转。基本上，我们做什么系统，需要大量的结构化数据，都会想到数据库。

数据库的设计有点像走独木桥。一方面，关系型数据库鼓励我们尽可能提高数据的一致性；另一方面，过高的数据一致性有可能降低效率，而且查询和修改（尤其是修改）会变得很不方便。归根结底，软件系统的设计都是在对现实世界进行建模，也就是将现实世界中的种种事物抽象为软件中的逻辑概念。个人感觉关系型数据库算不上一种非常好的抽象模型，我们生活中的很多数据并不适于用这类数据模型来表示。因而这就需要进行折衷。算下来，数据库设计无非两个原则：要么提高查询效率，要么提高修改效率。什么？你还想两者兼顾？那就只有提高预算了……

现代的多数数据库产品对查询优化得比较不错。在这个基础上，可以通过为数据人为地添加索引来进一步提高搜索的效率。如果还想进一步提高查询效率，还可以通过在数据库中记录更多的额外参考信息来减少查询结果的数量。当然，加上这些索引之类的玩意儿以后，咱就别想着什么增删改了……

至于修改（包括增删改），无非是尽可能提高数据之间的独立性。也就是说，数据表之间的外键链接尽可能少。这样，可以尽可能保证一次只需要少量的操作即可完场数据的修改。话说回来，现在这些数据库产品似乎都不是为了大量修改而准备的。

另外，系统应该尽可能利用数据库的一些功能来提高效率。其实存储过程、触发器、视图之类的东西都是非常好的功能，善加利用，不仅可以降低业务逻辑的复杂性，对于系统的效率也可以有很大的提高。很多需要多次查询判断最后写入的数据库操作，往往只需要一个存储过程传递几个参数就可以在数据库内部解决了。这类经验在网上应该有不少论述，高手很多，我就不在这儿现了……

这节最后，lqhk打算发发牢骚。现在市场上的数据库产品感觉都有点脑残，最重要的是缺少分布式系统的特性。很多大型系统中，业务逻辑之类的可以通过添加多台服务器进行动态的负载均衡，但一到数据库这一块，基本上没啥办法，就是上一台超强的电脑……要么就是想办法增加缓存，总之是治标不治本。分布式这块Oracle倒是有解决方案，但据说配置无比复杂（你搞个微软那样的下一步下一步下一步完成界面会死啊……）。MySQL好像也有，但是据说性能提高不大（开源的东西到底是缺点专业性的支持……）。这也是没办法的事，其实想想关系型数据库本身的基本特点，就是尽可能地使数据唯一化，这样的特性本身就不利于实现分布式系统。如果实在想搞，微软这边的Biztalk倒是可以在多台数据库之间进行负载的均衡，不过所有的开发就得在数据层这块针对Biztalk做开发了。

说到性能，也得提一下最近比较火的NoSQL。一般的关系型数据库应付查询的能力倒是不错，但是到写入这块基本上都得扑街了（大概……一秒钟一万次就差不多了）。拜脸书Fackbook所赐，SNS类的网站现在大行其道，问题是这类网站往往需要同时应付大量的用户，类似人人这样的网站每秒钟几万个人同时在线编辑自己的状态恐怕是非常正常的事情。这个时候网站有两个选择，要么通过复杂的业务逻辑处理把数据分布到不同的几台数据库中，要么就得另辟蹊径选择非关系型数据库了。实际上，现有的SNS网站也都是这么干的。各位有兴趣，可以试着查查看NoSQL的一些解决方案，还是蛮长见识的。

==========================================

累代码

最近参与的一些项目，全都是Java平台的。我想说，我不太喜欢这东西。

主要的问题是，.Net平台下有ADO.Net，对于数据的处理功能比较强大。相比较之下，Java在这方面的支持就比较一般了。刚好我们开发的又是Web项目，数据库用的又比较多……所以每次不得不把SQL语句写得超级复杂以求一次性读取出需要的数据。

为什么用Java？得到的答案无非是：Java能够跨平台，我们的产品将来有可能在Linux下跑；Java是企业级的解决方案，比较强大……如此等等。

真的看看，我们写的东西有多少是真的跑在Linux下的？你说10年以后？10年以后我们的项目还在跑吗？

并不是说.Net就是比Java优越。在很多时候，两者应该都能够满足需要。问题是，如果我们的项目只是需要快速实现，并且借助现有经验尽可能重复使用已有的代码，那么.Net还是有一些优势的。最起码，VS就已经内置了不少控件，TreeView之类的这些东西现成可以拿来用。ADO对于数据持久化方面的支持也非常出色（很多做Java的也承认这一点）。缺点嘛，如果你用.Net了，基本上就只能在微软的圈子里面转悠了。不过我们做的项目大多好像都是跑在Windows上的吧……何况数据库用的都是SQL Server。

还想说的是，现在的Web开发实在是不够Ajax。准确地说，是没有做到后台和前台分离。比较好的做法是，后台只需要传递必要的数据，数据的具体解析由前台负责。但是我这里所有的开发人员都说，这样很难做……我不是太理解……

==========================================

积累和总结

算算到现在，我们开发的项目也有不少了。

就拿我参与的这一个项目来说，之中有很多地方都可以使用已有项目的模块来现用。但等真的用起来以后，就发现还不如自己重写一个……那时候的感觉就是非常恶心。

说白了，没有归纳总结的经验终究只是嘴上说说的谈资。所谓学而不思则罔，思而不学则殆。正常的情况下，项目的主体完成后，一定要尽可能地总结。

总结可能是多方面的。首先，接到项目后，只要不是体力活，多多少少总能接触到一些新的技术，这些点点滴滴的东西应该加以记录，并且多多少少加上一些索引之类的。

然后，在架构这一级，新的项目总会有一些问题需要采用全新的架构进行处理。每种架构的优点、缺点会在不同的应用环境下体现得特别明显。这些架构上的经验，同样是非常宝贵的财富。尤其是在中国这个大环境下，咱们不能做一辈子程序员，想往高处走，多多少少总需要了解一些框架性的东西。

最后，则是具体实现方面的经验总结。写代码总会有错误，遇到过的错误最好记录一下防止以后再次遇到类似的问题。开发中的小技巧日积月累下也会成为高手不可缺少的一部分。从量变到质变的过程，正是这些点点滴滴的积累总结所造就的。

==========================================

总结的总结

以上的这些东西主要都是针对Web应用开发的一些经验。然而，软件开发总有共通之处，千变万化之下无非是一些极其简单的基本原则。

总算是项目临近尾声，希望下一次再遇到类似的项目会做的更好……

http://web3d.5d6d.com/?fromuid=6751

生日快乐！

老大，在这个美丽的午后午夜，我谨代表自己祝你生日快乐！ ]]> http://liuhaohome.com/?feed=rss2&p=62 0 http://liuhaohome.com/?p=59 http://liuhaohome.com/?p=59#comments Thu, 10 Dec 2009 01:00:42 +0000 lqhk http://liuhaohome.com/?p=59 难得啊，第一次的事故，幸运的是数据没丢。以后要注意备份了…