外包公司作遗留项目有意思么？

过年后，在目前公司的工做就要告一段落了，又恰逢年终，终以为仍是要总结点什么，来个了断吧~

背景介绍

考虑了一下，彷佛技术上没有什么太多可说的，再加上外包项目也不能透露太多客户的东西。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开始，但别拿这个当终极目标了。。 咱要有长远打算。

还无聊吗？ 我不知道啊！

 那好，说了这么多，就是让那些迷茫的人，能在本身的组织结构里，本身可控的部分挖掘潜能，毕竟，没人能阻止你进步。