过年后，在目前公司的工作就要告一段落了，又恰逢年终，终觉得还是要总结点什么，来个了断吧~
背景介绍
考虑了一下，似乎技术上没有什么太多可说的，再加上外包项目也不能透露太多客户的东西。3年多做得都是同一个Account（客户）下的项目，是客户产品线下的一个数据中心产品，面向数据中心的基础设施用户，也就是国内IDC。产品提供数据中心IT基础设施运维整体解决方案， 属于行业内KVM交换机顶级品牌， 另一家也是美国厂商, 行业内剩下的就是国内中低端的深圳厂商， KVM over IP 还是较有技术含量的。
该产品有悠久的历史，最早的代码在源码中的标记是10年前， 那时java还处于一个婴儿期， 并没有这么多开源框架支持企业级开发， 数据模型还是用java bean封装，操作方法也在bean中， web层的调用直接穿透到持久层（也就是bean）这里。so，这样的东西有技术挑战么？
遗留项目到底有没有意思？
大部分程序员都喜欢搞新项目，觉得新项目不用吃别的程序员的"狗食"， 能大胆用新技术，很爽。但现在IT信息化已经进行了10几年了，如果是外包行业，基本上接的最多的项目肯定都是维护性项目， 一般企业哪有这么多新项目啊，都是遗留系统。
遗留项目自有它的特点， 首先要吃透该系统的整体技术设计， 至少是宏观上的层面要有个整体把握，然后才能根据客户的enhancement需要来设计，不要破坏已有系统的设计，偏离了原来架构的设计意图，会使软件越改越烂，就是重构那本书里提到的"bad smell"。一旦有这个趋势，要及早处理， 这个技术债越欠越多，维护的人员一批一批的换，到最后没人搞得清楚整个系统的runtime运作，有些公司老产品折腾不来了干脆推倒重来， 然后循环又开始了。
这个就是维护的技术含量了，听说还有个专门的行当叫维护架构师，国内公司似乎还没发展到这个程度。你需要在遗留项目定好的条条框框里辗转腾挪，使劲浑身解数，为了提高产品的一点性能，应付越来越多的数据，保证质量的同时，尽量引入当前比较主流的工具或方法学来提高团队效率。
我们的项目就经历过一次大幅重构：
- 数据库从PointBase内存数据库更换到主流开源库Postgresql
- 引入Ioc（Guice）
- 基于原来的bean方式简单操作重新用JPA封装了持久层
- 由于原来内存库在数据量不大时速度如飞，更换了常规文件系统数据库后必然影响性能，所以加了ehcache缓存，对sql中where语句的查询结果进行缓存
- 2011年时部分复杂操作页面改用富客户端的Flex来处理，提高易用性（那时Adobe还没有放弃Flex）
- 高可用：每个WebApp之间的数据库采用开源方案SymmetricDS来处理，支持异构数据库同步（虽然当前不需要）
还觉得无聊吗？也许。
对于大部分项目机会不能自己选择的业内同行，也许有意思的玩意就在你身边，你觉得是一坨shit的东西仍然能从系统的整个生命周期中，结合当时的技术环境，看到这坨shit的一些有意思的东西，从设计文档里体会当时的设计权衡，考虑。 当然，文档里只有设计的结果，有些妥协maybe只有当事人才能知道，but,这不是重点！ 这里只想说，一个人想提升自己，如果有心，任何时候都可以，只要会发现。
OK，这是enhancement，那bug fix呢？这个更简单，现在如火如荼的开源，所有人去参与一个项目的第一步是什么？
- 看项目介绍，找架构文档，有个初步认识
- 订阅maillist，在里面浑水摸鱼，继续了解项目
- 去项目的online bug tracking上看看，有啥自己懂得没
- 然后。。。 改bug去吧~ 混个脸熟吧！ 多改几个吧！ 改着改着， 哇！ 核心开发啦！
多么的相似。菜鸟都从改bug开始，但别拿这个当终极目标了。。 咱要有长远打算。
还无聊吗？ 我不知道啊！
那好，说了这么多，就是让那些迷茫的人，能在自己的组织结构里，自己可控的部分挖掘潜能，毕竟，没人能阻止你进步。
