Live data from Hacker News

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

news.ycombinator.com

1–10 of 90 posts

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

#3
It's going to take time, for large code bases you won't actually look at all the code.

Make sure you're able to efficiently navigate through the code. If your IDE supports jumping to declarations and usages, make sure you get working.

Look at old commits to see how changes were added before, that will hint at how future changes should look.

Ask others for help if something doesn't make sense.

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

#4
What you need, more than anything, is the mental model the authors used when writing it. In a company you want to sit down with the people who wrote it. If it's open source you'll have to do the same if the API is undocumented. Otherwise it's something like unbaking a cake. I've done it myself by first figuring out the dependency tree of the modules, then trying to get a high-level idea of the purpose of each component. From there, it should become easier. If the code is written with any sense at all it will get lower-level and less abstract as you work your way down to the function calls.

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

#7
This is an incredibly broad question, and the answers will probably be all over the place. If you are working on the front end, try to find the entry points and work from there through various hypothetical scenarios. Hopefully there is documentation on various parts of the system, or architects/devs who built it, but that is unfortunately not always the case…

Find out the deployment process. Find out what to do if anything goes really, really wrong. Try to find patterns in the code. Just explore for a while and even try to create you own mental model of how things are structured.

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

#8
A codebase has a time dimension, and utilizing this effectively is critical.

Not sure when a bug was introduced? Write a test then bisect (if you can't automatically bisect frontend code you have other problems, but manual bisects work in a pinch).

Not sure why something was written the way it was? Hey sometimes this stuff just evolves naturally, try looking back through blame history to see how different commits effected the code.

Not sure what needs touching to add a new feature? Try seeing if you can find a similar feature that someone else wrote in the past.

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

#10
To find the frontend code associated with a feature, search the view code for text that you see in the app.

To see how it uses the backend, open the network tab in Chrome developer tools (or equiv in other browsers), look at what requests it makes, and then find corresponding controllers within the code.

Post reply on HN