为什么大家不愿意做重构项目？

引用

最新补充：
才两天，这么多浏览量了，挺意外的。

写本文的目的主要思考一下工作中切实遇到的问题。

公司是大型网站，这几年发展很快，而一些基本方面却变化不大，越来越不适应敏捷开发，项目扩展，快速满足需求的特点。
包括：project目录结构，开发框架，构建过程，设计文档规范等等。 因此自己思考为什么炫目的前沿技术项目起了很多， 而很少人愿意进行这些很有挑战，但很有价值的重构项目？

本帖子就是自己思考的一点心得和体会。核心还是对于“拥抱变化”的认识，变革的价值，变革和风险的权衡等问题上。

1. 问题
    我们的项目是大型网站，目前看还存在很多技术，过程问题，但变革和重构项目为什么很少人愿意做呢？ 思考ing

2. 分析
    目前，前沿技术项目名称很炫，比如：云计算，分布式计算，分布式服务等，然而重构项目却比较朴实，技术领导给予的重视程度不够，KPI分量也比较轻，可能是大家做重构项目意愿较低的原因吧。
    重构意味着要打破陈规，对现有项目动大手术。 要排以前的很多地雷，存在很大风险，容易出现A类故障. 而对重构项目的价值评估体系不够，KPI考核缺乏故障忍耐及变革奖励机制，因此架构师做重构项目的意愿不太高。

3. 对策
   对重构项目可以按 必要性，紧迫性，风险性建立评估模型。 对高风险的重构项目，例如：数据模型变更，开发框架升级，核心产品架构重构等可以按等级给予豁免故障分，通过创新制度鼓励“拥抱变化”。 这一点需要向 Facebook 学习。
 
   即便一些项目不存在风险，例如：开发过程优化，提升效率的工具优化等，其带来的研发效率的提高，成本的下降是非常巨大的。但价值评估不够，KPI比重不够。
   因此在对前沿创新和研究项目给予同样重视的待遇下，对重构项目项目按必要性，紧迫性适当提高KPI分值，可以提高架构师启动重构项目的意愿。
 
4  重构项目评估模型
1） 必要性和经济效益：1-10
     分值越大，代表经济价值越大，如生产效率的提高带来的人工成本，运营成本，硬件成本的降低。
2） 紧迫性：1-10
      分值越大，代表越紧迫。这主要是衡量机会成本。例如：早6个月完成，就可以带来 6 个月成本的降低和价值。机会成本通常是IT公司比较会忽略的因素。
3） 风险豁免值：1-N ( N 为最大故障分 )
      主要用来评估风险值，进而评估重构项目的风险豁免值。 用来鼓励软件工程师启动重构项目的意愿。

引用

重构项目价值 V = (必要性 * 紧迫性)

  注：值范围： 1-100

引用

重构项目的 KPI =  重构项目价值 * (风险豁免值 - 故障分)

   当 故障分 < 风险豁免值 时，重构项目考核的 KPI 仍然可以保持正数，工程师的考核不会因为出现一定故障而导致绩效下降；
   当 故障分 > 风险豁免值 时， 说明故障超出了可预先商定的容忍范围，会适当影响工程师的绩效。这样可以约束工程师加强重构项目的质量和风险控制。

5. 总结
   工程师通常会比较专注做事，而不善于包装。因此，项目经理或技术领导应该辅导帮助，进行项目的价值评估，例如：采用一定模型，对项目的人工成本降低，开发，发布效率的提升等经济价值进行分析。

评论

29 楼 raymond2006k 2010-01-30  

jayo 写道

其实是老板不想花钱让你做重复的事
如果你们私下就把新版做出来了，我不相信老板不要！
哈哈，所以说，成本衡量一切！

楼上说的没错，老板最关心的还是能看到的效益，提高多少效率？减少多少人日？

28 楼 jayo 2010-01-26  

其实是老板不想花钱让你做重复的事
如果你们私下就把新版做出来了，我不相信老板不要！
哈哈，所以说，成本衡量一切！

27 楼 wandou 2010-01-26  

没人愿意重构不是事实。
之所以出现迫切需要重构的地方，是因为管理层技术能力有问题。如果管理层对技术很精通，就不会出现迫切需要重构的情况。既然管理层对技术不精通，那么他也很难了解重构的价值，因为他一直不懂装懂，所以才造成效率的巨大浪费。而且这种浪费已经成了习惯，所以在更上层觉得这是正常的。
换句话说，出现需要重构的情况，是因为管理层不了解正常的软件，维护成本应该是多少，而且也不知道什么样的软件才是易于维护的。
在中国，出现这种情况，是由中国国情决定的。决定是否拿到项目的因素，不是技术，不是成本，而是谁离权力核心更近。

26 楼 dieslrae 2010-01-25  

