|
|
|
|
|
by Aperocky
1065 days ago
|
|
My opinion is manual navigation is O(log(N)) for well organized projects. Which scales very well - especially as the package should be optimized for local changes/split into dependencies when it gets above a certain size. For a project that's not organized at all, it's O(N) which means it will soon become untenable. Most project is somewhere in between but from what I've seen it tends towards the latter. As there are overwhelming amount of people utilizing the ease of IDE and do not care at all about the structure, or maintenance of the structure of a package. |
|
Unless you want to mindlessly click through directory structures and files hunting for vague hints, what are you going to do? Full text search? Unless you're both careful and lucky, you will find a lot or all of the call sites as well. Which, again, gets worse the larger the project (and thus the number of call sites) gets.
Then, you better remember the arguments' type, order, and significance of the many functions you call, otherwise it's back to the navigation I've described above every time you want to use it.
This was one of the more extreme examples, but the whole problem starts to rear its ugly head pretty early in much smaller projects. The issue is however somewhat masked if you are the only or one of very few developers with high familiarity of the project. Of course then you know which file to click on and where to scroll to.
But then, even on a small project, that project rarely exists in a vacuum (the OS kernel example above is actually almost somewhat of an exception). You will use other frameworks and libraries, at the very least the language's standard library, usually, which is effectively a big project again.