A very limited understanding is available across the remaining junior developers. Please share your strategies.
views:
111answers:
4
+2
A:
Hi there.
One way to help you understand the code is to use SandCastle which is a free tool for generating documentation of .NET source code. In conjunction with this tool, use SandCastle Help File Builder which is a free GUI front end for SandCastle and can help speed up the creation of help files.
EDIT: If you don't like SandScastle, then there is also NDoc Alpha which I've used in the past and found to be very good also.
Cheers. Jas.
Jason Evans
2009-12-05 22:10:13
Would be most useful if the main developer provided adequate XML comments in his code.
Robert Harvey
2009-12-05 22:11:35
Yeah, unfortunately if the main dev hasn't bothered with XML comments, all you'll be left with are the class names, their properties, methods, etc. This is still very useful though. Oh, I almost forgot, make use of .NET Reflector http://www.red-gate.com/products/reflector/ . You can use this to work out the legacy code is being used.
Jason Evans
2009-12-05 22:13:39
Next to that, those kind of 'helpfiles' do not really give a good overview of the structure of the project. (Which classes are related to which classes, etc... ).
Frederik Gheysels
2009-12-05 22:15:18
Looking at comments left by users at the SandCastle home page, there are apparently some concerns about usability. Any thoughts on this?
Robert Harvey
2009-12-05 22:17:50
There are no comments in the code :)
CodeToGlory
2009-12-05 22:56:30
+1
A:
1) If you still have access to the senior developer, ask him to produce a document providing a high level map of the system, so that you can figure out what classes work with what classes, and which parts of the app are responsible for what functionality in the system. This will spare you time by giving you a sense of how the whole thing is supposed to work together.
2) I heard a while back someone say that the only comment valid in code is "DON'T CHANGE THIS". In that spirit, ask the senior dev to list all the "sensitive" pieces of the system, and explain why they are sensitive/what to pay attention to. You want to know what you can change without being worried, and what places are minefields.
3) State unit testing the system, if it's not unit tested yet. Great way to build documentation and to understand how things really work.
Mathias
2009-12-05 22:28:11
+1
A:
Before documenting the system, you need to understand it. I just watched Code Visualization, UML, and DSLs, a video from the recent PDC 2009 event. It shows how to use the new tools in VS2010 to help understand a code base.
One interesting thing is that these tools work with code from .NET 1.0 onwards. They also don't need the source code in order to be useful.
I recommend downloading VS2010 beta 2 (Ultimate Edition), and installing it either on a VM or on a non-production machine. Use these tools to help you to understand the code base. You can then use the documentation method of your choice to document your new understanding.
John Saunders
2009-12-05 22:40:40
Thanks for the link! Spent 60 mins on this video and am impressed this vs2010 can definitely help me understand this code base.
CodeToGlory
2009-12-06 00:44:41
A:
Documentation is valuable if it's good (and often it isn't), but you still need someone to take over ownership of that code. Find the junior developer who's best at reading code, get him and the senior developer in the same room, and hopefully information will be transferred.
The junior developer should be assigned a concrete task, e.g. writing unit tests, writing documentation, fixing bugs, making simple extensions...
Joh
2009-12-05 23:30:42