反省,激进中的失误

昨天在继续之前中断的项目的时候,发觉像是在看天书,虽然中间仅中断了短短的两周。然后在使用用数据线进行调试的时候,发现之前的设计实在混乱,有些地方我简直不知道当时是如何考虑的,简直是另一个我了。

简单说下项目的情况,j2me项目,移植到C平台,j2me的项目,经过了N个人的手,所以,里面各种各样的代码混在一起。简单的C封装,当时可能同时在考虑其他项目上的事情,再说了,这种对平台的封装,和对j2me的熟悉程度,我可能当时边敲代码,边在想着手机网游的架构了,很有可能还在考虑BREW程序的更好的移植结构了,总之,一堆杂烩又添加了些新料杂烩到一起了。

在画面的显示当中,有些内容显示错误了,直观上的判断就是描绘的时候,所描绘的点超出了图片范围。在j2me中间,早期基本上使用下面的代码进行局部描绘:

       g.setClip(x, y, w, h);
       g.drawImage(img, x - u, y - v, Graphics.LEFT|Graphics.TOP);
       

对于我这边的C项目,系统不支持setClip的机制,刚开始做的时候,偷懒,就简单的不做setClip吧,不过,倒是可以进行局部描绘,于是,就简单的用C操作了下,但是,这样以来有了另外一个问题,如果在外面设置了clip的范围,然后调用drawImage的话,原始程序可以将后续的描绘操作放入一个矩形中,但我的不可以。那么,还是需要一个clip机制吧,反正也不难,于是,手动添加上clip机制:首先创建全局变量,然后在描绘的地方检查全局变量所定义的范围,然后重新设置描绘的范围。这本来是件简单的事情,就像上面所提到的,这个项目经过了N个人的手,每个人的命名风格,代码风格,思考的完全不一样,有些代码的添加仅仅是为了够用就行。即使对于上述的简单操作,在实际使用的地方,都调用大量的算法机制来调用,导致一眼看过去不知道到底在那部分是x, 哪部分是y,哪部分是u,哪部分是v,而我,这是简单的看了一下,然后大致的猜测了下x,y,u,v(当然,这部分是在添加clip机制之前)。然后,悲剧就发生了,两个代码发生了冲突,这种其实是粗心的错误,描绘的部分在一些情况下,通过setclip计算,在图像上的坐标变成了负值,然后,一切皆有可能了。当然了,对于大部分的系统来说,如果发生这种情况,很可能会直接重启的,内存保护起到了作用,不幸的是,我的这个平台没有这个机制,所以,一切正常,只是描绘错了。

这让我想起了小时候的关于数学的两件事情,我小时候其实对于计算器什么的科技玩意很感兴趣,那时候觉得计算器就非常强大了,可以算很多很多的数字,什么加减乘除都不在话下。然后,有一次做应用题的时候,为了赶时间,我就是用了计算器,结果,那次的作业做的一塌糊涂,因此,要合理有序的使用这些高科技设备是必须的。另外一件事情就是虽然小时候数学还算不错,自认为已经属于非常优秀之列(那时并未接触什么奥数之类的残酷竞争),但每每数学考试,却难以得到满分,往往在某个地方少了小数点,或者粗心算错什么的,更经常的是,前面都对,最后一步错,一失足成千古恨。这一恶习,想起来都懊悔,但屡改不掉,所幸的是,程序有修正的机会,但诸如考试之类的,只能随它去吧。也因为知道自己的恶习,每每在自大的时候,出现问题的时候,告诫自己,是自己错了,要先检查自己。这次也是这样的错误。

项目继续进行,在添加某个界面的时候,我发现当选择了某个选项,设置了某个标记,但总无效果,而我记得,之前文件保存之类的已经完全解决了阿。于是就检查了再检查,还是如此。然后,就决定让自己静下来,回想下从开始到最后的整个过程,记得在某个地方对变量判断的时候,应该使用==的,使用|是会出错的,对于按键的定义,我习惯于使用移位标志来进行判断按键状态,但别人并不一定这样,于是,查看下定义,果然不是根据移位来判断的,于是,修改为==,测试通过。

在很多时候,在设计算法,架构的时候,都会先在纸上列出重要的步骤,代码,然后再在电脑上输入代码,测试,查找bug,测试,再测试。当这样的代码输入太多的时候,以为自己成了神人,可以让手指自己去凭着感觉输入,这实在是太高估了自己。这在以后必须进行反省,并努力进行改正。

发布者

rix

如果连自己都不爱自己,哪还有谁来爱你