• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question about Re-Engineering Legacy Software

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does the book get into techniques to quickly understand a legacy system? I have been faced with this many times in my career and don't seem to be getting any better at it
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rick enater wrote: I have been faced with this many times in my career and don't seem to be getting any better at it


Of all those times, how often did you try to refactor Rename or Extract Method/Constant/Field/etc. to make the code clearer and better organized? One curious thing I have observed about developers over the years is their indifference to poorly chosen names. They seem to be so inured to these and will simply sit there scratching their heads, accepting the burden that the previous programmers have placed on them to wave their way through the fog that these poorly chosen names have shrouded the intent of the software in. I can't tell you how often I have to say to other developers during code reviews, "Why don't you just rename that variable or method then? What are you so afraid of? It's just frickin' code!"
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And Welcome to the Ranch, Rick!
 
Bartender
Posts: 3225
34
IntelliJ IDE Oracle Spring Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The way I have been working on legacy code is to get your hands dirty, as Junilu said one way is to refactor and test. If you are trying to understand the complete system in one go, that would be difficult. You can deal with the code on an usecase basis.
So you pick one usecase and play around with the code which is created for that usecase. Generally usecase would be a set of actions in the system, so you can go into the code and look for the code associated with those actions.

Also if there are people in the team who have worked on the system, you can get some knowledge by interacting with them. You can also run through the usecases with the stakeholders and correct your understanding about the usecases.

The approach mentioned by Junilu is referred to as - The Boy Scout Rule.
 
Author
Posts: 18
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Like the other commenters suggested, exploratory refactoring is the best way I know to find my way around a new codebase. Randomly choose an important-sounding file and open it up. Add comments, rename fields and methods to make them easier to understand, extract separate interfaces for each of the concrete class's concerns, ... and whatever else takes your fancy. I often start by giving classes and methods ridiculously long and descriptive names like processABatchOfItemsAndStoreTheResultInTheDBAndThenSendAnEmailAboutIt(). These names stand out in the code, acting as useful markers of code that should be refactored later.

Most likely you're doing all this refactoring without any tests to back you up, so you might end up throwing it all away at the end for fear of regressions. This is not a problem at all, as the act of doing the refactoring will have been a valuable learning experience.

It's also worth trying tools to generate a UML class diagram (most IDEs can do this for you). For a large codebase, an auto-generated UML diagram will probably be huge and chaotic, but it at least gives you a birds-eye view of how everything fits together. You could also auto-generate an ER diagram if the software uses an RDB.

Another way to learn about a project that seems obvious but is often neglected: ask somebody! No matter how old a piece of software is or how many generations of developers it has passed through, there must be somebody out there who knows something about it. Ask around and gather any clues you can. This includes not only engineers but people on the business side as well. If it's an in-house app, you might be able to talk directly to the software's users. For example, a user might be able to tell you that a certain feature is obsolete and no longer needed, allowing you to delete a large chunk of dead code.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Chris Birchall wrote:Another way to learn about a project that seems obvious but is often neglected: ask somebody!


"What we've got here is failure to communicate!" —Captain, in Cool Hand Luke (1967)

That's certainly a curious thing I have observed as well. There's something about asking other people what's going on and how that might reflect on yourself. I think culture has a lot to do with it and people with certain cultural backgrounds are more inclined to try to figure things out by themselves rather than ask somebody who might know more and be able to help. Globalization and the ever-growing prevalence of geographically dispersed teams seems to make these issue more apparent and in some cases it helps when you have more outspoken people on your team and that trait starts infecting others. It remains a major hurdle on many projects though.
 
You are HERE! The other map is obviously wrong. Better confirm with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic