Menu
Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.
-- Fred Brooks, The Mythical Man-Month [Emphasis mine]
Build one to throw away. That's what they told me. Then they told me that we're all agile now, so we should Refactor Mercilessly. What gives?
Is it always better to refactor my way out of trouble? If not, can anyone suggest a rule-of-thumb to help me decide when to stick with it, and when to give up and start over?
753
Rewrites differ from refactors because refactors take the existing code and improve it, while rewrites throw away the old code before starting on the new. Instead of rewriting code, learn better refactoring techniques.
With continuous refactoring, the useful life of an Enterprise's investment in software assets can be extended as long as possible, and users can continue to experience a flow of value for years to come. Refactors enable an emergent design to ensure the system continues to meet future business needs.
But what is Refactoring? -It is a scientific process of taking existing code and improves it while it makes code more readable, understandable, and clean. Also, it becomes very handy to add new features, build large applications and spot & fix bugs. It is a law of nature for fully successful iterative projects.
If you're doing test-driven development, you can refactor your way out of almost any trouble. I've changed major design decisions without much trouble, and rescued decade-old codebases.
The only exception is when you've discovered that your architecture is completely wrong from beginning to end. For example, if you wrote your app using threads, but you discovered that you wanted a bunch of asynchronous state machines. At that point, go ahead and throw away the first draft.
73
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
