Earlier quoted context omitted.
[deleted]
I can assure you netbeans will change and then not be your No. 1 java ide.
[deleted]
On navigating a large codebase
21–30 of 139 posts
Re: On navigating a large codebase
#22And then you try navigating an Akka Framework based source with their ask pattern. No way to navigate where the control flow would go with inheritance in the mix.
Re: On navigating a large codebase
#23This is a great article, I can relate. I specialise in replacing large parts of codebases with code that does the same thing from a business point of view but that makes future changes cheaper to make. One thing I thing that is worth mentioning is the political aspect of this sort of work. The people in power need to be comfortable with the fact that you will be introducing risk without immediate reward. That is a tough sell to someone who is used to putting out fires and writing root cause analysis reports to management. Sometimes this can’t be done and you have to hide your refactor in real business change work. This is not fun because it usually makes it look like you’re a slow dev.
In addition, most developers are fiercely defensive of their code and you need to be aware of that when you chose to replace it. A trick I find useful is publicly declaring, in your team meeting, how useful you found x members tests in covering your refactor. Or their comments or documentation or domain knowledge. When you are picking their brains for implementation specifics try to sympathise with them when you see a bit of hacky or confusing code. Say “I’ve had to do something like that before because of xyz”. It will save face and you will get more out of the developer. Never criticise, they will know what they have done wrong without you telling them. Just, be nice.
If you are looking for devs that can do this sort of work effectively then get them to read code in an interview and explain what it does to you. They can even offer suggestions and you get to see how they deliver criticism. Not complex algorithmic code but simple vast swaths of business junk.
Re: On navigating a large codebase
#24I navigate codebases by cat'ing all the files together (prefixed with filename) and piping it into vim.
I was shocked how much I learn by this seemingly-horrible technique. For example, the python files that actually get deployed are often quite different from the ones in source control. For tensorflow, at least.
I regularly read 1M+ lines of code this way. Not an exaggeration; vim scales, nothing else does.
Re: On navigating a large codebase
#25Are there any visual "code flow" interpreters? Something that would separate the 1000s of interactions between functions and show flow lines between them?
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.
Re: On navigating a large codebase
#26Are there any visual "code flow" interpreters? Something that would separate the 1000s of interactions between functions and show flow lines between them?
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…
There is no use viewing the whole graph at large. But “zooming” into and seeing the connections going to and from a node is really useful and not at all “magical”. As it is mentioned in the sibling post, sourcetrail can do it really well.
Re: On navigating a large codebase
#27Best Diapers for Crawling Babies | Top 10 Baby Diaper Brands
https://frenzyhome.com/best-diapers-for-crawling-babies/
Re: On navigating a large codebase
#28Just 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.
Re: On navigating a large codebase
#29It’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 IDE allows you to perform the same thing as well. Many text editors also have a pretty good indexing which will show matches on hovering the mouse. Never good enough to blindly trust, but usually faster and does a good job as 'quick win' for the first attempt.
Re: On navigating a large codebase
#30It’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…
Or better still, you should be able to integrate a decent search tool into your editor.
I'd take ag or rg over the built-in ones I've seen and being able to use them alone or in vim (or in a script) is a huge benefit.