Refactoring Spikes as a Learning Tool and How a Scheduled Git Reset Can Help | Javalobby
Home of the Mikado Method
Large and Small Scale Refactoring « Paul Dyson’s Blog
It is very good to know the problem of "just a little further" and the way to deal with this type of problems. I think many people experience these problems.
Home of the Mikado Method
Large and Small Scale Refactoring « Paul Dyson’s Blog
It is very good to know the problem of "just a little further" and the way to deal with this type of problems. I think many people experience these problems.
Mikado Method
When large portions of the code is changed the whole team will have to be engaged, and everyone needs to know the goal to be able to help out and understand. The team also has to communicate outside of its immediate vicinity, especially if the change is based on an external goal.
The History of Mikado Method
I like this story pretty much, at least the description statements within the story.
- The Technical Debt was everywhere.
- All of a sudden we were supposed to deliver to a new client and the interest on our loan went through the roof.
- This would double our debt, but decrease the interest temporarily, until the next client would drop in.
- So we went on, and every day on the daily stand-up we said that “We just have a couple more errors to fix, but we will probably be done today or tomorrow”. Yeah, right…
- We had realized that we had been walking with the refactoring dependencies, i.e. we tried to refactor a part of the code that was depending on that another refactoring already had been done, which it hadn’t.
- To do that, you naively start with the thing you want to achieve and draw that on your Mikado Graph, typically a business goal.
Refactoring or Rewriting?
Many people like to use "refactoring", even though they are doing rewriting, because of one of the two reasons, or maybe both:
- Refactoring sounds cool as a term, while rewriting sounds scary to your boss or your colleagues.
- They do things based on the code, without any high level design or discussion.
I got a rule of thumb:
- If something you change on the code based would cause compilation errors and you can't fix it in a minute, you are doing rewriting, instead of refactoring.
According to my rule, the Mikado guys are doing rewriting.
Why the terms are important?
Using correct words to name the work you are doing or you are going to do is very important, because the correct words would possibly lead you to correct information, better planning, and more useful resources. However, if you name it incorrectly, you might probably get loss.
Naming the work as refactoring, you will turn to Kent Beck's book for some help, while you won't get much useful information from it. You might think it won't take long, just like the Mikado guys said, "will probably be done today or tomorrow". You don't think you need a plan, which lead to the "Software Hydra" problem.
How should we handle re-writing?
Unfortunately, there has not been a book name "Rewriting". But at least, we know it is not refactoring. So we need these things:
- Preparation for a long term work. For example, two week to one month. You know, refactoring should only take you a couple of minutes.
- Preparation for risks. There are no risks in refactoring. The system will work exactly the same as before if you only apply refactoring out there. While doing rewriting, you are going to have risks: break the compilation, break some features, or even bring some unknown issues. However, you can't hide the risks. Before you can handle these risks, you need to know them.
- You need a plan.
- Mikado Graph could be a good tool for planning. I just do really understand what "Business Goal" is. We all know we want a better code base, less duplicated code, better structure, good code patterns, clean calling paths. But we just can't define them.
- You need to take the "old" system architecture and "new" system architecture into account. With refactoring, system architecture won't be your business. You should never touch it at all. But if the code is a ball of mud, dude, you need to operate on the system architecture sometimes.
- You need to identify the problems of the original code base, and prioritize them.
- You need to write down which parts you are going to change. Here, Mikado Graph could be a tool, because you need to find out the leaves.
- Naive start: I think the Mikado guys' idea of "Naive Start" is good. Even though you need to plan, don't plan too much. Or, in another word, don't think too much. Do it, touch it, change it, and see what would happen. There are some risks you must take. However, software development is something "soft", you can revert it back to the starting point if you like. The biggest risk is timing. Don't spend too much time before you realize it would be a mistakes. And planning to much is a big mistake, which you should know before hand.
- Add more test, and try your best to reduce to test cycle. Unit testing is not always something you can choose. But apply unit testing whenever you can. If you can't, make the tests automatic. If you can't, just test it.
- Apply the refactoring techniques whenever possible. I believe refactoring techniques could handle 60% of work.
No comments:
Post a Comment