>Hi,
>
>I am looking for a common sense, good practice advice. I have a BIZ object (for parts) that has 2 methods dealing with updating parts usages. The two methods are as long as the road from here to Alaska, with tons of refactorings (over the years), changes, etc. Managing this code is quite a nightmares. Plus, I believe the code has bugs. But since it is so long, even understanding it would take time (even though I am the creator and have nobody to blame). I used to think that keeping the entire code (with many CASE and IFs) in one method would reduce the maintenance. But it does not seem to work that way.
>So I am thinking of breaking up these two methods into probably 5-6 small methods, dealing with specific changes/updates.
>Does this approach make sense?

Look at your code and if you see a set of lines which does one thing, and if you can think of a good name for what it does, then that block of code (which you can easily do with the tool mentioned in Thor) should be a method.

Beware of local variables used in that block, though - they may be inherited from the surrounding code, and may be good candidates for parameters to your method. Looking at it the other way, if you see a set of variables which are used only within a certain block of code and not elsewhere, that block is also a candidate for a method - again, if you are able to say what it does and can come up with a good name.

Naming the methods and variables is half the work, I think sometimes, and half the fun. And if you can't think of good names for them (good in the sense that their meaning will be clear to you when you revisit the code in 2020), then think longer - because if you can't, it's still not quite clear in your head and you don't quite know what you're doing :).