Hi everyone! as the title say, I wanted to ask you what you do when you are facing a new codebase/legacy code to work to (besides looking at the docs).
The question arose because I want to get into the world of open source collaboration. I have forked and cloned several projects that have a lot of files, and many times no docs at all. So I get stuck in many small problems that have nothing to do with the project itself.
Thanks all, have a nice day!
Top comments (2)
Start small, if it's a large codebase it's probably going to take you a whole to get used to it, don't beat yourself up too much.
Find an issue and stick it out, the best way is to find an open issue and give it a crack, of there is already someone working on it, see if you can figure it out aswel, two heads are better than one. Also don't give up because your perception of the issue is that it is too hard, work at the problem, it will help you in the long run
Find the entry points, this is really important, learn where the entry points of the system, how people interact with the program is probably the most important detail
Read the tests, if there are any. This should give you a good overview of what is going on and hopefully why. If not then you can actively help by refactoring tests, this for me is very satisfying.
Write documentation, there is so much open source software out there with 0 docs and there is a reason, one no one likes writing tons of documentation and two if you've had your head in something for so long it gets really difficult to imagine life from outside the bubble you are in. This is why getting new people into the project is so important, if they are struggling to understand a concept that means other people will too. This is an opportunity to write better documentation
Debug, debug, debug. I wish I knew this earlier in my career but just step in and around the code, learn how it flows, where the deoendcies are, where they come from etc. Take your time to really understand why it's going down one oath and not the other.
That's all I have, sorry
I always imagine new code bases like new unexplored regions of a foreign land :)
One thing I've learned as a mountain trail runner is that you first need to know the cartography to make an educated guess on the direction you need to take to reach a particular goal.
Reaching the top of an elevated spot is usually the way to go first, then you'll worry about the right directions and the small details along the way until you reach your goal (like a large river or a bottomless ravine)
So it depends on the code base but I normally try to use an UML class graph generator to have a bird eye view of a code base.
That way, you'll get to really see some part of the logic flow and you'll be able to imagine the data flow as well.
Just like Mark said, debugging is also a great, if not the best, way to explore a code base; leave log trails around to see where the data/logic goes.