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

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

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 90 posts

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

#41

Post by gorgonzolachz »

guessmyname wrote: post #28

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.

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

#43

Post by wiz21c »

peterhunt wrote: post #6

Shadow a more experienced engineer and ask them lots of questions. One of my favorites is “how did you know to do that?”

That's the most relevant comment. Analyzing code by reading is probably the worse way to understand it. Using preprocessed information in the form of a human being* is much faster and less error prone...

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

#44

Post by akiselev »

gorgonzolachz wrote: post #41
guessmyname wrote: post #28

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.

VSCode uses ripgrep under the hood [1]

[1] https://github.com/microsoft/vscode-ripgrep

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

#45

Post by Areading314 »

guessmyname wrote: post #28

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…

myself am partial to silver searcher (brew install ag)

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

#46

Post by splittingTimes »

guessmyname wrote: post #28

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…

To get a sorted list of the most touched java files for example you can run

git log --name-status --pretty=format: | sed 's!.*/!!' | grep java | cut --fields=2- | sort | uniq --count | sort --numeric-sort --reverse

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

#47

Post by deergomoo »

What I find more useful than anything else is to find the entrypoint to the code you’re interested in, set a breakpoint on the first line, and step through with a debugger.

IMO it’s by far the fastest way to understand how an application bootstraps itself and produces its output.

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

#48

Post by splittingTimes »

Play with the application. In each of the main views try to find prominent/unique label strings. Search for those labels in the code base to get an entry point to the view. Then explore the code around that entry point and try to change something here and there and see if it has the effect you expected.

Other then that there is not much to that you would not do in other code bases as well. Set up your IDE probably do you have all the linters ready and can easily navigate the code base.

Ask your lead or mentor to show you the low prio backlog Tickets that have 1 or 2 story points and start the to get your feet wet. Once you have solve one, ask how your commit process works and follow it. Rinse and repeat three times then pick a ticket from the Sprint filter and start contributing.

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

#49

Post by echelon »

Areading314 wrote: post #45
guessmyname wrote: post #28

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…

myself am partial to silver searcher (brew install ag)

ripgrep is a faster and newer alternative with many ergonomic improvements.

The lineage is grep (C, 1973) -> ack (Perl, ~2006) -> ag (C, ~2011) -> rg (Rust, ~2016)

Ack inspired a wave of tool rewrites to accommodate better interfaces and usability.

Post reply on HN