说明：本文中描述的工作量是指人天、人月这样的人力投入量。不是狭义的代码量，用例数。
小规模的代码重构，如修改一个变量名，添加一行注释，在软件维护过程中，在添加新功能的时候随手就做了。没有单独做工作量估计的必要。但如果是做一个模块的重构，或一个子系统的重构，一下放倒上万行代码。没有估计，没有计划是不行的。
代码重构不同于新功能开发。它的需求是已经明确的，并且已经有实现代码，也不需要关键技术的分析(如果是解决代码性能问题，一般称之为性能攻关。不在代码重构的范畴里面，我们说的重构主要还是解决代码可读性，可扩展性，可维护性的问题)。评估工作量时它们关注的内容也会有差异。
总体上来讲，代码重构工作量估计应该关注四个方面：测试环境的搭建，测试用例测试代码的编写，重构代码修改，集成验证。
一、测试环境的搭建
1）重构代码的准备
不同软件对质量要求不同，测试环境要求也不同，这一部分的难易程度也不一样。工具类软件代码基数小，编译时间短，依赖关系简单可以直接在版本代码主分支上重构，花的时间少。电信、金融类软件，代码基数大，依赖复杂，重构时最好把要重构的代码隔离出来，拿到一个新的环境下重构、验证完备了再合入产品代码中。代码拿出来后就涉及很多问题：编译的问题，依赖的问题。桩函数和驱动的构建非常耗时间。
2）测试框架的搭建
选择第三方测试框架(如gtest, cppunit)，公司也有大平台自己开发专属测试框架的。测试代码要与产品代码物理上隔离，要理清楚测试工程如何部署，测试用例如何执行，如何与版本构建集成，是否需要采用分布式等。
二、测试用例
咨询测试专家（一般测试部门对用例的密度有一个指导标准），求助其他开发同类软件做单元测试或者LLT测试的同事，了解用例编写的密度，作为工作量估计的参考。比如1000行代码需要多少用例。基于这个密度，考虑用例开发效率，再结合当前要重构的代码量就能够估算出一个大致的工作量来。
三、重构代码修改
在完成重构方案分析后，重构过程中要添加哪些代码，要改哪部分代码已经有了一个大致的认识。邀请对该模块比较熟悉的其他开发人员、测试人员共同参谋一下。把添加和修改的代码量折算成新开发的代码量。折算系数方面结合自己产品情况协商一个值，比如修改代码按修改量X0.8之类折算成新开发代码量。
统一折算为新开发量后再结合项目正常版本的开发效率就能估算出这部分的工作量。
四、集成验证
光有单元测试还不足以保证质量，每个阶段的集成验证也是必须要考虑的。集成验证用例通常测试人员都已经开发完了(这就是他们的工作)，从测试专家那里了解一下重构部分代码相关的用例有多少，执行一次需要多少时间。如果有自动化的集成用例验证就省事很多，可以频繁的执行。如果没有自动化，要考虑人工执行，指定一个计划比如每周执行一次或者每月执行一次。根据这些条件大致估算一个工作量。
以上几条，重构代码修改的工作量占大头，其次是测试用例准备，如果估计得不准后面偏差可能就很大。务必找到相关熟悉的人和执行重构的人一起评估，达成共识。
另外，从高端专家了解到他们对重构的工作量估计也没有成熟的经验。通常的做法搭建好框架有时间就做一些，后续有时间就再补充。如果管理者要求很快出成绩，这招估计不受待见，这个无解。