Tools - Refactoring HTML: Improving the Design of Existing Web Applications - page 24

Chapter 2. Tools

Automatic tools are a critical component of refactoring. Although you can perform most refactoring manually
with a text editor, and although I will sometimes demonstrate refactoring that way for purposes of illustration,
in practice we almost always use software to help us. To my knowledge no major refactoring browsers are
available for HTML at the time of this writing. However, a lot of tools can assist in many of the processes. In this
section, I'll explain some of them.

Backups, Staging Servers, and Source Code Control

Throughout this topic, I'm going to show you some very powerful tools and techniques. As the great educator
Stan Lee taught us, "With great power comes great responsibility." Your responsibility is to not irretrievably
break anything while using these techniques. Some of the tools I'll show can misbehave. Some of them have
corner cases where they get confused. A huge amount of bad HTML is out there, not all of which the tools
discussed here have accounted for. Consequently, refactoring HTML requires at least a five-step process.

1. Identify the problem.

2. Fix the problem.

3. Verify that the problem has been fixed.

4. Check that no new problems have been introduced.

5. Deploy the solution.

Because things can go wrong, you should not use any of these techniques on a live site. Instead, make a local
copy of the site before making any changes. After making changes to your local copy, carefully verify all pages
once again before you deploy.

Most large sites today already use staging or development servers where content can be deployed and checked
before the public sees it. If you're just working on a small personal static site, you can make a local copy on
your hard drive instead; but by all means work on a copy and check the changes before deploying them. How to
check the changes is the subject of the next section.

Of course, even with the most careful checks, sometimes things slip by and are first noticed by end-users.
Sometimes a site works perfectly well on a staging server and has weird problems on the production server due
to unrecognized configuration differences. Thus, it's a very good idea to have a full and complete backup of the
production site that you can restore to in case the newly deployed site doesn't behave as expected. Regular,
reliable, tested backups are a must.

Finally, you should very seriously consider storing all your code, including all your HTML, CSS, and images, in a
source code control system. Programmers have been using source code control for decades, but it's a relatively
uncommon tool for web developers and designers. It's time for that to change. The more complex a site is, the
more likely it is that subtle problems will slip in unnoticed at first. When refactoring, it is critical to be able to go
back to previous versions, maybe even from months or years ago, to find out which change introduced a bug.
Source code control also provides timestamped backups so that it's possible to revert your site to its state at
any given point in time.

I strongly recommend Subversion for web development, mostly because of its strong support for moving files
from one directory to another, though its excellent Unicode support and decent support for binary files are also
helpful. Most source code control systems are set up for programmers who rarely bother to move files from one