All Stories

状态不好狂出错

  今天写代码,出了不少错,都是很低级的,状态不好啊。  先是连接一个MySQL数据库,从一个表中Select一些记录出来,死活没数据,还以为是SQL语句有问题,用其他客户端去运行,发现SQL语句是正常的。然后换了一条SQL语句,同样是Select的,发现又可以了,一步一步排查,发现是那个表中查不到数据,另外一个表中查得到数据,突然发现原来我连的MySQL地址不是我想要的那个!  接着是从XML格式的配置文件中读取配置信息,发现有的配置项好像怎么都读不出来,一直都是使用默认的值,后来才发现在判断值是否为空的时候,多写了个感叹号!  好不容易磕磕碰碰地调试通过了,编译了一个Release版本,用Inno Setup打了个包,放到目标机器上去运行,发现居然没反应,而且不巧的是我什么调试手段都没有,也没有什么日志。后来通过MessageBox发现,似乎配置信息读取又有问题了。然后发现如果是直接用Debug版本是正常的,于是想调试一下Release的,结果不知道应该设置什么选项,调试不了!只好通过OutputDebugString来打些信息出来。经过一番搏斗,发现原来我把装载配置文件的那条语句外面套了一个ASSERT,我狂晕!  以我现在的水平,状态好的时候,最多一个月也就能产1w行代码,而且代码质量还不能保证,唉,怎么才能让新写的代码跑得稳定呢!

准备使用Boost.Logging

  今天在Boost的邮件列表里看到有人在项目中使用Logging v2,这是在去年3月时提交Boost后review拒绝的一个库,当时我也略微关心过,因为一直在找一个好用的C++日志库,最后看到被拒绝了,我也就有点死心了,用起log4cxx来,其实发现log4cxx也不是那么好用,而且最近公司里用的时候发现似乎会有内存泄漏的问题。  看到邮件列表里那人对Logging的评价很高,我就心动了,它有一个优点是header only,这是我很喜欢的一点。其他的灵活性之类的我也没用过,也不好评价。不过我决定了,先在自己写的这些程序中试用一下。

史上最难用Win32 API

  啊,非SHFileOperation莫属!今天要实现个文件夹复制的特性,于是就想到这个API,可是很不幸,无论我怎么整,都报个1026错误!从网上找了一圈,发现代码根本一模一样的,人品问题啊!  后来在花费了不知道多少时间后,也许是1小时,也许更多,等不及了,花了10分钟自己用递归写了个函数来实现文件夹复制,我吐血三升!

boost svn中也有编译不过的代码

  回到家,习惯性地更新了一下boost svn中的代码,从来都最多只看一下哪些文件更新了,至于具体更新了什么内容,却从来没有关心过,也不是我能关心的。  然后整了一下自己写的一些代码。  再之后是继续整前几天放假时写的一个小程序,结果突然发现编译不过了!开始还怀疑该不会是VC出问题了吧,重启了一下VC,没用!于是看了一眼出错信息,定位到出错代码行,是boost::signals2中的一个叫signal_template.hpp的文件中。众所周知boost的代码只有超人才能看得懂,而我很幸运地不是超人,所以就看不懂啦!折腾了一阵,也没有办法,后来猛然看到这代码中明显是语法错误嘛!我猛烈地faint啊,原来超人也会犯错儿呀!尝试了一下把这语法错误修正,结果编译时报的是其他地方的错了,这我就不晓得是什么原因了。无奈之下,为了能正常编译我的程序,只好回退到之前一次提交的内容去了!  目瞪口呆!

鼠标手势算法

  今天看到一篇文章,讲鼠标手势算法,觉得有点意思。现在不少软件都有了鼠标手势支持,尤其是浏览器,几乎成了高级用户的标准配置了。  这算法分为4步。  一、过滤鼠标移动动作。如下图所示,这步过程把一连串的鼠标移动动作中幅度过小的动作过滤掉。这跟系统配置也有点关系,不同的配置下,记录鼠标移动的速率等量纲有所不同。   二、限制鼠标移动方向。如下图所示,对于简单的鼠标手势支持,只支持上下左右4个方向,就把其他方向的动作都归并到这4个方向中。一般就是比较一下上下方向和左右方向的差值,取大的那个作为最后的方向。   三、简化移动方向序列。如下图所示,这步非常简单,原本是右右上上右上上的方向序列,简化后变成右上右上了。   四、匹配和推演。这步是最困难的,表面是把夹杂在长距离移动动作中的短距离动作过滤掉。大概的做法是先把整个动作序列与一组预定义的序列匹配比较,如果匹配失败,就把这序列中最短幅度的动作过滤掉,再进行匹配,如此循环往复,直到最后匹配到为止。

