数据“质”与“量”

05月

333 0 0

博客：paladin career

　　这次我想表达的意思是：在程序的开发阶段，即便是最初期，测试用数据也应不光涵盖合法、微量的数据，还应涵盖相当多的非法、海量数据，以检测代码应对从优质到劣质，从微量到海量数据的能力。如果你对第一句话深有所感或不以为然都可以忽略下文以免浪费时间在里头了。

　　最近datatree在L同学的C++反射库序列化部分跑了起来，他给我的反馈比我预想的多（我不该对自己太有把握了）：datatree输出的字符串如果很长（500KB以上），输出时间将漫长到让人昏昏欲睡；datatree亟需SAX风格API弥补DOM风格的种种缺陷……关于长字符串的问题是因为输出的API频繁调用了几个会对字符串遍历的函数，如strlen、strcat。解决办法就是不用C语言基本的char*做字符串，改用存储了raw缓存和字符长度信息（还有raw长度）的struct，这样差不多O(n*n/2)的时间复杂度变成了O(1)。原来写那几个函数的时候就隐隐的感觉有些不妥，但当时却疏忽的没有反应过来究竟哪里不对。看来使用字符串库非常弱的语言一定要做些基础封装才用得踏实。对于一些不需要datatree DOM数据结构的需求，比如三维模型定点信息（得到的数据最好是原生定点数据数组而不是带类型信息的datatree节点信息数组），使用SAX会免去很多不必要的中间处理步骤，时间和空间上都有节省。SAX的另一个特性是可以实现成不把整个数据都从磁盘读到内存并解析出中间数据结构，而通过流的方式解析一点给一个回调事件，但datatree设计面对的数据并不包含大到连先将未处理的数据从磁盘预读到内存都舍不得（对一定量的数据整块读取比片段读取要好得多），所以计划datatree的SAX风格API将只是取消datatree数据结构的创建，给出解析回调，只做内存流读取，不会做磁盘文件流读取。

　　去年对伪数据驱动毫无技术含量的吐了个槽，数据驱动的程序模块（不管数据源是啥）要处理的数据错误情况怎么样，数据量怎么样都是设计者在最初不能预知的，但是设计者可以去拟定程序的适用域和规格，并标识出来（明确到能让不认识甚至根本联系不上设计者的调用者容易的发现）。就像电子器件的额定电压电流阻抗功率抗干扰性能说明书一样。

　　不管是不是本意，我周围的大多数程序员都知道测试用例的重要性却基本没人做到过测试先行。也许我们的内心反感与实际业务逻辑代码无关的东西，也许我们总是借口没空，哦，是的，没空写测试，没空写文档，没空写注释，没空与人交流心得，我们最不缺的就是这些个理由。对于一些有把握的东西，不写测试代码和数据是不会有太大的问题的，如果模块接口设计良好，规模不庞大，即使模块内出了问题再去修改的成本也是可以接受的；对于一些对数据（质与量）敏感的代码，在构建初期就先准备好足够覆盖大部分额定适用域的数据比较好。偶尔试试磨磨刀不会误了砍柴功。如果我在写datatree的代码前能把测试数据都写好应会少走几步弯路。

　　若不是亲身造几个轮子，一些感悟要花费更多的精力甚至是代价才能领会。

　　额。是真的吗，你竟然看到了这篇无聊的文字的结尾。我从来没有期望过有谁会读全我的文字，至少我写的时候没有期望过。互联网上每天产生的信息如此之多，以至于我倒觉得把时间花在看一个草根程序员的各种牢骚上面的人可能都是一些比我还无聊的同行吧。不过，谢谢你，让我在无聊的时候不会太孤独。虽然如果我的文字能引发你的思考我会非常高兴，但同样的我不能去期望或顾虑什么。我觉得，这一切就像svn的log message，不能像代码一样驱动一个世界的运转，甚至不会让计算机里的各种电阻们发热，也许log进去后就再不会有人看上一眼，我却如此执着；时间有别于svn，无法做branch，commit进的也不能revert，只能一次成型，想来这比写代码刺激和过瘾；你我能做的，就是不断的跨过一个个里程碑，期待属于自己的release。

锐亚教育

标签：魔兽开发经验爬坑游戏开发者开发技术游戏开发论坛

你还没有登录，请先登录或注册！

还没有人评论，欢迎说说您的想法！