Changing code is scary. With the wrong move, everything can break. But how do you adapt it to changes?
Refactoring is supposed to help, but how do you know where to start?
You can write the best code in the world, but it will often change because of:
- a better technique
- a new library or framework
- changing requirements
- or even a user changing how they use the application
The one thing that remains constant with software is change.
Are you afraid of refactoring?
Redmine is over 58,000 lines of code.
Redmine has controllers with over 400 lines of code and direct SQL queries.
But I don’t have any tests!
Redmine barely has a 82% test coverage and a 1:0.7 code to test ratio. There are major parts that don’t even have a test.
Yet I was still able to perform dozens of refactorings on Redmine. There is no reason you can’t use refactoring to clean up your application.
Confused when your peers talk about refactoring?
Have you ever heard other programmers talk about refactoring but didn’t understand? Or you don’t know the difference between a Pull Up Method and Move Method?
Do you want better quality code?
When you use the examples in Refactoring Redmine to learn about refactoring, you will start to think about refactoring all of the time. Then you will recognize potential refactorings in your own codebase, leading to leaner code.
Want to recognize potential refactorings in your own code?
The more refactoring examples you see, the better you will notice where refactoring can be used in your own code. With some practice, you’ll begin the habit of refactoring. This habit is one thing that separates good programmers from great programmers. Great programmers know when they write bad code and take the time to clean every line of code they write (i.e. refactor).
Refactoring isn’t magical, just for the cool kids, or out of reach.
Refactoring is a skill that can be learned just like any other. It also takes a lot of practice and learning to do it well.
Learn from real code used in over 100,000 sites
Refactoring Redmine is a compilation of 82 different refactorings that I’ve done to Redmine during 2010. These are real world refactorings, done to real production code used on thousands of sites every day. No made up or fake examples in here, just the real stuff.
Follow along in the git repository
Each refactoring includes a link to the full refactoring online on Github where you can view the diff and see all of the other changes in the tests, routing, and views.
Redmine is open source, so you can even download the full source code to try out the refactoring on your own.
See the Before and After of every code change
Each refactoring includes both the before and after code so you can compare the changes side by side with the major changes highlighted.
Real examples… real code
Why do real examples matter? When compared to fake examples, real examples show:
- how a small refactoring affects the entire system
how smaller refactorings build on top of each other
- what real production code looks like (i.e. messy)
- how to adapt the refactoring to work around potential problems
Learn which refactorings are the most useful
(and which should be left in your toolbox)
Do you really want to memorize all 93 refactoring methods, when all you need are a handful? How about two methods?
In the 82 refactorings, I only had to use 15 different refactoring methods. But over 56% of the refactorings came from two methods.
P.S. You rock for reading this far! Now buy the book and learn how to refactor Rails.