Not a programmer by profession but job entails perl/expect scripting. Generally that means that I/others write scripts for what I/they want/need and I/they support mine/theirs.
Due to a recent departure, I now have to support some perl scripts with 10k+ lines of code and little documentation.
Obviously, I can read the code but the sheer size of the files makes quickly understanding everything in the code a daunting task. Just wondering about the approaches used by others when taking over support for someone else's work.
When you and nobody in the group have the knowledge:
1) Reach to other groups in the company.
2) Ask management to hire a consultant to help and teach.
If by recent, you also mean sudden, then chances are you had no "hand-over".
For the most part, I hate maintaining other peoples' code. Everyone writes code differently, thinks differently, approaches problems differently, etc. And even the same person over time will code, think and approach problems differently. And they will maintain that code accordingly, and over time you end up with a 10k-line perl script that could be boiled down more specifically to what you know the problem today to be.
It's usually more important to know what the code is intended to accomplish, than how it might be doing it.
Perhaps your first task should be to break down that monolith, into manageable pieces, documenting it as you go. This would aid your understanding, and anyone else who had to use it would thank you!
As for "quick", there's probably no fix. Just bite the bullet and dig in!