DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report

Rebuild or Refactor

Is there a right answer? Is refactoring really that bad? Let's take a look.

David Bernstein user avatar by
David Bernstein
CORE ·
Nov. 16, 18 · Opinion
Like (13)
Save
Tweet
Share
13.67K Views

Join the DZone community and get the full member experience.

Join For Free

Sometimes, when an important project is going poorly there's a desire to start over. Sometimes this comes from management but often this comes from the developers themselves. They say if they only had a second chance and could start over then they can build the right system.

But that almost never happens. Take it from me. I've seen companies try many times and I can say that without exception, when a team sets out to rebuild the same system with basically the same approach, they end up with roughly the same system the started with, including the same problems only this time they have two systems they have to maintain.

Boy, I could tell you stories. Want to guess how many CRMs Microsoft had under development in the early 2000s? At one point, I counted a dozen. Twelve projects that basically did the same thing!

Legacy code gets a bad rap. People are scared to touch it but it embodies business rules and procedures that are time-tested, and even the most intractable legacy code may still hold value when used to refactor a system.

Refactoring gets a bad rap as well because developers and managers are unfamiliar with it. They don't know that there are safe ways of reorganizing their "big balls of mud" that their software has become into more manageable chunks that are independently verifiable and therefore less costly to maintain and extend.

Refactoring legacy code is often a process of breaking it up. It might have been written procedurally and worked fine for years but then, in order to improve the build and support continuous integration, code needs to be broken up into independently verifiable parts.

Don't worry. The hard part is over. The software does what it needs to do so refactoring it is really just a matter of reorganizing it. That doesn't mean it isn't easy or risk-free but there are ways of dealing with the issues that come up and the benefits of making these changes can oftentimes give companies the competitive edge.

Think of it this way, most software is written procedurally and takes a global perspective. That's fine for simple programs but as systems grow their complexity skyrockets so we needed a way to manage that complexity.

Object-oriented programming gives us a way of managing complexity by taking the behavior we want to create and putting it in a collection of "objects" that interact to create that behavior.

By doing this, we hide different parts of the system from each other. Instead of having one global perspective, object-oriented programs are composed of a collection of objects that interact to create the desired behavior.

By taking the additional step of encapsulating behavior into the right objects, we allow our systems to become more modular and independently testable through automation, which drops the cost of change for the software we produce.

This is by no means an easy task in most situations. Your legacy code got that way from years of neglect and it may take a bit of effort to clean it up but if it already does the right thing then often it's a matter of reorganizing and restructuring the code so it's in different places but the functionality remains the same. Reorganizing code is usually more straightforward than rewriting it from scratch.

Published at DZone with permission of David Bernstein, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Create Spider Chart With ReactJS
  • Microservices Testing
  • Choosing the Right Framework for Your Project
  • Integrate AWS Secrets Manager in Spring Boot Application

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: