2010年1月17日星期日

Reading about Refactoring

I'm reading a book about refactoring these days, and found some good points useful in my work.
1. Definition
Refactor do not change any observable behavior of software
//But new features are needed, they are mixed in time, but should not mixed in mind. They are two things!
//Programmers should never add any new feature without PM design while refactoring.
2. Aim
Improving the design
//Performance
//Data Consistency
//Reuse the logic
Make the code easy to understand
//Not easy, because the logic is really complicated sometimes. We should try.
Find bugs
//Clarifying the assumptions of each unit!
Move on fast
//Decayed design is a huge burden. Without it, we can move fast!
3. When and when not
Three strikes and you refactor.
//I used to refactor at two strike, and always find it unnecessary in the end.
Right time: adding new features, fixing bugs, doing a code review
Wrong time: Need to rewrite, near to deadline
//Stop refactoring on branch since staging release
4. Limitation
DB, interface
//change them carefully. Data migration is always dangerous. Other team depend on your interface, so if you change it, they have to change!
Design
//The feature design is sometimes lead to bad structure of program. Engineers are obliged to reduce the bad design.
5. Bad smell
Long parameters list
//Erlang program is easy to be writen into these style
Switch statement instead of polymorph
//Erlang has no switch, it is good! I love polymorph
Lazy class
//Someone loves it, but I never use it
Use member fields as global variable
//I hate it very much, although I do it sometimes
//Member fields are state of an instance, rather than a basket holding the mess you do not know where to put it.
Data classes
//All the time I wish all small data struct can be thrown into protobuf, but sometimes they need quick lookup or other functions. It is difficult to trade off.
6. Test
When you get a bug report, start by writing a unit test that expose the bug.
//I'm not sure if all the refactoring can be covered by unit test. I love TDD, however, I find it hard to maintain the unit tests because the inner interfaces changed frequently. Unit tests turn from my proud into my burden that I have to change accordingly. So I think writing too much unit test is not a good idea. Today I agree that unit tests have two major purpose: 1) Code coverage, 2) reported bugs coverage

没有评论: