第一年工作小结

工作一年了，一直在做一个C/S项目，涉及网络通讯，多线程，缓存管理，貌似没别的了。项目框架用MSH（mina，spring，hibernate），自己大部分时间都在做沟通，需求分析明确，模块分析，代码这块的时间花的不多（我完成底层几个基本的模块和组件后，交给同事做具体业务模块）。
开发过程中用到了不少设计模式和编程思想，比如客户端的数据轮询模式改变了传统的会话轮询，转而向自己客户端的缓存轮询（好处是降低了服务器的响应负担，提高了客户端的响应速度，因为轮询会话造成了服务器大部分资源都用于响应客户端的请求，而不是在处理业务，这个设计是借鉴了淘宝客户端的设计），根据项目的需求用到了几个常见的设计模式，什么单例模式，指令模式，适配器模式，代理模式啥的。编程思想AOP在项目中也有体现，主要是放在身份验证这一块，别的东西主要体现在依赖接口调用实例的方法。
spring主要还是用它的DI功能，太强大了，偶尔研究了一下它的一些源码，真心觉得spring是个好东西，很多设计模式和编程思想在它里面被用的淋漓尽致，最明显的地方是用AOP去补充OOP的不足。
mina这块倒是没有太多深入的研究，只是让它帮忙处理socket一些比较繁琐的东西，自己把大部分精力放在了协议定义，数据解析，会话管理（会话管理是最耗精力的，因为中间引入了消息应用，需要对会话进行主题分组，消息通知，而会话除了做这些，还关系着业务数据的传输，客户端业务数据传输和消息都共用一个会话，中间遇到了业务数据传输不全，缓存溢出，粘包啥的，搞得焦头烂额）。
hibernate就用它来生成表，做事务管理，别的没了，因为业务的hql这块儿不是我负责。
缓存管理就遍及整个项目了，有些缓存是即用即清，例如业务数据传输；有的是用了不清，例如消息，多个主题的多个消息的更新会在客户端保留，而服务器端这块只会保留主题的最新消息，不同模块间的消息通知，同一模块不同客户端通知，多个模块多个客户端通知都涉及到会话管理和缓存管理。缓存的基本设计思路是做好一个并发访问同时支持泛型的抽象类模板，然后让不同数据类型的缓存器继承这个模板，这个模板提供了一些基本的操作，比如CRUD。因为我没办法做到让所有的数据类型都支持并发访问和数据同步，所以就模仿spring的HibernateSurpport做了一个也支持泛型的针对缓存访问工具，用于同步缓存里面的对象访问，这个有点像是JDBC的数据库连接管理，一个时间内只能有一条线程去访问这条连接，它的设计思路比较简单，利用回调方式和缓存模板中的同步标识做CRUD控制。
多线程就只是简单用抽象类实现或者用自定义接口继承runnable，再创建一条线程放入到自己配置好的ThreadPool中(这个线程池是java自带的ThreadPoolExecutor，自己简单做一下配置而已，比如线程执行失败或者出现中断异常如何做处理)，感觉多线程这块真的很难搞，协调多个线程能正常工作绝对是对模块设计和代码设计的极大考验，自己在这方面还是很菜，希望新的一年能够有所长进。
前面说的网络通讯，其实也就只是用到了tcp和udp这两个而已，tcp的可靠性用来做业务数据传输，udp高传输性能用来做文件传输（考虑到大文件的实时传输，比如语音，视频等），实际用到的通讯技术不多，也不复杂，本来想用更多的通讯技术的，无奈技术有限，没办法做，只能在原有的基础上做拓展，比如消息群发，我是通过会话管理分组方式实现的。
项目中还用到了反射这个东东，虽然很耗性能，但也没有办法，spring的对象创建方式满足不了项目要求，所以只能自己利用反射创建一个对象工厂，自己实现对象创建和DI，这方面的设计方式是自己定义好接口，然后让相关的javabean和控件类去实现，接着模块指定自己需要的控件名称拿到已经配置好的控件。
这一年的最大体会就是，软件项目开发不仅仅是技术问题，更多的是沟通问题，尤其是不同专业背景的人在一块儿做开发，我们主管是非计算机专业的，不懂编程原理和代码，要和他做好沟通才能继续工作，沟通过程需要给他解释设计理念，设计模式啥的，很是考验自己的表达和沟通能力（PS：我在学校基本都是做自己的，自己怎样理解就怎样做，团队沟通这块儿有一些欠缺）。同事相处这块儿的话倒是没有大问题，不过有时候会被吐槽代码写的太抽象，看不懂为啥要那么设计（木有给他们看我的设计图和设计说明）。总的来说，这一年感觉自己沟通能力这块儿的进步大于自己技术的进步，希望在下一年里面有更大的进步，而不仅仅是技术。