页面

分类

梦断代码--一个程序员的自白(七)

2014/4/25, by wingfire ; 分类: 其他; 0 comments

大约是各方面对ADP的反响都不大好,ADP要想推销自己,必须找到新出路。最终,目标锁定到Protein,让Protein通过ADP来存储材质包。对于Protein项目,我至今也不知道最初的立项缘由。Protein后来被定位成一个内容(材质)管理库,为公司的所有产品提供统一的材质管理。最早,Protein是基于FBX(一个3D文件格式和SDK)来实现的。ADP同事加入的是Protein 2.0。由加拿大的一组同事设计了一套新的API,表面上隔离了FBX。O和G做了将ADP集成到Protein的所有关键工作。除了用一个单独的DLL用来作为胶合层外,ADP也为此大作修改,几乎重写了runtime部分。此时,大部分中国的同事,也包括我,是对这些工作一无所知的,或者说是漠不关心。我只是做一些常规性的工作,解决各种编译、移植、测试问题。随着ADP集成结束,我也转到了Protein项目。合作者也换成了加拿大的同事。

在产品集成Protein 2.0的过程中,遇到了许多早就预见到的问题。我称之为,明知前面有坑,被推着眼睁睁往下跳。我早在ADP时就说过,即使把数据存成文本,依然需要制定存储和转换协议,并预言中的问题却一一变成现实。一个是本地化的问题。例如在德语中,千分位和小数点符号不同于英语,而是相反。因此,“3.142”这样的数,到了德语里面就被读取成3142,这显然是不能接受的。这个问题在项目早期很好解决,就是要规定外部文本的解析方式,比如统一使用C locale保存就很容易搞定。另外一个是精度问题。比如0.3这样的数。用户输入的0.3,下次再打开,显示的却可能是0.2999999999。其实对于明白原因的人来说,这再正常不过了,可是对某些人却是难以接受的。由于Protein内部同时使用float和double类型,double还好一点,float出现前面问题的机会非常大。于是一个凑合的方案出台了,就是全部改成使用double,显示的时候,截短显示位数,利用平台API的能力来达到显示为0.3的效果。这种做法是非常脆弱和幼稚的。我们需要通过制定数据规格,让用户理解,什么样的显示差异是有道理的,也是符合预期的,而不是凑一个让用户满意的结果。如果我们明确了这种差异和差异的原因,用户代码自然就有据可凭,去填补数据表示和显示之间的空隙,而不是一团糊涂地代劳。事实上,提高精度和利用平台API的方法,在用户做了一个float到double再到float的转换后,因为精度丢失,就失效了。精度问题在后来Protein 3.0引入限制数据范围的特性后变得尤为严重。从字面上看是合法的数据,但是代码执行中却可能是非法的。这是因为double转成float会四舍五入,所以舍入后方向并不确定的缘故。这种问题对某些软件来说完全不重要,对另一些软件来说,则是至关重要,因为它影响到数据正确性。我们公司的软件正是后者,多是用来做各种设计--也就是创造数据的。

另一个我认为很重要的数据完整性(包括正确性)问题,则从未得到重视,或者说从未被理解过。在我看来一个很显然的事实是,对于ADP、Protein要处理的任何外部数据,都要持恶意假定,即可能是任何形式的坏数据。在此情形下,在处理到任何坏数据时,都不能出现崩溃或其他的致命错误(如内存耗尽,死循环等等)。即便是安全性错误也是要竭力避免的,如临时文件漏洞,缓冲区溢出等等。对于保存数据,ADP采用了创建--改名的机制,虽然很慢,很笨拙,却也有效地避免了数据完整性问题。就地修改的特性,且不采用回滚日志,最后也没做出来--幸好没做出来。时至今日,ADP、Protein在读取到坏文件时,几乎100%会发生故障,安全性问题更是没有任何评估。然而就这样的东西,现在居然有人将之部署到网站,用来处理用户提交的数据文件!这是打算引诱人犯罪吗?

当被自己预言过的问题坑了的时候,我不会觉得自己英明,而是为自己的无能为力感到羞耻乃至愤怒--愤怒不过是无能的另一种表现形式罢了。乃至于到我快离开ADP时,还给了我一个几乎让我暴走的任务:为了避免阻塞在费时的ADP保存数据操作上,要让写出过程是异步的,用多线程解决。要知道,这是ADP的运行时太慢导致的,即使我异步处理,仍然要读ADP运行时数据,而且为了保持数据一致性,就必须要锁住ADP系统--ADP可没有快照机制--直到保存数据操作完毕,那么要异步何用?这个任务我拖了好几个星期,并且被告了一状。最后说我临时先写一个,将来会用一个多线程IO的东西将之替换掉。没办法,我只好去做那个有害而无益的任务。在后来的Protein中,我不知道有多少次遇到多线程IO上出现的bug,而且,每次定位和修复bug都要花费好几天的时间。唯一值得庆幸的是,我写的那个临时方案确实很快被替换掉了,我不必为此背负骂名。

