昨天下午被老大喊去谈话了，主要还是对近半年的一个工作总结，一些体会，和一些建议。
这半年主要完成了2个framework，参与了整个开发流程，完成了它们的需求，设计，开发，测试，支持，维护，文档整个流程，我一直也在问自己什么样的框架是一个好框架，我想我首先其实也是一个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你了，那自己不是自找麻烦吗，所以每个public的api名字一定要取的简洁明了，开发上的每个细节都要注意，细节决定成败，实现模式出中文版了，这本书明年还是要翻翻的。Framework是写完了，满足了这个版本的需求，但是developer会有一些反馈，比如哪里用起来不方便，哪里还是不能满足要求，或者又有了什么新的技术也需要加入到framework当中等等，这时我们就要去改代码了，改代码是很头疼的一件事，我是这么认为的，而且改了一行代码，什么东东都要重新测一遍，这就不说了，但是如果时间很长的话，我们可能对一些代码的实现细节，甚至对哪个模块该干什么已经忘得一干二净了，所以就要求我们写的framework的可维护性要比较强，开发人员发现问题应该比业务用户强多了，那就更要求我们的代码要高内聚，松耦合，满足这些OO的原则，加上很好的模式设计，使我们的framework更易维护，重用，扩展，重构等。写的很乱，想表达的就是写好一个framework需要注意的问题，呵呵。