C++博客-春暖花开-随笔分类-日常总结

及时总结很重要

Sandy — Tue, 16 Nov 2010 15:34:00 GMT

发现许久没有来园子里逛了，一来是工作了，的确很忙，二来是手的确有点懒。想写点东西，找来找去，还是对这个园子有感情。

最近发现懒惰真的是一个很容易养成的习惯，它会慢慢吞噬掉一切。就项目而言，压力的确比学生时要繁重许多，但条理性似乎更加重要。随手记下，随时总结总归是好的，一个回头，就不知道什么是时候是个头了。

所以半年多的经验来看，一定要及时的总结项目，要把最新鲜的，最热气腾腾的东西记录下来。
对自己回顾是一个帮助，对他人入门也是个捷径。

养成及时总结的习惯很重要。

Sandy 2010-11-16 23:34 发表评论

一个有关StretchBlt的问题

Sandy — Fri, 04 Sep 2009 10:55:00 GMT

今天遇到了很诡异的问题，最后把症结归到了StretchBlt这里。
尝试了很多方法，最后发现，是图片的大小问题。原图片的大小比较小，而设定图片的宽度和高度时用了很大的值，结果导致StretchBlt失败，从而界面刷新失效。改成较小的值则没有这样的问题。对于这个原因，没有想明白为什么？因为有两个紧挨着的语句都这么调用，在很多机型中都没有问题。但是在特定的机型中就会发生。一次调用成功，两次调用失败。这让人很恼火。

在调试的过程中，设备很容易死机。这么尝试几十次之后，真的有点发疯了。

还好，问题解决了。自己的理由找的也很充分。

但是这对么？
在SDK中，看到有这么一句：
If the source transformation has a rotation or shear, an error occurs. 原图片与设备不相符时，是否会发生剪切的行为呢？我这里只是猜测。

Sandy 2009-09-04 18:55 发表评论

工作总结：新角度来看问题

Sandy — Fri, 28 Aug 2009 08:20:00 GMT

遇到问题的时候，要变换角度看问题，不能只盯着一处。

事情是这样的：我们新发布出去的产品发现了一个BUG，这个问题在测试阶段也遇到过，当时以手机的原因没有理会。但发出去后，发现很多用户使用中也用到了相同的问题。其中也有一款机型我见过。这让我很郁闷。什么原因呢？尝试了用户的操作发现，的确存在这样的问题。

原因还在查找中。所以在遇到问题的时候，一定要多方面的排查问题，不要轻易的将问题放过去。有可能会是一个痛。

生活中也有许多这样的例子吧。所以我们有时没有必要钻牛角尖。

Sandy 2009-08-28 16:20 发表评论

代码审查的思考

Sandy — Thu, 20 Aug 2009 10:00:00 GMT

项目要结项了，自然要进行一些审查的工作。不过我是那个被审查的。审查出的一些问题，还是值得反思的。

一是注释：虽然注释可有可无，但是良好的注释有助于提高代码的可读性。我们写代码的时候，有时候就比较懒，不写注释，或者写大多的注释。有的注释没有及时更新。这些都需要注意。

二是注释掉的代码没有删除。如果少量还好，但是在代码中存在这个问题。可能当时只是在修改BUG时的一个改动，但是修改成功后，应该及时删除这些代码。否则代码不是很美观。

三是一些测试代码依然存在代码中，虽然没有用到，但是让人多了很多迷惑。

四是名字起的不是很规范。

这是审查的那位大师简单一看就提出来的问题。有则改之，无则加勉。多多努力，让自己的代码更加漂亮起来。

Sandy 2009-08-20 18:00 发表评论

UML画图工具

Sandy — Thu, 20 Aug 2009 09:51:00 GMT

最近在做项目总结，其中网络部分的处理比较麻烦，以后交接工作也牵涉很多。于是在下了很大决心之下，决定画一些图来理理网络协议的处理。呵呵，主要是对UML画图不是很熟。

最熟悉的UML画图工具是Microsoft Office Visio工具，以前尝试过，但是总觉得不方便。呵呵，没有用惯，自然就抱怨起来了。于是良方吧。

同事有推荐使用Rational的，不过可惜的是没有装成功。

恰逢公司有培训UML使用的，培训的是一位架构师，还好原来跟他沟通过。他给我了一个小工具，名叫Enterprise.Architect.7.0，这是一个轻便的UML画图工具。刚开始使用的时候真还找不到门路。慢慢摸索发现还是挺好用的。

如果你也跟我有同样的烦恼，不如尝试一下这个小工具。

Sandy 2009-08-20 17:51 发表评论

工作总结：效率问题

Sandy — Wed, 05 Aug 2009 09:01:00 GMT

         最近越来越感觉效率的重要性。为什么呢？
         写程序不仅仅是简单的实现功能。原来写代码时没有注意这些问题，现在暴漏出来了，也无计可施。多个功能再加界面，导致了界面很慢。用户体验不好。所以这需要在以后工作中引以为戒。

         要把自己的代码写的漂亮一些。

Sandy 2009-08-05 17:01 发表评论

工作总结：注意接口的调整变化

Sandy — Wed, 29 Jul 2009 03:58:00 GMT

今天在进行memcpy出现了一些问题。
原因是这样的：
我定义了这样一个接口，里面涉及memcpy操作。