提高软件生产力

  提高软件生产力,意味着可以在更短的时间内交付质量更好的软件产品。软件生命周期的各个环节都对此有着极大的影响,而从开发人员的角度讲,有几件事是力所能及的。  一、提高代码产能。单纯的代码生产力,比如一个开发人员原本一天能写100行代码,经过一段时间的学习和锻炼,相同规模相同难度相同质量的代码,只需要半天就可以完成了。  二、提高代码质量。这个质量指代狭义的稳定性、鲁棒性,代码bug少。这一方面也是通过学习、锻炼可以获得此类能力和经验,另一方向,引入合适的工程方法,比如TDD等良好的实践,也有一定的效果。  三、发扬“拿来主义”。现在可以从各种渠道获得并使用的代码片段、函数库、类库、框架、组件、中间件、软件等等不计其数,并不是所有特性和功能都要自己着手开发实现。只要代码功能满足实际需要,质量在可承受的范围内,可维护性也过得去,以及license没问题,就拿来直接用吧。可重用的,不光是代码,还有架构、设计思想等。形式上,无论是源代码复用,还是二进制组件,都可接受,甚至可执行程序也可以。  四、提高代码复用性。自己写过一遍的代码,尽量不要写第二遍,复用吧!代码重构一种使得代码得以提高复用性的不错的办法。  五、提高架构可扩展性。为了更快更好地实现后续新增需求,高可扩展性的架构是一个良好的基础。可扩展性的对面是可裁减性,假如有一天突然要求去掉其中的一些特性,这种情况也是存在的。这点对经验的要求和依赖比较高。  六、提高架构和代码的可修改性。需求发生了变更,或者原本对需求的理解就有问题,或者发现了bug,这些情况都需要对代码进行修改,别因为一个功能上的小改动而引发代码上的大改动。  七、使用先进的工具、方法和流程。比如眼下流行的敏捷,使开发流程减少僵化。使用优秀的IDE,智能感知、重构、自动代码生成等等。使用版本管理工具,定期对一些代码进行指标度量。  八、宽松、舒适的环境。环境好,对开发人员的身心都有好处,长期收益极大。  九、快捷、方便的求助渠道。向人请教是一种很省事的方法,但很可能影响其中一方的状态。上网搜索则是另一条有效途径。  当眼下软件生产力严重不足的情况下,这是仅剩的几件我能做的事了。

被屏蔽了

  历经约2年的安逸生活,blogger终于又不能访问了,这次的决绝,让我惊异和始料不及,这次似乎不是伟大的GFW动的手,而是人家服务器端直接自己被我屏蔽了,悲叹啊!  命运不能掌握在自己手中的感觉,实在太不好了!

口水仗

  这两天看到TL里从MFC讨论到boost,无论是MFC还是boost,支持和反对的人都有,大打口水仗,我也是个不小的愤青,也去凑合了几下。  因为在公司里的项目用的基本上就是MFC,其中也穿插用了不少boost的东西。说心里话,至少目前我对它们没什么不好的印象,对于boost更是有种赞赏的感情,它在C++语言的基础上创建了那么一个通用的可移植的庞然大物,确实为我节省了不少工作量,这是最让我高兴的原因。  TL上的口水仗最后也沦为抓住一丁点儿瑕疵穷追猛打,实在无聊得紧。在我看来,这么一个东西,它确实对我有帮助,也许节省了10%~20%的时间,这就足够让我继续坚持用下去了。

boost::signals的应用

  今天跟一个同事讨论起在项目中使用boost::signals,发现有些情况下很适合,比如我们的程序有时候会做些耗时的操作,而且这些操作过程中可能会去访问子窗口,而子窗口却不一定继续有效,于是可能就会有问题了。原来的办法是保存好这些子窗口的句柄,然后给它发消息。但有了signals就可以稍微做得更好一点,把子窗口的类从boost::signals::trackable继承过来,这样子窗口对象销毁时,会自动把它从信号槽中移除,不再需要自己费心管理它是否有效。另外一点的好处,也是boost的各种类惯用的手段,做为回调,只要签名相同,即有唯一确定的返回值和参数列表,而不用在乎它最终是什么形式,全局函数也好,仿函数也好,成员函数也好,都可以作为回调。  从1.39.0开始,boost中有了signals2,相比signals,它有不少改进,但在我看来最主要的是线程安全和header only。其他的用法倒还是和signals一样。不过无论是boost::signals还是boost::signals2,似乎都没有办法解决一个问题,就是Windows GUI的多线程操作。还是得另外想办法啊!  烦躁!