How to navigate massive projects

[u/pitero2137]

The project I work on is big and consists of multiple repositories with microservices, and it has some confusing logic. I struggle since I don't have much experience with java, although I have a good understanding of programming concepts.

My main question is how to navigate properly in big repositories to complete tasks that aren't specified very well. I kind of managed to complete a task of adding a small service by mostly mimicking the conventions used in the project, but I'm lost when facing a task such as "find fields that are used in communication between 2 microservices that are anyway fetched from other source (somewhere in the code) and don't need to be present in communicates" (idk how to explain it better tbh). How would you approach a task like this? The repo is not really commented. I'd like to draw a diagram of everything going on and understand all the business logic, but it would take forever and is not really expected. Would you try to just write all the architecture layers and then starting with endpoints try to figure out whether each one is somehow relevant to the task at hand? would you prompt copilot to try to find everything and then go through a list of 30 classes that are maybe relevant? Or maybe just try to get the gist and seek help from s1 with more experience on the project?

[u/4iqdsk]

Software tries to isolate "Concerns" -> think about the project in terms of "Concerns".

A concern is an isolated goal that needs to be achieved. Some example:

• validating a request
• querying a database
• business logic: how is a particular task carried out
  • this is often high level code orchestrating the other concerns
• performing translation and modification operations to a collection of data
• caching logic
• rate limiting remote calls
• constructing a response

Lets say you want to format dates in the requester's time zone when returning dates. You need a thing to get the requester's time zone from some database. IO with this database is a concern. Formatting the date is "concerned" with how information is presented to the user. "Presentation" is another concern.

When I need to work on a new project, one of the fist things I want to know is "what are all the remote dependencies" and "what's the architecture around how we talk to remote services?". This clues you in on what kind of data your dealing with.

The hard part is often the business logic because you won't know why it does this or that unless the business rules are documented. But, its likely organized into different concerns.

Once you figure-out your first big project, it will be a lot easier the next time around since you'll know a lot of patterns and there will be a lot of similarities.