In this situation, you have your work cut out for you, but it is not impossible. You will need to organize things a bit for your own sake. The actions you will need are:
- Collect the specifications, manufacturer manuals, etc. you can. You'll need to familiarize yourself with how the SCARA robot is controlled and what acceptable parameters are. Don't assume someone else has done their due diligence for you.
- Discover how the files are organized. It might look like a mess to start with, but eventually you'll learn which file(s) to look in. If the current organization of the application doesn't seem to make sense, spend some time adding some order. Some people still like to put everything in one file, esp. if it's a small app. You might consider breaking files up that have multiple classes so that there is one class per file. That makes it easier to find the file you need.
- Attempt to recognize patterns that are being used. The GoF book "Design Patterns" provides some blueprints for common approaches to solving some problems. The code you see in the wild may not conform exactly to the way they are described in the book, but you can at least get an idea of what the code is supposed to be doing.
- Comment the critical sections. The hard part is finding out what the critical sections of code are. That's what the previous steps were doing. Now that you've got an idea of what they are, it's time to really analyze what is happening. You'll have your manuals and specifications open for reference, but you will have to trace the application line by line to come up with the intent behind the code.
In this last step, you are going to want to take frequent breaks and keep asking yourself why is the application doing X or Y. Basically you are trying to figure out if you are in a forest or a jungle by looking at the leaves around you. But that's all you have at the moment. As you go through pass by pass, you will start to get a mental model for how the code is actually working. As you start to recognize the patterns and how things are working, change your comments because you need those to "get it". As you look at the new comments and code, you might be able to get to another level of abstraction away. You can add those comments, or change the comments you have as it makes sense.
Remember, you are trying to build some familiarity with the code. In the absence of the developer who wrote it, this is all you can do. This is also how I learned assembly programming way back in the day. The higher level concepts are there, but it takes time to zoom out as it were.
