Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On navigating a large codebase

blog.royalsloth.eu

Post reply on HN
Print view View original

31–40 of 139 posts

Re: On navigating a large codebase

#31

Post by petepete »

RMPR wrote: post #8

> In 1980’s Tim Berners-Lee realized that the documents are hard to find at CERN, so he started imagining a system of interconnected documents that would supposedly solve this thorny problem for good. Nowadays we know this invention as the internet. > Despite 40 years of improvements and the internet becoming a part of our daily life, we still face the same problems. You can talk to another person half way across the…

To be honest, most normal people call the web the internet. It's the only bit most people see.

Re: On navigating a large codebase

#32

Post by sydd »

bluefirebrand wrote: post #3

This is a great article. I felt like it was describing a job I recently left, especially this piece: > It’s fine to have less experienced people working on a large system as long as they have the elders overseeing their work. In the world where senior titles are handed left and right, that is often not the case and it’s how you end up with a very fragile system that is suitable for a replacement as soon as it was bui…

> Code comments? Nah.

This is one of my biggest gripes. Someone (I think uncle bob) said that good code is self-documenting, which is bs in 95% of the cases. Yeah, you don't need to document the convertMinsToSecs() method, but most real life codebases are full with edge cases, shortcuts, temporary solutions, half-complete reorganizations. So people use this for writing no comments at all, whereas a few words of comments would save hours of investigative work for future developers working on the codebase.

Re: On navigating a large codebase

#33

Post by fphilipe »

stinos wrote: post #29

It’s worth spending some time learning the grep or similar CLI tools that can quickly find the files containing the relevant keywords you are looking for. Even though it is great advice, there is some sadness in the fact that it should even be advice. Apart from knowing how to enter code, the other most basic thing should be knowing how to lookup code? Nitpick: it shouldn't be a CLI tool, a proper text editor or even…

This is a skill I've noticed that many developers don't have, or don't have sufficiently. This lack manifests itself e.g. when I review a PR that removes feature XYZ. I do `rg xyz` and `fd xyz` to see if there's anything that was forgotten to be removed related to that feature. Very often there is.

Re: On navigating a large codebase

#34

Post by ramino »

The article describes pretty much what I’m facing at my job. We have a monolithic Ruby on Rails application with lines of code in the millions.

Still we general mantra is that comments are not allowed and I can only agree with the author that this makes non standard parts of the code extremely hard to comprehend. I would definitely love to work once on an application that size with a few comments here and there.

In my day to day work I depend a lot on our test suite. If I can’t even find the tests that cover this part of the code I just break the code on my branch and let the CI tell me which tests fail. There are probably better ways to do this with test coverage tools but this method seems fairly straight forward to me.

Documentation is something we started to do recently. I feel as long as the documentation is not directly connected with the code it is hard to keep it in sync. We even have PR templates that mention to update the documentation but the shape of the documentation is just too different from the code to have a straight forward Intuition at which point it needs to be updated. What happens for us is mostly that the feature owner at some point realizes that the documentation pages are not accurate at all anymore and rewrites them.

Sadly our commit messages are 50% of the time useless so that they serve more to know who to talk to than to understand why the change was done. PRs and commit messages are great documentation I wish we would use them more. In my company the idea is more that the change should be so small that no explanation is needed but I feel this idea misses the point that code can’t explain *why* something was done.

This is definitely an area for further improvements. Are there best practices someone could point me to?

Re: On navigating a large codebase

#35

Post by stinos »

fphilipe wrote: post #33
stinos wrote: post #29

It’s worth spending some time learning the grep or similar CLI tools that can quickly find the files containing the relevant keywords you are looking for. Even though it is great advice, there is some sadness in the fact that it should even be advice. Apart from knowing how to enter code, the other most basic thing should be knowing how to lookup code? Nitpick: it shouldn't be a CLI tool, a proper text editor or even…

This is a skill I've noticed that many developers don't have, or don't have sufficiently. This lack manifests itself e.g. when I review a PR that removes feature XYZ. I do `rg xyz` and `fd xyz` to see if there's anything that was forgotten to be removed related to that feature. Very often there is.

This is a skill I've noticed that many developers don't have, or don't have sufficiently

Yes, and I have trouble understanding how that is possible. Ok if you've never programmed and are just a beginner, but otherwise? Or does it depend on the kind of code? I assume this gets taught in programming / CS course, no? Or maybe not, and that is the problem?

Re: On navigating a large codebase

#36

Post by peterkos »

stinos wrote: post #29

It’s worth spending some time learning the grep or similar CLI tools that can quickly find the files containing the relevant keywords you are looking for. Even though it is great advice, there is some sadness in the fact that it should even be advice. Apart from knowing how to enter code, the other most basic thing should be knowing how to lookup code? Nitpick: it shouldn't be a CLI tool, a proper text editor or even…

I love keeping Sublime Text installed even for iOS work for just this reason -- no (smart) autocomplete and debugger make it hard to use day-to-day, but the raw speed at which it can navigate code is just awesome.

Re: On navigating a large codebase

#38

Post by aste-risk »

lstamour wrote: post #9
gdoptimizer wrote: post #6

Earlier quoted context omitted.

Sourcetrail?

Yep, Sourcetrail can do that, for the languages it supports. (It has an SDK so additional languages can be added, with effort.) Give it a method, another method, and it will draw a line from point A to B (with all the functions in between) using static analysis plus you can explore before and after to see what calls what. You can even see field usage though there it can be confused sometimes, understanding varies by…

Can you use sourcetrail on properitery codebases as well? I see it's GPL and according to my understanding, it's okay to use it on properitery software as long as you don't make any modifications to the sourcetrail software itself. Are there any hidden commercial licenses before I try it out on my company's codebase?

Re: On navigating a large codebase

#39

Post by m463 »

antpls wrote: post #25
m463 wrote: post #20

Earlier quoted context omitted.

I think this is a fantasy (that many of us have). "I run this magical tool, and voila! a satellite view of the code! It clearly shows this river runs into this bay, and there's a dam over there! Now I'm miles ahead of everyone! Lookie, this river runs in circles..." Ha. What really happens is you run some tool and what comes out looks and smells like hair you pulled out of your clogged drain. I've tried this. Anythin…

Maybe one could limit the graph to the happy path to begin with. The output of a run of profile-guided optimisation could be used to discover that graph, and only the touched functions would be drawn. This graph could be useful to start with the codebase, without being too overwhelming with all the edge cases.

I think this depends on what you're graphing. If it's an application, I think it has a better chance of working.

If it's something like a driver or something with a hal or tables of functions or callbacks it might be harder. If your codebase is large... hmm.

Last time I tried something like this was a decade ago so things might have gotten better.

Re: On navigating a large codebase

#40

Post by TameAntelope »

tluyben2 wrote: post #28
TameAntelope wrote: post #12

Just rewrite the dang thing! Planned obsolescence is so important for all of these reasons listed in this article. Know when its time to kill your services, and have a plan well in advance for how it'll go down, and what will take its place.

For very large codebases, this is often not an option. I know of very large 'let's write Cobol mainframe to Java' projects, burning 10s of millions of euros, that were just thrown away because they could not actually get it working in the end. And this is not limited to mainframe projects; it happens with (large) more recent projects (Java/C# mostly) as well.

For sure, it's not an option for these existing systems.

But when building a new system, design it and plan for it to be retired when certain criteria are met (e.g. when it hits 100 reqs/sec, 3 years from first release, when LOC hits 100k).

Post reply on HN