产品维护和二次开发，如何留住人。。。

在十年++的泥潭里轮回，不得超生。。。。

，把别人留给我们的泥潭挖得更深。更坑爹。。

果断

我在一个五年的老项目中沉沦，中间走了无数次人。改的也是面目全非。现在就我一个人在维护，项目挺大的。我有想过整理一份全面的文档，可是公司给的钱太少，只能遇到问题就改，没事，闲着也不去整理了。关键是钱的问题。曾经领导让我整理，我拒绝了，我说整理不出来。后来不了了之，我都不知道怎么去提辞职的事情，我现在是想辞掉这份工作。搞维护，没什么头衔，工资还那么少，平时有产品的设计也不让我参加，别的项目有需求我也没机会去学习。领导现在就把我放在一个维护人员的位置，平时没事了，帮助同事解决点问题。这种生活太没意思了。关键点是钱太少，还没机会。这是我干维护的经历。

这个情况，我觉得还是组长的问题，既然匹配 2~3 个人，最好要明确职责和发展方向：一是对外处理维护（一个人足于）、
二是整理清洁化版本 + 新业务（一到两个人）。 做两个版本：维护版本（branch），清洁干净版本（trunk）。直到清洁版本替换维护版本，这样不但可以做到新人有事做、有方向。而且项目版本朝着好的方向发展！

在实际项目中我们说的重构，不是要全盘要打破老的东西，而是在产品性能、或者是人才成本的考虑，做一些跨语言平台的重构，比如 c++ 换成 java，java 换成 ruby 等，如果是相同的系统设计理念，相同的语言平台，重构是没有意义的。只能是整理版本！并不一定要补充文档，就是像整理衣物一样，让人看起来舒服，干净！

这种没有创新精神的垃圾公司，谁愿意在其中浪费青春

打江山难，坐江山更乎其难吧。

其实现在重构也不是一定不可以。从以下两点考虑：
1.业务积累
  有了业务积累，在重构的设计阶段可以充分满足所有的业务，然后尽量让扩展性更强
2.技术积累
   我想这么久以来相关人员的技术，写代码的思想多少都会有变化，再实现一些相似的功能会写出更漂亮的代码，便于后期的维护

哥也在一泥潭中啊，8年的潭子，jsp中各种java代码。。
不过公司老板比较牛，对业务，销售和支持基本都抓的住。控制的比较好。。



重构的话，首先业务要十分清楚，然后才是技术问题。。

其实这是必然的，就拿我上家 来说，抠门到极限

所以留人还在于待遇和管理，两者我更倾向于管理。因为在一定时期内，比如实习生，他想的就是学东西，如果老板在管理和制度上人性化多点 从感情上说他不会给你撂挑子