Now that you know what constitutes refactoring (see Part 1 of this series), how can you tell what really qualifies as a worthwhile refactoring? Bob Grogan suggests some big hits that were popular immediately, others that eventually reached groundswell stage, and some that aren't quite there yet.

Like this article? We recommend

Introduction

After a much needed (and frankly job-related) absence, I have the opportunity
to continue what was a rather large subject. The thesis of my last article was
that various areas of lifein the U.S. in particularare constantly
undergoing a cycle of "create and consolidate." It seems as soon as
someone or some company creates a unique or novel object, process, or software
application, there exists a broader entity waiting to consume or subsume that
concept. In some cases, this is because the synergy makes sense and the result
is a uniquely valuable combination. In other cases, it's a misguided effort
or just outright profiteering.

In the first installment of this series, I put forth some basic criteria to
consider before attempting a combination (or refactoring). These were loosely
termed context, customer acceptance,complexity, and scale.
Context involved the assertion that combinations could be well-advised in
some circumstances but not others. Customer acceptance provided a
reminder that many different types of people must believe in the idea for it to
be a good idea. Complexity put forward a justification for a cost/benefit
analysis (CBA) to fully assess validityin other words, "Yes, it can
be done, but is it worth the effort?" The final criteria of scale is
the firmly held belief that corporations, government programs, even screwdrivers
can simply be too big. With these criteria in mind, I would like to illustrate
some real examples of refactoring.