Sorry for the very late follow up.
The topic discussed during my session was around the options available for making legacy codes more maintainable and understandable.
Problem: the software was not well designed when started out 5 years ago with no proper documentation. As it was not well thought through, we faced a lot of issue maintaining and analysing the code.
Options available: rewrite, clean up the code as we make changes or prepare documents
It was suggested that the way to get out of this is to do a lot of unit testing and create test cases around the functions affected every time someone touches the set of codes. This will mean it will take longer to produce any new enhancements on top of it but it will make the codes easier to understand through testing.
It will be a waste of time to rewrite the product with the same features all over again.
Charmaine Chong
Executive Director, Development
DID: +65 6304 7543
Mobile: +65 9800 2927
Main: +65 6304 7500
Fax: +65 6474 5890
Email: charmai...@lanworks.com.sg
Web: www.lanworks.com.sg
Office: 6 Commonwealth Lane, #01-01, GMTI Building, Singapore 149547
LANWorks
IT from a Business Perspective
We want to do the best we can for you. Please let us know how we can improve by emailing me or my Manager, Abu Omar at abu....@lanworks.com.sg
Hi,
I did not attend the session, but I hope I can contribute something useful here.
Poor legacy codes that are not understandable is a common problem. Heavy investment into refactoring will not work if the development team has poor coding habits. Every line of code they write becomes legacy code the next day, or a week later. Thus, even if the team do take the time to do major refactoring, the code gets degraded very soon.
1. Stop code degradation. This means that using the current set of codes as a baseline, any further modification should not make it worse. This can be achieved through using such as code metrics – like McCabe complexity, lines of code per method or file, etc. So, get people into the habit of writing good code from now on.
2. Once you have code metrics in place, you can look at areas that need improvement. If you are using refactoring tools, the tools guarantee that changes will not break the system. This is only useful for simple refactoring, not major ones. However, still it is a good start. Again, the whole idea is to have to get into the habit of writing good code and tidying up.
Of course this is all easier said than done.
Cheers
-- Pan-Wei Ng, Ph.D.
Ivar Jacobson International