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

61–70 of 139 posts

Re: On navigating a large codebase

#61

Post by RoyalSloth »

ramino wrote: post #34

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 m…

I think that the only thing that really works are code reviews. The best engineers on the team should have enough time to review what is being committed and provide suggestions for improvement. Things will start gradually improving, but it usually takes a very long time before you see any progress.

Like someone already mentioned in this thread before, an important part of this transformation is to not forget about the political aspects of such cleanup process. People don't like to hear criticism, so you will probably encounter a lot of pushback in the beginning.

Re: On navigating a large codebase

#62

Post by baby »

magicalhippo wrote: post #57

This is one of the big reasons I prefer static typing. When looking at some unfamiliar code in an unfamiliar codebase, I can reason about the code much faster when I can see what functions return, and quickly go check their types out if the type is unknown. This makes me much more productive. I helped maintain a 250kLOC Python program. I came in when it already at over 200kLOC. I spent so much time , every time, just…

That’s really painful indeed when you review python/erlang/etc. code or Golang with interface{}

Re: On navigating a large codebase

#63

Post by spinningslate »

sydd wrote: post #32
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 comme…

my priority for comments is that they should answer "why?" and "why not?" questions. Why does the method/function do it this way? Why didn't it choose that other, perhaps more obvious route?

That's not necessary in every case. But it's true in a good number of them. The code alone can never tell you that - but it's often invaluable during evolution/refactoring.

Re: On navigating a large codebase

#64

Post by scollet »

sydd wrote: post #32
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 comme…

I'm really grateful for my current team because of this.

It takes 5 minutes to have thoughtful naming and "this is why because..."

They have done a stellar job at that.

Re: On navigating a large codebase

#65

Post by astura »

gambiting wrote: post #42
mtzet wrote: post #16

The advice about using both grep /and/ the IDE is very good. Often they are framed as in opposition to each other, but in reality they're just tools. IDE's are great when they work, but it's entirely possible to make it confused. I keep hearing to get better IDE's, especially from Java developers who seem to have nicer IDE's than us C++ schmucks, but even the best IDE will not save you when your program is really an…

Speaking of IDEs - I work in video games development, huge codebase that's over a decade old, heavily templated C++ code - I've switched off the IDE "suggestions" long time ago, visual studio is just wrong about incorrect/missing code like 90% of the time. Just hit compile and read the errors, I have files that VS shows as nearly entirely wrong, squiggly lines everywhere, and yet they compile and link fine. And the o…

Yeah, visual studio is absolute and complete garbage with C++ code, it always identifies correct code as having errors, and it's not just a "big project" thing, it happens in very small projects, even "projects" that have a single file. I really don't get it... I also don't understand why intellisense doesn't update itself with the results from the compiler.

Re: On navigating a large codebase

#66

Post by barbarbar »

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.

That raises an interesting question. Are there any such rewrites that have succeeded? I have mainly heard that it is either failures or not done.

Re: On navigating a large codebase

#67

Post by fraculus »

sillysaurusx wrote: post #45
Gehinnn wrote: post #41

Earlier quoted context omitted.

If you read/scan 10 lines a second, you still need over 24 hours non-stop to read a 1M+ code base. I doubt a random file ordering is helpful! Especially if you lose code navigation features like "go to definition".

You'd be surprised. Suppose I want to "go to definition" for a class named Saver. /^class Saver\> 19 times out of 20, this works. It's also instant; my vim will likely get me there faster than your IDE's go to definition functionality. (Looking at you, pycharm!) Here's my flow. >>> import tensorflow as tf >>> tf.train.Saver >>> from tensorflow.python.training import saver >>> saver Then I open /usr/local/lib/python3.…

I agree that things like "Go To Definition" can be pretty bad (especially when a codebase has code that is auto-generated, but you haven't figured out how yet).

But I'm curious, what benefits do you see in your approach over just doing a grep in the folder (or e.g. Ctrl+Shift+F "Find in Files" in Pycharm)?

Re: On navigating a large codebase

#68

Post by Aeolun »

sydd wrote: post #32
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 comme…

> good code is self-documenting

I still believe this to be more or less true.

The important part there is that you have to write good code though.

Re: On navigating a large codebase

#69

Post by Aeolun »

stinos wrote: post #35
fphilipe wrote: post #33

Earlier quoted context omitted.

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?

It’s much easier to leave in some extra code because the compiler won’t complain.

Re: On navigating a large codebase

#70

Post by lordnacho »

Great article, my two cents:

- Areas vs perimeters: perimeters are linear, areas quadratic. This is why you really, really want tests. Tests will black box a component and test it from the perimeters, basically the external API. Only once something needs to be changed do you need someone who understands the insides of that component. But the testing is kept small, and the error domain is kept small, so that you might have different people fixing different components.

- AvP, part 2: people's brains can index a lot, eg you know where the tests are, you know what the components are called, but they can't map that much. Your engineers will know what line to change for the parts they've mapped, but they'll have to spend time if they only have an index to where it might be.

- AvP, part 3: documentation can mean a map or an index. Rewriting the implementation in prose is bound to go wrong. The version control method makes a lot of sense here, it connects locations to technical decisions.

- Visualising is to ensure you have held down the complexity. If the 2D box-and-line chart of your project is just a huge blob, you've done it wrong.

- You need to comment code, but try to keep it to one-liners. If you can't explain in one line what some snippet does, it's probably too clever. Also don't think that everyone will understand it just because you gave everything sensible names. Your code might be read by someone used to reading a different language. Or more importantly there's some domain specific reason why something needs to be done a certain way, and you don't want the next person to forget that.

Post reply on HN