Live data from Hacker News

Ask HN: Working with large code base for the first time

news.ycombinator.com

81–90 of 90 posts

Re: Ask HN: Working with large code base for the first time

#81
post #77

Earlier quoted context omitted.

Realistically, i agree with your point and it's probably a good course of action! > Ask, ask, ask. Yes, you can spend days or weeks poring over the code in various ways, but asking those who made it (ideally) or those who maintain it will give you the "why". My question, however, is why aren't these things documented in the first place? In DevTernity (a recent software development conference), the concept of ADRs ( h…

In my experience, many things are documented, but the documentation is unhelpful, redundant or outdated. Sometimes there are several documents on the same thing, some are outdated in different ways, or the author has given up on it. In code itself, often you see comments that say one thing, the function name saying another, and the relationship doing something different. It's probably good company culture for seniors…

> In my experience, many things are documented, but the documentation is unhelpful, redundant or outdated. Sometimes there are several documents on the same thing, some are outdated in different ways, or the author has given up on it.

> In code itself, often you see comments that say one thing, the function name saying another, and the relationship doing something different.

Is that not a red flag in of itself? Because it seems like at some point someone cared enough to write the docs, but eventually no one cared much to maintain them.

To me, that just expresses that later either the other developers or even that same dev cared only about keeping things running, which was the standard of quality that they chose for themselves, as opposed to actually caring about the long term sustainability and therefore the docs.

I've seen situations like that as well, but generally when everything surrounding the projects is also bad - improper risk management, old dependencies possibly with insecure code, unaddressed technical debt and either god objects or overly long functions with outdated names/docs all go hand in hand.

Personally, i don't take it as "just the way things are" but rather something to be addressed head on - in the past year, i've written everything from onboarding guides to initialization scripts and tooling for around 5-10 projects and have kept them up to date.

Furthermore, i've definitely sent back merge/pull requests on the basis that they need further refinement due to the aforementioned concerns. Not nitpicky stuff that's irrelevant, but rather things that would make the codebase lie to someone reading it, in one way or another.

Of course, one can argue that docs are useless in of themselves because they're not what's actually running on the servers, but personally i disagree with that point of view as well, though perhaps that's a conversation for another day.

Re: Ask HN: Working with large code base for the first time

#82
post #64
post #52

Earlier quoted context omitted.

Tangential wish - I'd love it if someone figured out a good/generally working way of jumping to definition/references through a URL. E.g. from `axios.get(`/users/${currentUserId}`) in frontend code jump to `class UserSingleView: def get(self, user_id):` in the backend, and vice versa.

As someone who has worked for years on a UI consuming such information: it's bloody difficult. Each language has its own weirdnesses, you almost always have to build the code to figure out the cross references, and what's correct to the compiler is often non-intuitive to the user. Prime example: C++ code mixing macros and templates. There isn't even a good definition of what the definition is!

I probably do underestimate its difficulty, but certainly appreciate it's bloody difficult. Hence I'd love someone else to do it! I don't have the appetite for it, but it would be fantastic to use.

Re: Ask HN: Working with large code base for the first time

#83
post #63

- Definitely use an IDE like IntelliJ - Familiarizing yourself with vim is great and one of the best timesaving skills I decided to pick up randomly. You can install vim plugins for most IDEs - Pick a small feature that you are curious how it works, and focus entirely on how it was implemented. The simpler the better really. Use git history to see the commit that the feature was introduced, and look how that engineer…

vi-style editing is fast only if one can touch-type. If not, it is not faster. Its plus is the consistency of keybindings across platforms, but even then on international keyboard layouts it is not ideal (or just bad) and requires a lot of customization which may be highly non-trivial in vim modes for various IDEs. So if one already uses vim, then sure vim-mode in IDE is nice to have, but if not, I suggest not to bot…

Not gonna lie, it really blew my mind when I was onboarding junior engineers that not every engineer knows how to touch-type. Frankly, I had never even heard of the terminology "touch-type" until that moment, and basically thought that if you can't do this (in most cases) you never learned to type. Not trying to be rude in any way, any idea how common this is? Maybe more common internationally than in the US?

Re: Ask HN: Working with large code base for the first time

#84

I'm a firm believer that the onus should be on the current development team to explain this to you. That is unlikely IME to happen without you asking. What happens next will be an iterative process. Do some initial investigation - don't waste time figuring things out, we just want a set of questions and areas to explain at this stage. Ask for some help from the team - perhaps 30-60 mins, perhaps with different people…

And when someone teaches you a sequence of commands that are ~always run together, consider writing a script. Check the script into the repo. Now you have executable documentation.

(Obviously within reason: maybe `npm install && npm run start` doesn’t need to be in a script, but maybe two or three commands that print out some token which needs to be copied into the next steps would benefit).

Depending on the nature of the script, maybe even write a test. Now you have machine checked documentation.

Re: Ask HN: Working with large code base for the first time

#85
post #76
post #16

- Search for unique-looking strings from whatever view you're trying to modify to find the associated html/js file. - Pull up the commit history for the file to see what other files were modified along with it the last few times. This will give you dependencies and linkages. - Make your change and then ask your ide/command line to find all typing/lint errors in your project which will help you find other dependencies…

Thanks, didn't realize that you could pull commit history for a file.

Git blame is also super helpful when reading individual files, as it gives you a line by line commit history.

I recently used it in a major re factor of a file (I didn't write) as it gave me background info (commit messages) on why the code ended up looking like that.

Re: Ask HN: Working with large code base for the first time

#86
post #29
post #26

If the project you are working on has enough time to burn, and the codebase has no (or near to) unit tests, add them. Find large utilities that are not coupled with a particular part of the application, and put them under heavy testing. Do not fix any failing test before having completed the test suite. If you have access to other developers that know the codebase, review the tests with them, and fix failing tests to…

How are you supposed to write tests for code if you don't understand what it does/is supposed to do?

First of all you’re not going to be all by yourself. Ask previous developers or peers if there are any. Ask them to help you navigate the codebase and find good candidates.

On the opposite scenario, where you have to take ownership of a large codebase and there’s no one around that can guide you through it, if every time you learn something about it you turn it into a test case you will do your future self a favor and at the same time also tracing your progress.

Re: Ask HN: Working with large code base for the first time

#87

1. Get confortable using “grep” [1], or better, “ripgrep” [2], which is quite faster than the former. They are both available in Linux, macOS, and Windows via WSL. 2. If the project uses a version control system (Git, Mercurial, Subversion, etc.) then take a look at the most recent additions, modifications, and/or deletions in the version control log (git-log, or whatever you want to call it). Sometimes, the most rel…

> Get confortable using “grep” [1], or better, “ripgrep” [2]

And as part of getting comfortable, the -A and -C options are particularly useful.

Re: Ask HN: Working with large code base for the first time

#88

1. Get confortable using “grep” [1], or better, “ripgrep” [2], which is quite faster than the former. They are both available in Linux, macOS, and Windows via WSL. 2. If the project uses a version control system (Git, Mercurial, Subversion, etc.) then take a look at the most recent additions, modifications, and/or deletions in the version control log (git-log, or whatever you want to call it). Sometimes, the most rel…

2 and 3 are great points, but honestly - and especially if you're working in multiple repos, or multiple subdirectories in a monorepo - VS code's folder search is better than grep. It'll find you the exact place in the file, and a click will take you there, nice and easy. I've more or less forgotten the quirks/flags of grep, because I haven't needed to use it in a while.

What if I told you VS code search is ripgrep? Pretty much every coding focused editor has built-in ability to view grep results, then click on the result to jump to the file location. It's 1980's UI technology.

Re: Ask HN: Working with large code base for the first time

#90
post #77

Earlier quoted context omitted.

Realistically, i agree with your point and it's probably a good course of action! > Ask, ask, ask. Yes, you can spend days or weeks poring over the code in various ways, but asking those who made it (ideally) or those who maintain it will give you the "why". My question, however, is why aren't these things documented in the first place? In DevTernity (a recent software development conference), the concept of ADRs ( h…

In my experience, many things are documented, but the documentation is unhelpful, redundant or outdated. Sometimes there are several documents on the same thing, some are outdated in different ways, or the author has given up on it. In code itself, often you see comments that say one thing, the function name saying another, and the relationship doing something different. It's probably good company culture for seniors…

A neat trick is to have the new person update the docs whenever they needed to ask a question.

Writing docs falls in the realm of error handling and testing. Lots of developers only want to deal with the happy path not those extra drags. Standard CS education isn't helping here.

Post reply on HN