I'm still new to software development, and I find it difficult to follow code that is split across many functions and modules. For example, I might see `const result = await createOrder(data);` and then jump to another file to find out what `createOrder()` does, only to discover that it calls several more functions elsewhere. I understand the benefits of separation of concerns, reusable functions, and small modules, but sometimes I feel that related logic would be easier to understand if it were kept closer together. Is navigating between files just something that becomes easier with experience? How do experienced developers decide when to follow a function call and when to treat it as a black box? Can professional code be over-abstracted?
3 Answers
There is definitely such a thing as too much abstraction. Splitting code is useful when a function represents a meaningful concept, is reused, has a clear responsibility, or hides complicated details. It becomes frustrating when simple logic is scattered across many one-line wrappers that merely call another function with the same arguments. Code that is well organized should make the high-level flow readable, even if the implementation details live elsewhere.
Yes, this is a normal part of working in a real codebase, and you get faster at it with practice. Modern editors make it much less painful: use Go to Definition, Find All References, and the navigate-back shortcut so you can jump into a function and return to your original location easily. It also helps to keep several related files open or use bookmarks and split views.
I'm using VS Code and just discovered that Ctrl-click or F12 jumps to the definition. The back shortcut makes it much easier to explore.
When exploring unfamiliar code, start at an entry point and follow the data through the relevant path instead of trying to understand the entire project at once. Read from the high-level flow toward lower-level details, and write down notes about what each important function accepts, returns, and changes. Experienced developers still jump around constantly, but they usually do it selectively: they investigate only the pieces that matter for the bug or feature they are working on.
It also helps to ask whether you need to know how a function works or only what it guarantees. That question prevents a lot of unnecessary digging.
A useful warning sign is needing to open five or six files just to understand one simple operation. That may indicate poor factoring rather than a lack of experience.