Archive For 十二月, 2008
最近工作重心转回code，虽然比传说中的码农层次稍微高一些（个人感觉啊），可也相差无几。真正参与（设计、开发）的第3个项目，公司产品的3.0版本，分为模块化的开发，然后大家将各自的模块做一个组合。要说的是关于在这几个项目中关于测试的感受。 这里啰嗦几句，跟主题无关。最近老看到一些什么“大公司做人，小公司做事”的论调，相当不以为然，调整好自己的 心态无论做事还是做人，真最重要。虽然自己没能做到”像随时要离开一样做好准备，像永远要留下一样用心。”但是 还是尽量认真做事，认真做人吧。 好了言归正传。同事L曾戏说，我们真正把客户当做我们团队的一部分，由他们负责来测试。我想这个是由于欠缺规 划，或者是协调的不合理的原因。时间紧固然是一个因素，但是我也从来没见过暴雪因为时间紧就让玩家来测试的， 他们宁愿担着跳票带来的风险也要践行“暴雪出品，必属精品”。 没了解过专门的测试团队是如何工作的，但是个人觉得这个不光光是测试本身的问题。 为什么需要测试？提高软件质量，给客户提供优质服务。软件质量是由软件整个开发生命周期决定的，从需求分析， 到概要设计，到编码，到单元测试，到集成测试。每一环都会影响到软件质量。
前段时间（前2个礼拜），忙着给一个基于Web的绩效管理项目作Close，这个项目其实是一套管理类的软件，而Close的工作实际上就是给做那个项目的二期。在项目现有的代码上增加一些功能，比如很简单的一个例子，以前有一个月度的考核，现在需要一个年度的考核，年度的考核基本上跟月度考核一致，如果熟悉面向对象开发的或者了解设计模式，一定会很自然的想到一个叫“模板”的概念，通过抽象来重用、重构软件。问题来了，年度的成绩有很大一部分来自月度考核的结果，好吧，再抽象出一个成绩的接口，由这个接口去负责取考核结果，想法很好，可是你行不通（当然这些更应该在设计之初就考虑的问题）。 这个项目是构建在一个自定义的框架上，为了提高开发效率，框架作了很多工作，开发者只需要调用指定的方法就能完成诸如控件绑定、数据库访问等一些内容，为了进一步减少工作量，有一个小的工具软件专门负责生成数据库访问相关代码，当然有的必有所失，这框架最大的不足就是对类、接口等有很多的限制。