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
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

Code Transformations

New features and add-ins are often simply stack on top of existing code when developers should be considering how to change it completely.

David Bernstein user avatar by
David Bernstein
CORE ·
Nov. 10, 18 · Opinion
Like (1)
Save
Tweet
Share
5.83K Views

Join the DZone community and get the full member experience.

Join For Free

A lot of poor designs can be attributed to sticking with an existing design as changing requirements show us the need for a better one. Oftentimes, an initial design is just a stab in the dark. We might not know enough to make an informed decision but we have to get something done, so we do what Agile says and we code up the behavior that we need right now and not worry about future requirements.

For most teams, the problem comes when they start to enhance that behavior and go back into the code to extend it. Now they're asking the system to do something that it couldn't do before and, instead of redesigning a feature to accommodate the new behavior, developers might try to hack in the new behavior while minimally impacting the existing design. But this can degrade the quality of the code when done over and over again in a system.

What if we don't have to get it right the first time? What if we could start off with a crappy design but improve it over time as we learned more about how the design should be and what behaviors it should be able to accommodate?

It turns out that often a "learn as you go" approach is more efficient and effective than the "figure it all out upfront" approach. It turns out that most of the time, in order to go from one design to another design in code requires a minimal effort. Code refactoring is a reliable, safe and effective way of transforming the design of software, which we typically need to do in order to accommodate new features.

We often stick with an existing design because it's what we know but this is something that's going to have to change in our industry. We have to be willing to change our designs in light of new information and pay off technical debt when we do it.

The book Refactoring: Improving the Design of Existing Code by Martin Fowler is an essential text for all developers. It teaches us about common transformations in code that allow us to clean up existing software so that it's more extensible and reliable.

Reading this book and learning how to refactor code has been very freeing for me. It means I don't have to get the design right the first time. In Agile, that's rarely possible anyway because we often start building software without a complete set of requirements so we're always dealing with unknowns. Knowing what it takes to go from one design to another in software means that we don't have to get it right the first time. It means we can start out with the wrong design and change it later without paying a high price.

So, our initial design doesn't really matter, as long as we can change it later to a better design without a lot of rework. This takes the pressure off of us to get it right up front and is actually a very efficient way of building software. It means that we can emerge features as they're needed and this turns out to be a highly effective way of building many kinds of software systems.

Design

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

  • Top 5 Node.js REST API Frameworks
  • Problems of Cloud Cost Management: A Socio-Technical Analysis
  • Silver Bullet or False Panacea? 3 Questions for Data Contracts
  • OpenID Connect Flows

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: