experience with refactoring on large projects

i very like the idea of refactoring, when it comes to extend your system or if you just want to improve overall design.

but i wonder how it works on large scale handovered software systems (you need to extend and maintain), especially if the system does not come with unit tests, which "protect" my refactorings.

second issue is that it is very difficult to measure improvements through refactoring. with small software systems i could measure it by sniffing around for code-smells. but i think this is not applicable for systems >500k loc, it is just too big to judge and focus which refactorings to use and where exactly to apply.

i looked around and found a very interesting paper:Straightening Spaghetti-Code with Refactoring? i found it very interesting that most refactorings had an negative influence on certain software metrics. i know you have to be careful with metrics but they can be helpful when it comes to a very big code-base.

what about your experience with refactoring issues on big maintainance/extension software projects.

Manuel, Working Effectively with Legacy Code is an excellent book on this topic. It shows how to bootstrap the code of refactoring systems with no tests.

A static analysis tool can automatically look for code smells for you on a large code base. If you run it with many rules enabled, the classes with larger clusters of errors are the ones that should be examined by hand for a possible refactoring.

Originally posted by manuel aldana: but i wonder how it works on large scale handovered software systems (you need to extend and maintain), especially if the system does not come with unit tests, which "protect" my refactorings.

Jeanne's book suggestion is very much on top.

second issue is that it is very difficult to measure improvements through refactoring.

What exactly do you need to measure improvements for?

with small software systems i could measure it by sniffing around for code-smells. but i think this is not applicable for systems >500k loc, it is just too big to judge and focus which refactorings to use and where exactly to apply.

I'm working on such a system, and frankly I'm not sure what you are talking about. When working on the code, I'm still working on single classes. I still can see where a variable could have a better name. I still have a sense for which class is too big and needs to be split. I still have a sense for inappropriate dependencies and can introduce abstractions to break them.

So, what is the actual problem you are facing? Can you give a concrete example?

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

manuel aldana

Ranch Hand

Posts: 308

posted 11 years ago

i cannot give a concrete example.

while working i just have seen several (big) software systems which had such a big design debt (no unit tests and untestable classes, duplicate code everywhere, no seperation of concerns etc.) that i imagine very difficult to improve the system without a hint where to start first, which refactoring to use first etc., i.e. to priorize your refactoring steps.

i know experience is very important(!), but i think metrics can be a big help too, especially for big systems. and in desribed paper (link) usual metrics don't "measure" well from the point of view after/before refactoring.

maybe there are tools which analyze the code and use the known bad smells as metric-parameters? the smells like long method, large class shouldn't be a big problem but what about the other smells, which are difficult to be measured by tools (e.g. divergent change, shotgun surgery).

when refactoring in general, are you using metric-tools to get an "design-debt" overview of the system you are maintaining or are you analyzing all the code without metric-tools help?

I typically don't use those analyzation tools. I've tried some, but in my experience, they just tell me what I already know: that the whole system is shoddy and it would take ages to remove all problems.

What has been proven to be a good strategy is to just apply refactorings while you are working on the code anyway (to fix bugs or implement new features). Don't overdue it, just make sure that every time you touch some code, the code becomes a little bit better. Start by renaming things so that you understand them better, break down big chunks of code into smaller bits. Once you start to understand the code better, you can begin to tackle bigger refactorings, such as replacing conditionals with strategies etc.

"How do you eat an elephant?" - "One Bite at a Time."

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Peer Reynders

Bartender

Posts: 2968

6

posted 11 years ago

Originally posted by manuel aldana: maybe there are tools which analyze the code and use the known bad smells as metric-parameters? the smells like long method, large class shouldn't be a big problem but what about the other smells, which are difficult to be measured by tools (e.g. divergent change, shotgun surgery).

when refactoring in general, are you using metric-tools to get an "design-debt" overview of the system you are maintaining or are you analyzing all the code without metric-tools help?

At this point I'm left with the impression that you haven't sufficiently internalized the lessons of Fowler's Refactoring. When I got my hands on that book in 1999 I immediately recognized some of the refactorings he was describing, while others I had to work harder at. The Refactoring Workbook may be of some help to you but I suspect that you just need to keep reading other people's code and keep going back to Fowler's Refactoring to refresh your memory. Working Effectively with Legacy Code is a must have when you are handed that Big Ball of Mud. Because of the sheer size of some projects it will be difficult to know where to start. Object Oriented Reengineering Patterns is a catalog of practices that can help you accomplish this type of reengineering project.