I have A LOT of this to deal with right now. There are whole libraries used across multiple webapps and services that are completely undocumented. No javadocs, no comments in the source code, no flow diagrams, no written explanations, nothing.
Some of these libraries don't even have source code attached to them, and of course there are no information about them whatsoever on the internet, so they must have been developed internally, or even worse, borrowed from mysterious sources.
Needless to say that the original devs are long disappeared, even before I joined the team.
Now what would you do about it? Should we invest time in analyzing it and produce some documentation? Should we rewrite the whole thing?
It is worth noting that the libraries appear to work correctly, so you know, don't fix what ain't broken, but it still is a maintenance hell... Inputs will be appreciated
This is the "Big Ball of Mud" architectural pattern -- by some accounts, the most successful of all such patterns by sheer volume and running implementations. {0}<p>Eric Evans and Foote describe a strategy of walling off new code in this conversation {1}.<p>I'd suggest favoring working code over ideology as sound engineering practice. Professionals are paid to do things that kind of suck.<p>Good luck.<p>{0}: <a href="http://www.laputan.org/mud/" rel="nofollow">http://www.laputan.org/mud/</a><p>{1}: <a href="http://www.infoq.com/interviews/eric-evans-brian-foote-design-discussion" rel="nofollow">http://www.infoq.com/interviews/eric-evans-brian-foote-desig...</a>
Ah, the mythical re-write. Much harder to do when you don't have the original source, because you have no idea what's going on besides sometimes-opaque side effects.<p>You start by trying to identify those side effects. You write integration tests so you have <i>something</i> to work against. You pick small pieces and re-implement. You use whatever tooling you can to identify dependencies and flows (e.g., Structure 101). You use AOP to stick in flow tracing.<p>You weep a lot.