Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Introducing DI in legacy code

 
Johan Pelgrim
Ranch Hand
Posts: 105
Android Java Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,

I often work with clients / legacy code where Spring or Guice, i.e. DI, is not used. I really like the DI principle because it enforces loosely coupled code and thus makes my code more readable and testable. What would be a good strategy / argument to introduce a DI framework in the legacy code case? Refactor bit by bit and attack it from the service & unit test layer? Big bang? Any experience with introducing DI in legacy code?

Cheers,

Johan
 
Alaa Nassef
Ranch Hand
Posts: 471
Hibernate Mac OS X Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would certainly go for the bit by bit refactoring. Big Bang, as you put it, is really risky, will take a lot work time with no real difference that appears to the client. The Big Bang option might be useful if you are in a stage where no new features are asked to be added to the legacy code, and you are in a stage where code cleaning and refactoring is the main target.
 
Dhanji Prasanna
author
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Certainly not big-bang.

Yes I have introduced it in a couple of applications from the ground up. The key is to start with the parts of code that are changing the most, then work your way outward. That way your immediate pain is eased a bit, and everyone on the team is using DI regularly and gets comfortable with it.

There are lots of compelling reasons in the political fight, you essentially have the good ones though: modularity, testability, loose coupling and reduction of error-prone boilerplate code.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic