昨天在继续之前中断的项目的时候，发觉像是在看天书，虽然中间仅中断了短短的两周。然后在使用用数据线进行调试的时候，发现之前的设计实在混乱，有些地方我简直不知道当时是如何考虑的，简直是另一个我了。
简单说下项目的情况，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，测试，再测试。当这样的代码输入太多的时候，以为自己成了神人，可以让手指自己去凭着感觉输入，这实在是太高估了自己。这在以后必须进行反省，并努力进行改正。