2010年小结

又是一年春荣夏繁秋枯，北京本该来的白雪(就算是白雪吧)却失约未至。我本是一个好总结的人，写总结的习惯已经持续了2年，就算做一个平凡的自传。

我已经在公司供职已经达到三年。还记得毕业后刚刚来到公司不久，没有想象中的入职技术培训，面对公司的支付系统海量的代码头晕脑胀，我不停的在以前的文档中寻找作者的业务思路和编码意图、在互联网上寻找作者的技术理念和实现原理。通过在公司的支付系统项目中学习的关于加密、通讯、分布式、缓存、数据持久、数据库优化、系统调优、需求分析、设计的理念帮助我有效的解决在2010年的项目的遇到的问题。在2010年初期，我主要的任务是根据C语言实现的令牌项目反编译出加密实现算法和通讯协议，并用Java重新实现，因为没有参考文档和代码注释，这是一个繁琐的、让人厌烦的脑力活，最终我搞定了这个需求，而且在正式的项目中使用，这很让我欣慰，没有白忙活一场！后来就和同事开始做改进版的模拟器，这个需求原定的期限是7天，最后在需求和技术的双重阻碍下，我们延期了3个星期才勉强完成：这个需求隐藏着很多以前没有接触过的对账文件生成规则、无格式数据保存方案。但是这个项目让我明白了很多需求往往是从让需求方认为很简单的小需求中慢慢抽出来的，再加上为了以后可能不会需要的扩展性-一个模拟程序能扩展成什么样子-而导致的过度设计，以及开发过程中乱七八糟的问题，这些因素造成了项目的延期。在技术上，我开了眼界，原来模板技术使用起来真的很方便、数据库不仅仅是这些RDMS-NoSQL的数据库使用起来更方便、基于Spring的AOP技术编写的BerkeleyDB的事务拦截器也能做到对开发者而言透明的事务开启和关闭。

作为一个技术人员，在进行系统设计与实现时，往往很多时候过于陷入技术而最后导致忽略了原始需求的误区的描述，应该记住“软件的建设目的是为了让客户和老板爽，实现他们的功能需求才能达到这个目标，而非功能性需求很多时候都是为了让开发人员爽”，在建设系统的时候不要犯反客为主这样的错误。之后就开始公司的支付系统的日常维护与新的需求模块的实现：商户订单业务和邮局直充相关业务。然后从7月份开始了加班之旅，令牌管理平台成功完成是我们团队的胜利，项目初期，我们没有基于web的大型管理平台的页面的实现方案和技术存储、没有struts2的应用经验、没有spring事务托管经验、也没有iBATIS2的使用经验，但是我们在开发过程中通过积极的沟通和技术共享解决了这些技术上的难题，当然神马需求分析如果不面对客户都是浮云……我私下把这个工程分为了2个周期，一个是起始阶段：根据原始的页面原型，团队闷着头编码，第二个是在上线使用后，根据用户的反馈，进行大量的功能添加和修改。一个没有充分需求调研、开发人员在项目初始阶段还是懵懂状态就开始编程，在我们顽强的团队调整能力下把这个几经修改的项目submit了。一个团队不需要技术高手，但是每个成员要擅于和别人主动沟通、易于接受理解别人观点并抓住重点-也就是容易被洗脑……、要有求知的欲望-把围观小月月、信春哥曾哥的时间用来学习新的知识、了解新的技术和其的场景、并乐于将新的知识共享给团队的成员。一个成熟的技术团队要有自己常用的开发模式和工具，合理的代码编写格式，即使不能做到TDD编程，但是良好的代码习惯也利于以后代码的维护和变更，免得一个小小的修改就把测试人员折腾的上蹿下跳。

对于公司的管理，我没有啥概念，但是一个团队不应该管理，而是协作，让每个成员知道自己做的东西的价值，让他们乐于做。“没有人愿意让别人管的，所以你的企图去管人就已经让你进入困境，作为领导，重要不是学习什么管理技巧，而是要掌握正确领导者应有的心态，那就是以帮忙自己下属成功为自己的成功，没有这个心态，你整天只会在一些人际关系里面折腾”（http://blog.qq.com/qzone/117733/1293116643.htm）

在收到监控的需求的时候，自我感觉这是个小case，但是在组团这个需求时，我发现3个人团队实际的进度并没有和我想象中的“如丝般的感受”那样的顺利、轻松，我希望在来年中在技术继续提升自己能力的同时，能够让我所在的团队更有效的发挥出她的效能，这样就能更少的加班，免得影响家庭和谐！