Refactoring - Refactoring HTML: Improving the Design of Existing Web Applications

HTML and CSS Reference

In-Depth Information

However, while the back end of a large networked application is often a relational database, the front end is a

web site. Thin client GUIs delivered in Firefox or Internet Explorer everywhere are replacing thick client GUIs for

all sorts of business applications, such as payroll and lead tracking. Adventurous users at companies such as

Sun and Google are going even further and replacing classic desktop applications like word processors and

spreadsheets with web apps built out of HTML, CSS, and JavaScript. Finally, the Web and the ubiquity of the

web browser have enabled completely new kinds of applications that never existed before, such as eBay,

Netflix, PayPal, Google Reader, and Google Maps.

HTML made these applications possible, and it made them faster to develop, but it didn't make them easy. It

didn't make them simple. It certainly didn't make them less fundamentally complex. Some of these systems are

now on their second, third, or fourth generation—and wouldn't you know it? Just like any other sufficiently

complex, sufficiently long-lived application, these web apps are developing cruft. The new pieces aren't merging

perfectly with the old pieces. Systems are slowing down because the whole structure is just too ungainly.

Security is being breached when hackers slip in through the cracks where the new parts meet the old parts.

Once again, the choice comes down to throwing out the original application and starting over, or fixing the

foundations, but really, there's no choice. In today's fast-moving world, nobody can afford to wait for a

completely new replacement. The only realistic option is to refactor.

Why Refactor

How do you know when it's time to refactor? What are the smells of bad code that should set your nose to

twitching? There are quite a few symptoms, but these are some of the smelliest.

Smell: Illegible Code

The most obvious symptom is that you do a View Source on the page, and it might as well be written in Greek

(unless, of course, you're working in Greece). Most coders know ugly code when we see it. Ugly code looks ugly.

Which would you rather see, Listing 1.1 or Listing 1.2 ? I don't think I have to tell you which is uglier, and which

is going to be easier to maintain and update.

Listing 1.1. Dirtier Code

<TR><TD WIDTH="70"> <A HREF="http://www.example.com/" TARGET=

"_blank"

>

<IMG SRC="/images/logo-footer.gif"

HSPACE = 5 VSPACE="0" BORDER="0"></A></TD>

www.example.com/" TARGET="_blank">Example Inc.</A>.

<A HREF="http://www.example.com/legal/index.html"

TARGET="_blank">Legal Notice</A> -

<A HREF="http://www.example.com/legal/privacy.htm"

TARGET="_blank">Privacy Policy</A> - <A HREF="http://www.example.com/

legal/permissions.html"

TARGET="_blank">

Permissions</A>

</td>

</TR></TABLE>

Listing 1.2. Cleaner Code

Search WWH ::

Custom Search

Home