They discuss a technique where they can continuously improve the code without having to understand the code!
This does require that you have an adequate suite of tests to back you up.
The Technique
You're never going to be given enough time to fully understand the code, and to decide the best "refactoring path".
Instead, we're going to use a different technique, to cut up code that you don't understand, and figure what it means later: Start with the Curly Braces.
Find if statements, try / catches, etc and use the extract method refactoring on the whole thing and give it a name.
This will make unused or badly written code stick out, by removing one chunk of code, from an even bigger method.
They did not take the time to understand any of the code: by slowing improving names and removing duplication, they were able to make the program more maintainable.
They eventually discovered the IChart abstraction, which made adding new chart types to the application a safe operation, since existing chart types methods would no longer need to be modified (which was their original goal).
At any point, they could have stopped working and deployed the code, since they worked in two-minute intervals and committed changes at every safe point (the code was cleaner at every check in, than when it was originally checked out).
You may also be interested in reading one of J.B. Rainsberger's articles on simple design.
The article explains how improving names and removing duplication cause abstractions to surface, which allows responsibilities to be redistributed among classes. The video above is definitely a prime example of this process in action.
The four rules of simple design can be used to determine when you should strike the metal.
Beyond those tips, start slow and refactor only the pieces that you are working on currently. This will limit the amount of risk you introduce with each set of changes. This also prevents your boss from asking the question: why did feature X break, when no one worked on that feature in this deployment.
Luckily, given that it's all my code I understand the code pretty well but I'll still check the video out, thanks! I'll definitely check out the article on simple design too, I'm about halfway through POODR right now. Thanks for the resources!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you have about two hours, I would recommend watching this youtube video:
youtu.be/aWiwDdx_rdo?t=3176
They discuss a technique where they can continuously improve the code without having to understand the code!
This does require that you have an adequate suite of tests to back you up.
The Technique
They did not take the time to understand any of the code: by slowing improving names and removing duplication, they were able to make the program more maintainable.
They eventually discovered the IChart abstraction, which made adding new chart types to the application a safe operation, since existing chart types methods would no longer need to be modified (which was their original goal).
At any point, they could have stopped working and deployed the code, since they worked in two-minute intervals and committed changes at every safe point (the code was cleaner at every check in, than when it was originally checked out).
You may also be interested in reading one of J.B. Rainsberger's articles on simple design.
blog.thecodewhisperer.com/permalin...
The article explains how improving names and removing duplication cause abstractions to surface, which allows responsibilities to be redistributed among classes. The video above is definitely a prime example of this process in action.
The four rules of simple design can be used to determine when you should strike the metal.
Beyond those tips, start slow and refactor only the pieces that you are working on currently. This will limit the amount of risk you introduce with each set of changes. This also prevents your boss from asking the question: why did feature X break, when no one worked on that feature in this deployment.
Luckily, given that it's all my code I understand the code pretty well but I'll still check the video out, thanks! I'll definitely check out the article on simple design too, I'm about halfway through POODR right now. Thanks for the resources!