举个例子吧，如接口addItem,
void addItem(int iType, LPVOID *pItem)；

里面有一个对象是TCHAR szStr[512];
我直接进行了这样的拷贝，memcpy(szStr, pItem, sizeof(szStr));
今天就出问题了。提示某块内存无法访问。于是重新看这个问题。为什么会这么写这样的接口呢？
我原先写的是 void addItem(int iType, TCHAR *pItem);
后来由于需求的变化，变成了LPVOID。改成这个以后，原先的字符串wcscpy就变成了memcpy。这个一直没有引起警觉。其实这一步的改变，就应该对接口做相应的调整，接口应该变为
void addItem(int iType, LPVOID *pItem, DWORD cbItem);
增加一个参数来说明pItem的大小。然而这一步没有做。

所以今天的教训就是要注意修改接口的时候，注意相应的变化。

还有是字符串的操作问题，宽字符和ASCII字符串的操作要注意。

Sandy 2009-07-29 11:58 发表评论

工作总结：述职报告的总结

Sandy — Thu, 16 Jul 2009 01:37:00 GMT

昨天进行了上一季度的述职总结，自己也罗列了自身的一些问题，如单元测试不充分，需求理解不透彻，等等问题。领导也针对我的总结提出了几点：
一是一定要重视需求。这个赞同。现在所作的项目频繁的需求变更压得有时不怎么重视需求。这点提得对。
二是一定要重视单元测试。这个赞同，的确单元测试做得不是很充分，就拉上了系统测试，暴漏了很多问题。
三是要有条理。这个赞同。首先我的述职报告条理性就没有别人的好。一二三看起来不是很分明。所以这点以后要多加改进。层次也突出不好。其次呢就是学习要有条理，不能什么都想学。一定要有条理的学习。
四是敬业精神。这个一开始不太好接受。自认为还比较敬业，主动发现问题和加班，敬业有佳。但回去思考了一晚，想想自己还真的不是很敬业，离真正的敬业还是很有差距的。主动发现问题，不只是一个方面，应该是多方面的，比如说原先代码的不合理处，自己清楚，却没有主动提出改进方案。这个不是很敬业。所以以后需要好好改进。

有这么多问题，所以一定要从自身找问题，积极改进。做一个积极向上的好人。

Sandy 2009-07-16 09:37 发表评论

工作总结: 面向对象的思想

Sandy — Wed, 15 Jul 2009 01:39:00 GMT

昨天发现了一个问题,在我们发布的产品中的各个版本都有。这是一个很棘手的问题。还好，已经有人对问题代码进行了优化。
但是问题又出来了，优化的代码的接口变了。这又是问题。
此时我就想把他的代码改呀改，或者改我自己的代码，以便利用他优化后的代码。发现还是错了。

此时，经验丰富的大师会告诉我利用派生，封装。这的确是一个好办法。看来面向对象的思想还没有深入到我的骨髓，不能很好的体会和运用。

这是昨天的一点收获。拿到别人的代码不要着急去改，如果要用的话，要学会派生和封装，否则改坏了代码，维护代价会更大的。
不过收获归收获，代码封装真的不是很好做，我最后还是放弃了。对比代码的不同，进行修改。有些东西需要搞懂原理，这才是根本。

Sandy 2009-07-15 09:39 发表评论

工作总结: 工作要仔细

Sandy — Fri, 10 Jul 2009 08:43:00 GMT

有一个内存泄露的问题，折腾了我很长时间了，这个问题存在，也确确实实是内存泄露了。把代码查了一遍又一遍，就是没有看出什么问题，也想了很多方式方法，似乎也都不见效。
怎么办呢？
今天都在想是不是指针被修改了，造成的问题。
发现少打印了一处，奇怪，为什么没有走到那里？原来前面一个出错判断，我直接返回了，没有走到删除的那一步。哈哈，终于被我找到了。

分析了一下原因：
1、代码的问题。代码处理的逻辑还未负责，对此就有了遗漏。建议利用goto，最后做一些删除的处理。这个道理明白，有时用起来就忘了。
2、用心的问题。应该及早的发现该问题，但还是没有认真的对自己的代码进行审查造成的。所以以后要走到自己的代码里面调，尽快发现问题。

加油！不要再犯了。

Sandy 2009-07-10 16:43 发表评论

工作总结：如何解决BUG

Sandy — Mon, 29 Jun 2009 10:44:00 GMT

今天解决了两个BUG，但是原因都是自身的原因。
第一个BUG是由于修改，一份代码发生了变化，另一份代码没有相应进行变化，导致了BUG的发生。可能你也很好奇为什么有两份代码呢？一个是加长版，一个是缩减版。主要是另一个地方只用到了一个功能，而这个功能又牵涉了一些小函数，都搬过去感觉有些臃肿。但是不搬过去就存在了这种情况，两个代码不统一。

不知道怎么解决这个情况，也只能维持现状，保持两段代码了。不过需要人为的维护代码了。

第二个BUG主要是细心的问题吧。new很隐蔽，导致没有释放，这样造成了内存泄露，进而引发了数据读取的异常。这个类似的BUG见过一些了。内存泄露还是一个值得注意的大问题。所以要好好检查一下代码。

就写这么多吧。

Sandy 2009-06-29 18:44 发表评论