[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
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.
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.
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
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
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?
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |