走自己的路

路漫漫其修远兮,吾将上下而求索

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  50 随笔 :: 4 文章 :: 118 评论 :: 0 Trackbacks
 

昨天下午被老大喊去谈话了,主要还是对近半年的一个工作总结,一些体会,和一些建议。

这半年主要完成了2framework,参与了整个开发流程,完成了它们的需求,设计,开发,测试,支持,维护,文档整个流程,我一直也在问自己什么样的框架是一个好框架,我想我首先其实也是一个framework的用户,我们写framework的也不会什么都从头做起,重复的去发明轮子,已有的framework也会拿过来用,这会减少开发的成本和周期,所有framework的目的都是方便application developer的开发,方便他们的使用,对于他们来说framework完成技术的细节,他们只要关心业务的逻辑,而且这些framework用起来都要很简单,简单的使用,完成强大的功能。当然framework的可重用性也要很强,不然framework只能给每个特定的application使用,这就和application自己开发一个framework就没有区别了,所以framework还要考虑到各个项目的可重用性,在某些特殊的情况下,framework也不可能满足所有的需求,这时application用户就需要在framework上加入他们的特殊的逻辑,这些逻辑是特定于这个application的需求的,不是通用的,这时候就要求我们的framework是易扩展的,插件式的,还要注意的是虽然我们已经做到了这些,但是如果我们开发的framework跑起来的时候,如果性能很差,影响了application的正常逻辑,这也是致命的错误,所以我们还需要关心framework的性能,这可能比application关心他们的性能更为重要,因为一些复杂的技术细节是由framework完成的,复杂的技术使用起来可能消耗的资源比较多,我们的framework又是给所有application用的,如果性能太差影响范围也很大,如何来提升framework的性能也是至关重要的,至少我们要追求我们的代码质量,每一行代码都要细细品味;可读性当然不能太差了,framework的源代码,application是可以从clearecase或者maven上获取的,对于一个developer来说可能更习惯于看代码而不是看文档,所以代码和测试就是最好的文档,在开发消息集成框架的时候,也体会到了单元测试的重要性,如果什么问题都放到集成测试的时候去测的话,修一个bug可能要花半天的时间,所以单元测试也是很重要的,到目前为止,我还是不能完全做到测试驱动开发,一个是因为schedule定的比较紧,自己写测试的水平也不够到家,所以有时我也会冲动的先写代码逻辑,但是事后我也会补上我的测试代码,因为自己在看一些开源framework时候,一下子也不知道每个类是干嘛的,所以就会先看测试,从测试中去了解程序的逻辑,测试其实也是一些小的sample,可以指导developer如何去使用,所以详细的单元测试是免不了的。细节上的实现需要注意的就更多,比如我们公开的api是给application用户调用的,如果一个api是发送消息的,你取得名字是和发送消息无关的,application用户使用起来就比较麻烦了,他们可能还需要打开很长的developer guide,来找哪个api可能完成发送消息的功能,如果找不到,他们就会call你了,那自己不是自找麻烦吗,所以每个publicapi名字一定要取的简洁明了,开发上的每个细节都要注意,细节决定成败,实现模式出中文版了,这本书明年还是要翻翻的。Framework是写完了,满足了这个版本的需求,但是developer会有一些反馈,比如哪里用起来不方便,哪里还是不能满足要求,或者又有了什么新的技术也需要加入到framework当中等等,这时我们就要去改代码了,改代码是很头疼的一件事,我是这么认为的,而且改了一行代码,什么东东都要重新测一遍,这就不说了,但是如果时间很长的话,我们可能对一些代码的实现细节,甚至对哪个模块该干什么已经忘得一干二净了,所以就要求我们写的framework的可维护性要比较强,开发人员发现问题应该比业务用户强多了,那就更要求我们的代码要高内聚,松耦合,满足这些OO的原则,加上很好的模式设计,使我们的framework更易维护,重用,扩展,重构等。写的很乱,想表达的就是写好一个framework需要注意的问题,呵呵。



posted on 2008-12-16 07:42 叱咤红人 阅读(267) 评论(0)  编辑  收藏 所属分类: Life

只有注册用户登录后才能发表评论。


网站导航: