发布时间: 2013-04-04 02:44:00
虽然重构这本书出现了14年，自己在重构方面也有一些实践（从07年开始），但是我发现重构在实际应用中还是需要思考一下的。 ( Although the book <<refactoring>> has been published for 14 years , and I had this kind of experience since 2007, I found that in the real world, we should think for a while before we do the refactoring. )
是重构合适，还是重写合适？ ( should it be refactored , or rebuilt? )
我的意见是，如果代码的质量很差，就不值得为其重构。差代码的特点是： ( my suggestion is: let's rebuild it if it doesn't worth refactoring. The bad code looks like: )
1. 命名很糟糕。绕来绕去的。最怕怕的例子： red = 'green', success = 'false', get_an_apple() => 'banana' ( terrible naming)
2. 逻辑很糟糕。大段大段的复制代码。 ( terrible logic)
3. 底层架构就是错的。 ( totally incorrect infrastructure code )
在这样的差代码下做重构是浪费时间。一般说来，重构的步骤是： ( to refactor this kind of code kinda of wasting time. I would rather ask the business analyser for the re-build. generally, the steps for refactoring are: )
1. 保证代码可以运行 ( make sure the targe code is running )
2. 读懂代码，可以写单元测试或者 回归测试 ( read the code , know the logic, and write the unit tests)
3. 开始着手重构。 写代码 ，运行测试，写代码，运行测试。。。 (start refactoring, run tests, write code, run tests, write code ... )
我觉得让一个十年经验的程序员去读一个烂代码，从代码中分析业务逻辑，不如直接让他直接去找业务人员，了解业务需求。然后按照他自己的理解来重写。 ( It's not a good idea to make a ten-years experienced programmer to read the code written by a newbie with lots of terrible code with bad smells )
那么，在什么时候重构合适呢？ 我觉得有三种情况： ( So, when should we do the refactoring? I think there are 3 cases: )
1. 这个代码没有时间重写了。 (no time to write a new project )
2. 这个代码正在生产环境中使用。没法在短时间内把它停下来。或者说，一换下来，就会发生重大的生产事故，没人敢碰。 ( this code is running for production purpose )
3. 两个人的水平相差的不太悬殊。而且底层代码的架构不是差得离谱。还有拯救的可能。( the previous coder's ability is not too bad, and the infrastructure is not so bad. )
Back