蜗牛创业网 写道

关键是管理人员无法认识到重构对业务提升带来的效益，重构就没有存在的意义。军队要听党指挥，搞技术的要听效益指挥。几年工作下来搞技术的人很多都还没感到因为重构带来什么显著的效果，不懂技术的人就更无法理解了

其实我一直不认同这个观点，军队是人民的

25 楼 myreligion 2010-01-25  

我们进行项目重构的原因只会有一个：弄成产品，卖给更多的人。

24 楼 friendsys 2010-01-25  

有新需求的时候,才会去适当的重构代码,不过也仅局限于保持代码的简单和可阅读性,不会专门的抽时间去重构代码

23 楼 raymond2006k 2010-01-25  

才两天，这么多浏览量了，挺意外的。

写本文的目的主要思考一下工作中切实遇到的问题。

公司是大型网站，这几年发展很快，而一些基本方面却变化不大，越来越不适应敏捷开发，项目扩展，快速满足需求的特点。
包括：project目录结构，开发框架，构建过程，设计文档规范等等。 因此自己思考为什么炫目的前沿技术项目起了很多， 而很少人愿意进行这些但很有挑战，但很有价值的重构项目？

本帖子就是自己思考的一点心得和体会。核心还是对于“拥抱变化”的认识，变革的价值，变革和风险的权衡等问题上。

22 楼 zeronelee 2010-01-25  

zhangjunji111 写道

还有就是
1、人员流动性比较大，有时候根本不太理解前一个人的意图，不敢贸然修改代码。
2、项目比较紧张，根本没有时间修改旧的代码。
3、菜鸟写的代码比较乱，看都不想看，更别说重构了。

菜鸟写的代码你不是不想看，是你根本看不懂，也就是说你比菜鸟还菜。

不要看不起菜鸟，要想想你也是从很菜的鸟人成长成为比菜鸟稍稍强点的菜鸟。

你的话明显有讽刺菜鸟的意思。不爽。

21 楼 墓里活人 2010-01-25  

自我已经受够了。
在至少一千行js,多则5千行JS的文件代码海里，改bug。
而且一个注释都没有。

20 楼 qamer 2010-01-25  

没走完的重构时痛苦的，走完了就是快乐的

19 楼 maxiaoxia 2010-01-25  

没有测试代码的重构，还是重构么，所以重构不在于在什么时期，而是是否可以有效的实施，为什么要重构，产品怎么用，首先要更新需求和设计，规划和重新编写测试代码，否则应该更新需求设计后，利用旧的代码和架构重新开发。

18 楼 prowl 2010-01-25  

最近没事干老是回头看自己写过的代码，总会发现有很多地方值得改进，重构让人兴奋！

17 楼 vieri122 2010-01-25  

如果是维护时期重构代码，风险比较大。特别是当这个项目之前是他人做的。

有点别人拉屎，你来才屁股的意味

16 楼 lkj107 2010-01-25  

如果是已上线项目，当然是不重构的好，因为重构风险更大，毕竟上线以后很多问题已经发现并处理了；最好的办法是由销售忽悠上2.0，3.0，这个是双赢的结局

15 楼 flyfan 2010-01-24  

我也喜欢重构，但只限于自己的代码，重构别人的代码只能说是痛苦

14 楼 lyxh_2003 2010-01-24  

大多数领导是业务驱动项目开发。。。。

13 楼 qy_wangliang 2010-01-24  

我刚刚参加了一个重构项目，角色是一个小弟，说实话学到了不少的东西。刚到项目组一年，项目组一直在维护一个PDM项目，升级了N个版本了，这次领导下了很大的决心，对之前的产品进行了“解剖手术”，彻底的改了一下，也是借这次机会充分了解了产品。还学到可一些重构的技术、先关的重构工具。

12 楼 EldonReturn 2010-01-24  

不是长期的自主的产品，谁会去弄重构啊，自己找事儿嘛

11 楼 蜗牛创业网 2010-01-24  

关键是管理人员无法认识到重构对业务提升带来的效益，重构就没有存在的意义。军队要听党指挥，搞技术的要听效益指挥。几年工作下来搞技术的人很多都还没感到因为重构带来什么显著的效果，不懂技术的人就更无法理解了

10 楼 freej 2010-01-24  

我做过很多你所说的重构项目，重构的代码从坏味熏天到相对整齐划一，而且大部分都没有设计文档和代码注释，有的甚至是零文档的项目。

重构项目代码很需要团队成员的功底，包括阅读代码的能力、代码到业务的反推能力，以及对编码规范和各种模式的深刻理解。

同时，做重构工作也很锻炼能力，如果一个程序员能够有机会参与几个项目的重构工作，我想无论是对软件设计能力还是对业务理解能力都是很有好处的。