对于java局部代码的重构需要遵守下面的准则：
1.弥补模块外部表现的单元测试
2.做最小的改变，让每一步都可以被跟踪
3.不断执行单元测试，查看修改结果
根据以上内容可以断定下面的做法不是真正意义上的重构：
1. 编写一块全新的模块，采用不同的外部表现，但它无法支持或者接替原先同样功能的模块。全新的模块尽管增加了一些功能或者采用全新的构架，编写它所耗费的工作量可能不是很大，但是它外围的程序所带来的更新的工作量却十分庞大，而且危险性很高。
2. 在原先的程序上，不断的打补丁，为了满足一些新的需求和修改一些BUG，但是没有提升原先的软件结构使其更加容易添加新的需求，或者让其更加完善。这样的BUG 修改方法造成的结果是让软件变得越来越难以修改和提高。
3.建立在对原先系统不熟悉的基础之上的另辟炉灶，由于目前的系统存在的问题，而要重新写一块程序。如果这种做法不建立在对原先系统的良好理解的基础之上，而制造出来的新产品同样会面临众多的问题，无法真正满足实际的需求。
4.缺乏良好单元测试的重构，单元测试是我们目前缺乏，而今后需要极力提倡和推广的方法。过去我们的“重构”在一定程度上缺乏有效的单元测试，所以总会出现很多不兼容或者重大问题。
由此我们可以看出，重构必须建立在对目前系统和代码的深入了解之上，建立在良好的单元测试之上，建立在对原有对外接口不变的基础之上。