Understanding other peoples code, functionality, applications

[jamsandwich]

I've had several software developer jobs working on business applications with Microsoft tech stack, although I guess this is a fairly generic question about working as a programmer doing bug fixes, maintenance and enhancement (as opposed to greenfield development on a totally new application).

Up until recently, I've managed to gain enough understanding of a legacy app to be able to work on it by reading through the relevant area of code in the IDE and playing around with the front-end app in a dev/test environment.

However, I started a new job recently (still as a software developer) working on maintenance and enhancement of an existing application which is quite large and complex with many separate components. In this job I've found that I've struggled when trying to apply my usual method of understanding an application that is new to me.

I thought it might help if I modelled some areas of functionality by drawing some UML diagrams (class diagrams, sequence diagrams, etc) so I began doing this. I found it quite time consuming and had difficulty in knowing how much detail to add (e.g. some classes had a lot of properties & methods). I tried to leave out all except those that were most relevant to what I was working on. I'm not sure how much this really helped me. Then again, I've not done much with diagramming notation, whether UML or other type. I wonder if I should practice drawing UML diagrams more in order to gain greater understanding of the concepts and notation, and that maybe doing that might help me model existing code better and gain understanding of it quicker.

Has anyone had much experience of diagramming/modelling like this, or are there other ways of gaining understanding of legacy code that might help me?

Thanks.

[cojak]

I've had several software developer jobs working on business applications with Microsoft tech stack, although I guess this is a fairly generic question about working as a programmer doing bug fixes, maintenance and enhancement (as opposed to greenfield development on a totally new application).

Up until recently, I've managed to gain enough understanding of a legacy app to be able to work on it by reading through the relevant area of code in the IDE and playing around with the front-end app in a dev/test environment.

However, I started a new job recently (still as a software developer) working on maintenance and enhancement of an existing application which is quite large and complex with many separate components. In this job I've found that I've struggled when trying to apply my usual method of understanding an application that is new to me.

I thought it might help if I modelled some areas of functionality by drawing some UML diagrams (class diagrams, sequence diagrams, etc) so I began doing this. I found it quite time consuming and had difficulty in knowing how much detail to add (e.g. some classes had a lot of properties & methods). I tried to leave out all except those that were most relevant to what I was working on. I'm not sure how much this really helped me. Then again, I've not done much with diagramming notation, whether UML or other type. I wonder if I should practice drawing UML diagrams more in order to gain greater understanding of the concepts and notation, and that maybe doing that might help me model existing code better and gain understanding of it quicker.

Has anyone had much experience of diagramming/modelling like this, or are there other ways of gaining understanding of legacy code that might help me?

Thanks.

Get hold of a 30 day installation of Sparx Enterprise Architect and use that to create your models.

A couple of hours on YouTube and reading the excellent user guides will get you started.

[Hobosapien]

Shirley the app already has plenty of comprehensive up to date documentation from the original development project. I know, only joking.

Presuming the IDE is of Visual Studio calibre, if so I've reverse documented apps into a technical specification (when a company bought out another and wanted to know how poorly documented software worked so it could be modified or replaced) by starting with the UI elements such as menu, buttons, and other user actions that trigger events.

Put breakpoints on the app start up and all relevent events and see where the code goes when using the UI. Visual Studio makes this simple by stepping through or over code so can get a good idea of how it hangs together at runtime using the debugger. Obviously need to do this with the version of code in production but using a test environment so don't have to worry as much about it changing any data.

If there are seperation layers such as APIs or services, search the entire codebase for the public function/endpoint names to see if they're actually used anywhere. I once cleaned up a webservice by doing this to identify which public functions out of about 400 were still referenced anywhere. A suprising number weren't so that helped by identifying the obsolete ones so didn't have to spend any more time tracing those or worrying what they did. I commented out the codepaths no longer used so easy to identify active code, then checked it still compiled as I went through it so could find active references easily.

Certainly find that type of approach more productive than trying to just look at the code, many parts of which may be obsolete or orphaned and no longer used.

This is a bit old skool as I've not had to do such a task for some years, so there may be better tools to generate docs from code, or profile code for active paths and reference trees and other useful stuff that should be easy to automate so likely someone has done that work already.

[GhostofTarbera]

If it’s in RPG put into debug mode a walk through the live code


Sent from my iPhone using Contractor UK Forum

[RasputinDude]

+1 for enterprise architect

Back in the day, when I was doing tech due diligence on acquisitions, I found it really helpful for understanding some systems.

[NickFitz]

+1 for stepping through the code in a debugger.

As it takes time, just do it for the bits you're actively interested in. Step in from those high level pieces of functionality to the lower level stuff when it seems likely to lead to something interesting, or when you see a lot of stuff happened in there after you stepped over it.

There's no better way of building a mental model of what the code is doing than, quite simply, watching what the code is actually doing from the inside