zephyrfalcon.org :: Efectos Especiales: Repairing my bicycle, the hard way talks about the complications of refactoring dynamic languages like python. I agree that when you are doing large refactoring on big applications then a compiler that catches as much as possible does appear helpful. However, even that can give you a false sense of security if you don't have a well structured code base.
My thoughts though are
- Use all the tools available eg. for Python use Pylint and PyChecker. For java use PMD and the like. BUT, get the code clean with these and all compiler warnings first!
- Carefully structure the clever bits of code that do introspection etc. ie the really dynamic bits of code that are going to be dificult to check. Don't let them spread like wildfire accross the project just because they are cool
- Think packages and logical structure from an early stage. I find that this should be an early refactor not a late one.
- Be specific in code. So for example in java import specific classes and use a tool to check/maintain those imports. Otherwise you could accidently miss getting compiler errors because of a co-incidence in the way classes are imported
- All tests are your friend. Unit, Acceptance, Performance and human experimentation. Do them all before and after
- Use your software version control sensibly. Consider a branch but at the minimum make sure you can build the application pre and post this refactor with only this refactor involved
- Fight to get to do these refactorings, because a project where the developers are frightened of the code is heading for disaster. I suspect 80% of bugs will be in the 20% of code that 80% of your developers can't understand and the critical ones will always be found when the 20% of developers are on holiday or sick
- Do be realistic about the time that the refactoring will take and make sure that you do it in the right environment - sadly in too many places that may mean when all the interruptions have gone home. But at the same time be bullish to management about the amount of time refactoring like this will take.
- Do not let yourself get sidetracked into fixing/adjusting anything else. Note them all but stick to the original change you planned. One step at a time will get you through even really hairy code and before you know it you will understand the application
- This is a great way to learn a project. Try doing dummy runs, let developers pick something they think needs refactoring and try it out - especially developers new to the project. They will learn loads. Just be honest up-front that this is principally a learning and idea testing excercise not immediately leading to committed code
- Do co-ordinate this. Be kind to the other developers on the project and don't just decide to do this on the spur of the moment. They may have code nearly ready to commit that you are going to break. So plan and agree when this will be done so that the impact on others is minimized
Oh and enjoy it. Taking code and refactoring out something that with hindsight seems obvious and just ends up making sense to everyone but that no one else dared do is one of the most rewarding coding achievements - and very good for your career prospects ;-)
Comments