This “Refactoring” project started in January 2022, based on an invited talk for Princeton Chapter of ACM.
Refactoring is a useful development tool for maintenance programmers and agile development teams. Developers focus on techniques for improving existing code in a safe way.
Anyone who works with legacy code is familiar with a key software engineering problem: the unpredictable nature of software change. Whenever developers make changes to a “working system,” the code base loses some of its design integrity. A well-designed code base will slowly become more chaotic over time. Bug fixes and new feature code may be added under time pressure, with inadequate consideration for overall software quality.
For many decades, software developers have recognized situations where they need to “invest in cleaning up” an old application or an old code library. Beginning in the 1990s, a number of tools to support the process of code cleanup began to appear: refactoring tools.
This project page is still under construction, but we plan to add links to more books and resources. Note that "refactoring" means different things to different people:
This talk (refactoring_talk_2022.pdf) is an overview talk on Refactoring (from January 2022).
The following essay on refactoring is derived from the January 2022 talk: Refactoring Essay (PDF)
“Legacy software” is the set of software components, libraries, tools, or systems that are still providing positive value to their users. User needs are constantly changing, which creates both problems and opportunities.
This talk (legacy_talk_2023.pdf) is an overview talk on Legacy Software issues (from March 2023).
You may encounter some so-called experts who will explain to you that it is OK to "refactor" even if you are making code changes that modify your application's behavior. But they are advocating a risky practice.
Most sensible developers will start out with simple refactorings that preserve the original behavior -- and after those initial refactorings have been tested, then they are ready to make small behavior modifications to the refactored code (to fix bugs or to add new capabilities). If you are impatient and want to make all of the changes at once, it might not end well. You will have a harder time dealing with the task of running adequate tests on your modified code.
The following books have a lot of good information about refactoring:
Michael Feathers has promised a new book on refactoring in 2022: Brutal Refactoring
Some refactoring resources on the web:
More articles on refactoring practices:
If you want to get serious about doing refactoring, there are several technologies you might want to learn about as part of your first refactoring project.
1. Learn how to use a Version Control System for your code
If you aren't using a version control system yet, "Git" is one of the most popular and useful -- both for solo developers and for teams. Check out https://docs.github.com - the GitHub documentation site - for information how you and your team can use Git to manage your source code.
2. Learn about "Code Smells"
Start with Martin Fowler's brief introduction: https://martinfowler.com/bliki/CodeSmell.html. Remember what Martin says: "smells don't always indicate a problem. Some long methods are just fine. You have to look deeper to see if there is an underlying problem there - smells aren't inherently bad on their own - they are often an indicator of a problem rather than the problem themselves."
Read some of the common Code Smell catalogs:
3. Learn about how to write small unit tests
There are a number of good introductory books on unit testing, and it doesn't matter where you start. Find a book that shows unit test examples in your favorite programming language.
You should do some hands-on practice: both on the simple examples in your chosen tutorial book *and* on small samples of your own code.
4. Get started!
Don't obsess about refactoring tools - but if you are already using a good interactive development environment [IDE], it is OK to try out some of its refactoring capabilities. But you can learn a lot just from doing manual refactoring.
It is useful to have one of the refactoring tutorial books next to your elbow when you do your first refactoring project, but it isn't essential. Be brave and try to use some simple refactorings to clean up your code on your own!
Don't forget: After each refactoring step, you need to recompile and "test" as a check that your refactoring didn't change anything. (Of course, if you are using a language that doesn't need to be compiled, such as Python or Javascript, you will skip the "recompile" step. In non-compiled languages, there is a big risk that one of your refactorings has created an "undefined variable" or "undefined function," and you will only discover this when you *test* your code.)
Why is testing important? The second-worst thing that can happen after refactoring is "your code crashes." The *worst* thing that can happen is that "your code actually runs, but it generates bad output or exhibits bad behavior... but you didn't notice." Testing is essential because small errors might accumulate to become big errors!