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

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

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

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


  注：值范围： 1-100

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

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

从企业讲如果项目的产出不是持久产品，那么重构项目就无法产生利益，自然就不会由企业利益中产生出重构项目的需要，而企业没有这种需要，项目组、工作人员就不可能有时间，也不可能有人会主动投入时间进行这项工作。

人永远都是去寻找能得到更多东西的工作去做，没有人是真正的劳模，鉴于此，如果两个工作放在一起，一个是新项目，一个是老项目，肯定是新项目。

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

要想重构
就在开发的同时一并做了
等工程都完事了
再提出来想重构
是个领导都会反对的

重构项目是可以理解的，也是要有人去做的。
终归都是业务的发展需求，驱动项目的开发。

1楼正解.
做什么工作大多时候项目经理都无法决定.
要让公司决定重构是一件相当难的事(除非系统有大的问题了).

我就很喜欢重构

你所指定重构是在项目开发时期，还是在维护时期。如果在开发时期，我想没有几个人会拒绝重构代码。
在维护时期类。你有那么大魄力吗？

   可能你说的是那种代码规范比较好。这种代码改起来也舒服啊。
   要是动辄一千行，而且没有什么注释的代码。兄台也会喜欢？