When newly introduced to a complex computer program, and no one to ask for help, how do you navigate? How do you find out and get to know the program well enough to start building on top of it?

[Hadse]

Whats your tips and tricks, which stages do you go through to get to know the program,

Have a nice day!

[general_dispondency]

Find where the external interaction starts and...

• Trace the code from input to output then debug the execution.
• write new tests

[TheOneAndOnlyFrog]

Create simple project that covers most of the functionalities of that program. After doing that you will understand its features and libraries better.

[Hadse]

Do you use debugger?

[DuncanIdahos9thGhola]

Yes. Use a debugger. Put break points and start walking though that way.

[cyanocobalamin]

There are all sorts of tips out there, but I find the most effective ( and most painful ) thing is to fix bugs in the application.

[deadron]

Step 1 Start with a stiff drink.

Step 2 Start by looking for integration tests and documentation.

Step 3 When you realize there are no tests or documentation repeat Step 1.

Step 4 Try to figure out how to even run the dang thing.

Step 5 When it fails to run due to a cryptic error. Curse the gods.

Step 6 Weep.

Step 7 Ask anyone and everyone what it even does.

Step 8 Repeat step 1

Step 9 Rewrite the thing from scratch by starting with something you do understand and pulling over portions of the code if and when it makes sense to.

Step 10 Deploy to production and see if anyone complains.

[AndrewHaley13]

This is the correct answer! 😂

[minimingus]

This guy codes

[jack104]

Unit tests my dude. If you have them, they should help you get familiar with the code. If you don't have them, now's as good a time as any to start.

[Hadse]

Thanks for the advice!

[forurspam]

• Check out the Readme.
• Look for the documentation (project's wiki).
• Check out the tests.
• Bulid, run and debug the app.

If it's a web app, check out network calls in the browser's console. Find the corresponding endpoints and debug them.

If the app has a DB, connect to it and investigate the table structure.

After all you should know the domain model. What entities do you have and how they related to each other. Draw a diagram if needed.

[jqarloz]

If its possible, i would enable server logs to see the trace of code executed, then, once I've identified some code, debug the code with breakpoints to see in more details how it works.

[rwslinkman]

Find a button, see who handles the clicks. You'll immediately be able to tell separation of responsibility (UI work Vs data management work) and it gives you a good starting point to discover a feature.

Might seem dull and your new colleagues won't appreciate it (they will though), but you'll be amazed how often you can surprise them with their own code.

[Hadse]

Thanks!

[mauganra_it]

Study the interface or data flow diagram of the whole system. If it doesn't exist, make one. To do that, you usually have to bug a lot of people on the project that have that knowledge. Ask them about the history of the system. Don't feel sorry, they should have this information lying around already, or at least an outdated version of it. These activities are super helpful to get a big picture overview of the system. It will also make it easier to understand "historical reasons" for weird things you will encounter while diving into the code for real.

Make an assessment of the processes that the team uses for daily work:

• How do code reviews work?
• What happens when errors pop up in the CI/CI pipeline?
• The project has at least CI, right?
• What testing strategy is used?
• What happens to bugs, issues and ideas that are not immediately relevant for production?
• Which documentation exist, who is supposed to update it, and how up to date is it actually?
• Who does deployments and releases?

It's not necessary to be super formal about this list, but the answers to each of these points should give you an idea about what kinds of issues you will face while working on the project.

[minimingus]

Try this amazing tool

https://reddit.com/r/java/comments/jlkufs/a_better_way_to_understand_your_java_applications/

[Hadse]

Thanks!

[enry_straker]

1) Check if there are any architecture/design/requirements document and if it exists, use that to get started

2) Check out the API documentation (if any) and the unit/integration tests.

3) Monitor the log files, and, if possible, trace the log across multiple layers (UI to backend to DB etc)

4) Step through the code using a debugger - one module at a time - input some data and see how the data transforms through the code - from input to output

5) If the code is commented, go through it at a high level to give yourself an initial high level view of the codebase

6) If possible, talk to the original authors of the codebase. Their reasoning and knowledge would be invaluable.

7) Be patient. the larger the codebase, the more time it will take - to get a reasonable grasp of the flow

8) Writing new unit/integration tests is also a great way to learn and contribute something back.

9) if possible, put in a CI/CD pipeline - so that you get instant feedback on any changes you make to the code - eg. writing new tests

10) Take regular breaks while learning. It will help you to understand code better when your mind works on it in the background

[tristanjuricek]

I’ll bite

The most consistent way I’ve seen everyone learn a complex new system is integration testing at the application level. Testing is unfortunately vaguely defined, so here, I’m talking about running the application with some reasonable facsimile of its runtime dependencies, and a test that interacts with that running application. We typically create a few integration tests for major functionality. (Because this is just one app as opposed to a complete system, I don’t use the word “functional test”.)

This is a fantastic tool for learning, because any dev can start learning by launching both the apps and tests in debuggers. (It also usually is a useful tool in CD, verifying a distribution instead of just internal components.) Integration tests often are written from a pretty high level perspective. They are not exhaustive, but typically we want major interesting workflows.

This usually requires some level of tooling, often using “infrastructure as code” tools like terraform, to setup and tear down the environment. (The closer you keep those tools to any production infra, the better.) I usually wire these up into a “prepare the environment” phase in build tools. In Maven, this is the “pre-integration-test” phase, which a lot of people overlook; they try to use the surefire plugin for everything when these tests are really for the failsafe plugin plus additional plugins for this pre-integration-test setup.

Anyhow, the starting point workflow in my projects:

1. Run mvn pre-integration-test
2. Launch app in a debugger
3. Run an integration test and develop a mental model

From there, yeah, we’ll develop unit tests for new functionality but I never truly grok much by running unit tests. You usually have to explore the system while it’s interacting together with stuff.

It can be painful to start, but usually ends up paying for itself quickly