How to deal with huge sources?

Question

Programming

Tell me how to understand which part is responsible for what in large projects consisting of hundreds of files, such as the Linux kernel. Personally, I'm confused in this ocean of code, and I can't imagine how such giants are supported. How to add new functionality and look for bugs?

Answer 1

In programming, there is such a thing as modularity - large systems are divided into modules, each of which is responsible for its part of the work - the linux kernel, graphics subsystem, drivers. If we take the Linux kernel, then there are many modules - drivers for equipment - video cards, sound cards, etc. at the lowest level, a subsystem for multiplexing I/O (select/poll/epoll), etc. Each developer is engaged in his task, his module in the Linux kernel. For example, if you write in Node.js, you can start wondering what's inside. And find the chain that leads to the Linux kernel (simplified): Node.js -> libuv -> epoll and then understand how this system call works at the kernel level and start studying the Linux kernel source code for this system call.

Answer 2

No way.
If we are talking about commercial projects, where 10 generations of developers have changed, then everything is done by random, with caution. If the project does not imply modularity or OOP, then this is an asshole.
Digging through such piles of code is the most disgusting part of the profession. No experience, no practical use. The programmer acts as a kind of janitor, digging into the shit.

Answer 3

- How to eat an elephant?
- Piece by piece. And with ketchup.

Answer 4

it is necessary to disassemble the logic of the project with the developer of this project. Otherwise, it will be difficult, it is easier to raise a topic from scratch than to poke around.

Answer 5

Profiling and drawing up the entire architectural scheme of the project (or part of it).