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…
On navigating a large codebase
121–130 of 139 posts
Re: On navigating a large codebase
#122Well, that's a surprise for sure. I wrote this article a few months ago and it gained no traction. Today I woke up and boom, front page.
I really connected with the writing. Thank you for taking that time. There is a lot in my current context the writing resonates with. Nice to find that others have been on this path too, and that we benefit from a lot of the same techniques. Thanks for putting this out there as an invitation to draw people together.
Re: On navigating a large codebase
#123Earlier quoted context omitted.
> 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…
While I agree to some extent, the problem with comments is that they need to be maintained in order to be helpful: code comments - updated when the code changes, general comments - when the context changes, etc. This is a work in itself: developer has to remember to do it, reviewer has to remember to look for it. In my experience, people tend to forget to do it or just don't bother, which means that someone else find…
Someone updating the comments in code that they are updating because they see the comments right in front of them.
Or
Someone going to look through the documentation to see if there is anything relevant about the code they are working on that needs to be updated.
Re: On navigating a large codebase
#124I found cscope essential when working with a 10+M loc C codebase. I wish there were more cscope like tools for other languages, easy to setup and editor agnostic.
Re: On navigating a large codebase
#125Earlier quoted context omitted.
I'd much rather have a million lines of Java. And I'm not a huge fan of Java. It can be a bit tedious going down the AbstractWidgetInterfaceFactoryFactory rabbit holes, but at least I have a fighting chance.
To each his own...
Re: On navigating a large codebase
#126This 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…
250kLOC Python sounds scary. But that would easily be 1mLOC+ lines in Java ...
Re: On navigating a large codebase
#127I also agree that's it's complete macho crap about not needing comments. Hell I come back to something I was working on six months ago and don't remember what I was doing. Far better to have some comments telling me than spend time looking back over more code to figure out what this piece is supposed to be doing.
Re: On navigating a large codebase
#128This 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…
250kLOC Python sounds scary. But that would easily be 1mLOC+ lines in Java ...
Re: On navigating a large codebase
#129Earlier quoted context omitted.
While I agree to some extent, the problem with comments is that they need to be maintained in order to be helpful: code comments - updated when the code changes, general comments - when the context changes, etc. This is a work in itself: developer has to remember to do it, reviewer has to remember to look for it. In my experience, people tend to forget to do it or just don't bother, which means that someone else find…
Sure but which is more likely: Someone updating the comments in code that they are updating because they see the comments right in front of them. Or Someone going to look through the documentation to see if there is anything relevant about the code they are working on that needs to be updated.
Re: On navigating a large codebase
#130The article mentions the importance of comments and documentation inline in code. I tend to agree - well-written code is great and all, but a good comment can bring in context external to the code and make _why_ code is what it is more clear to future readers. And reviewers. Comments explaining _what_ code does largely aren't needed - that's evident from usage. But the _why_? Some people would say code which can't be…
Please, please comment code. Junior devs like myself will thank you senior devs for throwing us a bone.