Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Legacy Code: Extract-FirstUT-Cover-Refactor-TDD

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

Recently, I had the opportunity to work on legacy code with several teams from various organizations. I would like to share my experience.

We usually start by choosing a piece of code that is “painful”: changing frequently and “scary” to touch because of its complexity. We explain that our purpose is to make the code simpler, readable, and easy to change. Establishing the motivation for what we do is important!

In essence, the steps we take are:

  1.       Use extract method/rename to make the code more readable (specifically applicable for very long methods).
  2.       Write and execute the first unit test (that’s usually the toughest part) as described by Michael Feathers.
  3.       Add more unit tests until the area you want to refactor is satisfactorily covered.
  4.       Refactor to make the code more maintainable (working in very small steps, as described by Joshua Kerievsky).
  5.       Make the required change using TDD.

The purpose of (1) is to see the forest, not the trees. Long methods tend to be unreadable. Using the “extract method” helps you see clearly what’s going on. Once you gain vision, you can start to rename. Arlo Belshee talks about this.

As an example, look at these two statements:

At the first, if statement, we have extracted the condition to a method. Remember that what you do most of the time with code is read it. You need to make it readable.

Item (2), as mentioned above, is the difficult part. You need both to master the technique and have the resolution to do it. I usually do it with the entire team and so, together, we have the required courage.

For instance, take a look at this behemoth method.

Pure fun, eh? This is something I call an amusement park method. We usually start by trying to call it null. Sometimes it actually works and we have a first-unit test. Then we start to slowly fill in the parameters. Maybe instead of a null send an empty dictionary. Maybe instead of an empty dictionary send a dictionary with two entries. And if there’s no choice sometimes we run the actual application and serialize the parameters, to be deserialized in the unit test later.

Sometimes we change a method from private to public, sometimes we add a method to better control a member, and there are more vicious things we do. Sometimes it can take a whole morning to do this. However, once you understand this, it becomes very simple.

Then you start looking at coverage.

Once you have the first test, things start to move faster (3). You start adding more and more tests. You start looking at coverage reports to see which lines of code are covered and which aren’t. If something is not covered, you can add another unit test to cover it.

Now (4) we can start to make bigger changes. Once you have the unit tests in place you feel free. You make a small change, you run the test. Another small step and the tests run again. Some IDEs have plug-ins that run the tests every time something is changed.

This is the time to get better familiar with the automatic refactoring tools of your IDE. Make sure you are familiar with introducing parameters, fields, and variables. Extract class is a very nice one and so is the ability to convert a method to static and move a method. The trick here is to make as fewer manual changes as possible and move the code around fluently.

Many times by this point, there is a small disappointment. The code you feared in the morning now looks quite simple. The real challenge is making the code simple and solving the puzzle.

Now we reached the point when we can quite easily add some code to fulfill a new requirement (5). We can add a new test, see it fail, make the required change, see it pass, and maybe do a little refactoring. Nothing like the joy of seeing unit tests turn from red to green.

(the above are unit tests from a very nice exercise called Gilded Rose)

And that’s it.

Subscribe for Email Updates:

Categories:

Tags:

Kanban
Lean Software Development
Nexus vs SAFe
RSA
Kaizen Workshop
Risk Management in Kanban
Legacy Code
Continuous Integration
Scrum With Kanban
Agile Product Development
ScrumMaster Tales
Lean Agile
Professional Scrum Master
System Integration Environments
System Team
Scaled Agile Framework
Webinar
Scrum Guide
IT Operations
Agile Release Management
Self-organization
Daily Scrum
Program Increment
AI Artificial Intelligence
Lean and Agile Techniques
Agile India
SAFe DevOps
Covid19
Product Ownership
Spotify
TDD
Story Slicing
A Kanban System for Software Engineering
Agile Israel
Agile
Pomodoro Technique
speed at scale
Reading List
Manage Budget Creation
Agile Release Planning
Agile Program
Agility
ROI
Change Management
Lean Risk Management
Agile Community
Coaching Agile Teams
Large Scale Scrum
Jira Plans
Applying Agile Methodology
WIP
Jira
PI Planning
Agile for Embedded Systems
Agile Project Management
Agile Outsourcing
Sprint Iteration
Continuous Delivery
Continuous Improvement
Amdocs
Agile Contracts Best Practices
Agile Techniques
Introduction to ATDD
Business Agility
Tools
Value Streams
Games and Exercises
Agile Games and Exercises
Entrepreneurial Operating System®
Enterprise DevOps
Agile Project
Managing Projects
Kanban 101
Test Driven Development
Lean Agile Organization
Scrum Values
chatgpt
An Appreciative Retrospective
Nexus and SAFe
Nexus Integration Team
Limiting Work in Progress
Risk Management on Agile Projects
Scrum and XP
Software Development Estimation
Portfolio for Jira
agileisrael
Releases Using Lean
Scrum Master
Jira Cloud
LPM
LeSS
Hybrid Work
Acceptance Test-Driven Development
BDD
Risk-aware Product Development
SAFe
Systems Thinking
System Archetypes
Iterative Incremental Development
Development Value Streams
Lean Budgeting
Agile Games
User stories
PI Objectives
QA
Nexus and Kanban
Accelerate Value Delivery At Scale
ATDD
Video
Lean Agile Leadership
Lean-Agile Software Development
Implementation of Lean and Agile
Lean Startup
Effective Agile Retrospectives
GanttBan
Sprint Planning
lean agile change management
Legacy Enterprise
NIT
Presentation
The Kanban Method
Scrum Primer
Nexus
Agile Assembly Architecture
SAFe Release Planning
Perfection Game
Continuous Planning
Scrum.org
Agile Marketing
SPC
RTE
Agile Israel Events
RTE Role
Certified SAFe
Atlaassian
LAB
ATDD vs. BDD
Release Train Engineer
Operational Value Stream
Professional Scrum with Kanban
Agile Delivery
Managing Risk on Agile Projects
Agile Testing Practices
Lean and Agile Principles and Practices
Planning
Principles of Lean-Agile Leadership
Engineering Practices
Quality Assurance
AI
Agile Product Ownership
Process Improvement
Artificial Intelligence
Slides
Introduction to Test Driven Development
Certification
Software Development
EOS®
Agile Mindset
Lean-Agile Budgeting
ALM Tools
Elastic Leadership
Agile Basics
ART Success
Frameworks
Kanban Kickstart Example
Kanban Game
predictability
Tips
Jira admin
POPM
Agile Development
ARTs
speed @ scale
What Is Kanban
SA
Agile Risk Management
Continuous Deployment
Agile in the Enterprise
Product Management
Atlassian
Sprint Retrospectives
The Agile Coach
Scrum
Professional Scrum Product Owner
DevOps
Scrum Master Role
Agile Exercises
Code
Implementing SAFe
Lean Agile Management
Agile and DevOps Journey
AgileSparks
Built-In Quality
Kanban Basics
Rapid RTC
Achieve Business Agility
Lean Agile Basics
Kaizen
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart