标签：
过年后，在目前公司的工作就要告一段落了，又恰逢年终，终觉得还是要总结点什么，来个了断吧~
考虑了一下，似乎技术上没有什么太多可说的，再加上外包项目也不能透露太多客户的东西。3年多做得都是同一个Account（客户）下的项目，是客户产品线下的一个数据中心产品，面向数据中心的基础设施用户，也就是国内IDC。产品提供数据中心IT基础设施运维整体解决方案， 属于行业内KVM交换机顶级品牌， 另一家也是美国厂商, 行业内剩下的就是国内中低端的深圳厂商， KVM over IP 还是较有技术含量的。
该产品有悠久的历史，最早的代码在源码中的标记是10年前， 那时java还处于一个婴儿期， 并没有这么多开源框架支持企业级开发， 数据模型还是用java bean封装，操作方法也在bean中， web层的调用直接穿透到持久层（也就是bean）这里。so，这样的东西有技术挑战么？
大部分程序员都喜欢搞新项目，觉得新项目不用吃别的程序员的"狗食"， 能大胆用新技术，很爽。但现在IT信息化已经进行了10几年了，如果是外包行业，基本上接的最多的项目肯定都是维护性项目， 一般企业哪有这么多新项目啊，都是遗留系统。
遗留项目自有它的特点， 首先要吃透该系统的整体技术设计， 至少是宏观上的层面要有个整体把握，然后才能根据客户的enhancement需要来设计，不要破坏已有系统的设计，偏离了原来架构的设计意图，会使软件越改越烂，就是重构那本书里提到的"bad smell"。一旦有这个趋势，要及早处理， 这个技术债越欠越多，维护的人员一批一批的换，到最后没人搞得清楚整个系统的runtime运作，有些公司老产品折腾不来了干脆推倒重来， 然后循环又开始了。
这个就是维护的技术含量了，听说还有个专门的行当叫维护架构师，国内公司似乎还没发展到这个程度。你需要在遗留项目定好的条条框框里辗转腾挪，使劲浑身解数，为了提高产品的一点性能，应付越来越多的数据，保证质量的同时，尽量引入当前比较主流的工具或方法学来提高团队效率。
我们的项目就经历过一次大幅重构：
还觉得无聊吗？也许。
对于大部分项目机会不能自己选择的业内同行，也许有意思的玩意就在你身边，你觉得是一坨shit的东西仍然能从系统的整个生命周期中，结合当时的技术环境，看到这坨shit的一些有意思的东西，从设计文档里体会当时的设计权衡，考虑。 当然，文档里只有设计的结果，有些妥协maybe只有当事人才能知道，but,这不是重点！ 这里只想说，一个人想提升自己，如果有心，任何时候都可以，只要会发现。
OK，这是enhancement，那bug fix呢？这个更简单，现在如火如荼的开源，所有人去参与一个项目的第一步是什么？
多么的相似。菜鸟都从改bug开始，但别拿这个当终极目标了。。 咱要有长远打算。
还无聊吗？ 我不知道啊！
标签：
原文地址：http://www.cnblogs.com/zhukunrong/p/4272536.html
