krproject开发进展（十二）

这篇应该不属于krproject的开发进展内容，但绝对是属于krproject的文章，暂没想好区分，索性放在一起了。

过去的这两个礼拜，对krproject来说，也应该算是个值得纪念的日子吧，准确的说是krproject的首秀！虽说之前krproject的前身已经在某国有大行成功实施，但彼时的系统受环境、政策等因素限制，相对于后来改版后的krproject，性能和易用性都有较大的差距。但是新版的系统，毕竟一直都是在我的虚拟机里或者公司的测试机上默默运行，一直没有机会拉出去晒晒太阳~

上两个礼拜，偶然的机会，krproject得以小试拳脚，结果还是很令人满意的，虽然在实战时还是暴露了自身的很多问题和不足，但是初出茅庐的它竟然在性能上有比其他同学高出近百倍来……，它的小巧、简洁、语义清晰等特性也是让人眼前一亮。

看到它有一天终于开始要发光发热，想起一路磕磕盼盼的走过，也曾受过质疑与挑战，却依然固执与坚持。这一刻，会觉得它是个争气的小孩！嗯！

好了，牛就吹到了这儿了。老实记录下krproject首秀过程中暴露出的不足吧：

最大的问题俨然是出在rapodbc身上，当时作为取代embedded sql的小工具，花了几天时间，但并没有详细测试过，尤其是插入和更新是有问题的……，修改完善后，发现又没有实现错误信息的获取，也是让我吃尽了苦头。代价就是最后性能测试没有得到完美表现，真是遗憾……！所以基础小工具的完善绝对是搭建大工程的最重要基础，一点不可马虎。

其次就是上次重构后的遗留，上篇日志提到了重构，其实每次代码重构都藏了一些坑，里面有诸如：增加KR_TYPE_LONG类型后，运算器模块没有包含及时更新； 集合改为动态加载后，运算器模块相关type/value的获取方式调整； 统计量整合后，线程上下文的清理机制等等。

再有就是线程池的broadcast机制了，这倒不难，我也是在那几天时间里，将他实现了，但其实我很早就想将我的线程池再完善一下了（在读nanomsg源码的时候），结果一直拖到节骨眼上，才临时上了个人认为实现的不够完美的版本。

最后还是日志信息，我对现在的日志打印还是不满意，不能简洁直观的反应问题所在，这显然不利于寻找和解决问题。

以上的这些都会是下阶段krproject的完善工作。