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. DefinitionRefactor 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. AimImproving the design//Performance//Data Consistency //Reuse the logicMake 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 notThree 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 reviewWrong time: Need to rewrite, near to deadline//Stop refactoring on branch since staging release4. LimitationDB, 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 smellLong parameters list//Erlang program is easy to be writen into these styleSwitch statement instead of polymorph//Erlang has no switch, it is good! I love polymorph Lazy class//Someone loves it, but I never use itUse 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. TestWhen 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