Protein团队的组织有点松散。我到了Protein长期处于无事可干的状态。在完成了Property和PropertyTable的实现之后,发了两次邮件请示工作无果后,我也就懒得关心,看看代码就是了。Protein由多个模块组成,我们的主要工作是其中一个dll,即提供对材质库的访问和管理,以及为材质对象建模。Protein API的风格应该是受Java或者.Net的极大影响,全部设计为接口,整个库导出一个唯一的全局函数(GetIAssetLibraryManager())作为入口点。因为没有导出任何实例类,所以一切的工作都要从这个library manager对象出发,逐步展开。对于这样风格的API,如果设计的好,未尝不可。但不管怎么说,这样的系统问题也是很明显的:

1.难以获得语言的支持和配合。C++鼓励扁平化的类设计,为什么?说白了就是对非扁平化的设计支持不好。
2.从依赖关系上来说,library manager依赖整个系统,任何使用了library manager的地点,都隐含地依赖整个系统,这回导致系统僵化,难以重构。
3.无法直接创建任何一个接口的实例类,必须从library manager出发去创建。而library manager又不是factory,因此,任何一个组件都无法从系统中单独拿出来考察。这意味着组件隔离做不到,按需创建测试目标代价高昂,单元测试将非常困难和低效。

除了两个给用户的扩展外,Protein的每一个接口,实际上只有一个实现类--就像Pimpl的接口和实现那样。然而,和Pimpl不同的是,Protein的接口和实现类的功能不是一一对应的,接口功能只是实现类的一个子集。这就导致一个很大的问题,在Protein的实现代码中,拿到一个接口指针,第一件事就是Downcast成其对应的实现类对象。这是典型的抽象不足的表现。然而,我们是缺乏API重构的权限的。事实上,大多数项目都缺乏此权限。我当然理解API变化会影响客户代码,但是我不明白,为什么在项目早期也不鼓励改进API呢?我坚信,没有人可以在不写实现代码的情况下就设计出足够好的API来。

另外,因为完全依赖C++的接口,在C++中就不可避免地要返回接口指针,如何维护这些返回对象的生命周期就是要慎重对待的。当然,如果有统一的约定,情况还好些,可惜Protein并不统一,所幸问题到也不很严重。Protein的实现完全是构建在FBX之上的,因此了解FBX也是必要的。FBX当中有一些质量不错的东西,但是也有大量不可理喻的东西。我不了解FBX的历史,倘若FBX最初写于1995年前,我觉得这就是一个不错的东西,如果写于2000年,那就平庸得很了。这让我想起AutoCAD的2D引擎Heidi。很多人对Heidi表示不屑,但是如果考虑到那是在80年代一个人搞出来的东西,就不能不表示尊敬,Heidi达到了它那个时代业界的最高质量标准。即使放到今天来看,Heidi所表现出的简洁性、一致性、严密性仍然是值得称道的--尽管已不符合当今一些人的口味。

除了接口,Protein的实现质量在我看来也是很糟糕的。各种special case--我就不知道有啥不包含特例的--对我这样的人来说,记忆这种逻辑不明的东西就是个噩梦。大量的代码逻辑复制粘帖自FBX,以至于读代码是完全不知道在干什么,性能也很糟糕,各模块的交叉依赖简直是做到了极致。另外,Protein还附带了一些渲染处理,界面工具,而非仅仅是一个数据模型和包管理。这种混乱的层次关系也让我对Protein很是不喜欢。Protein唯一值得表扬的就是,它确实做了一件用户需要的事情,用户也确实在用。因此,我认为无论如何,Protein比ADP强。特别地,当有人拿ADP和Protein做比较,说Protein质量差时,我都忍不住要反驳:Protein很烂,但是有人离不开它,他有用;ADP不那么烂,但是所有人都不想要,恨不得扔掉它。至少从我的角度来说,我希望ADP彻底消失。一来可以使用了它的那些软件免于腐蚀,二来可以掩饰我的失败。

Protein所谓的材质(Material),实际上是一个属性集合对象(差不多是这样,Protein管它叫Instance)不同属性可能有不同的数据类型和值,某些属性还引用了另一个Instance。Instance中的属性值有些可以改变,有些不能改变。Instance不能添加或删除任何属性,因此,每个Instance都从一个模板--叫Definition--clone出来的。可诡异的是Definition没提供接口去访问其中的属性,要想查询,先clone一个Instance吧!想修改,没门。到了2011年,我们还搞了个叫Schema的东西,专门定义Defintition/Instance有哪些属性,属性的数据类型,默认值等等。这种三层的结构实在是让人头疼到爆。然而,我们无权更改API。

我不想再去吐槽那些让人抓狂的错误设计,毫无营养可言,回忆它们也不能从中汲取任何有益的教训。我每次在代码上受到挫折时,就到那个ADPLite上写一点代码,舒缓一下心情。然而写不了几天,我就又要开小差了--我都不在ADP干了,写那玩意儿干啥--去尝试和验证各种新鲜的想法,甚至就是学习。然而,在这断断续续大半年的时间里,我发现也积累了一点代码。我厌烦了牵挂这么个东西,想做个了断。

添加评论:

 
 the email would not displayed
 

您可以使用 Markdown 语法。

您必须启用浏览器的 JavaScript 功能才能发表评论。