По одному фрагменту за раз.
Когда вам нужно внести изменения, напишите тесты для того, что вы изменяете. Затем безопасно внесите изменения. Со временем вы получите более чистый код, в котором есть тесты.
Я бы сделал это, чтобы очистить код, если он еще не очищен (выровняйте фигурные скобки и т. Д.). Самые достойные текстовые редакторы иметь эту встроенную функцию (eclipse, netbeans.)
Тогда я бы, вероятно, просмотрел приложение и проследил, куда меня ведет логика, совершил круиз по коду и ознакомился с тем, как предыдущий разработчик (и) справлялся с вещи.
По одной функции за раз. Предполагайте немногое и комментируйте (про себя) по ходу дела. Я недавно тоже так делал - мне дали программу на "c++", которая в основном на 99% состоит из c, а основной модуль написан в одном монолитном классе. Если у вас будет достаточно времени, вы освоитесь с кодом и сможете прыгать в нем с некоторым комфортом. Только не начинайте ничего менять по крайней мере в течение первой недели. Пока вы не поймете, что именно происходит, вы будете потом пускать себе пулю в ногу.
Через несколько дней все будет не так уж плохо :)
Есть ли у него контроль исходных текстов? Просмотрите историю изменений.
Если нет, поставьте его под контроль исходников. Вы неизбежно будете вносить ломающие изменения. Отсутствие документации по ожидаемому поведению гарантирует это. Если вы будете старательно проверять свои изменения по ходу работы, вы сможете сделать откат и переделать все заново.
Создавайте документацию по ходу работы. По мере того, как вы узнаете, что код делает или должен делать, документируйте это.
Если код находится в состоянии выполнения, один из подходов - установить точку останова в начале приложения и пройти через типичное выполнение в отладчике, чтобы увидеть, что код делает на самом деле (в отличие от того, что вы думаете, что он делает).