105 How Do I Understand a Complex Codebase At Work?

I just started at a new company. How do I learn to work with their code? How do I get up to speed on the code I have to work on? What if it is complicated, spaghetti code with no code comments? How do I learn to support it? These are the questions we are going to answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:25

How do you understand the complex code base at work? Maybe you start a new job and you're just trying to figure out what all this code does? How does it work? What are these different modules? How are they bringing being brought into the code? How does it interact? How does it work at all? And this is very difficult because of the fact that you can't go to Google and say, how does my custom code at my employer work? Because it's not on Google. So let's talk this through in today's episode of DevQuestions. Now, this question was asked on a suggestion site. And if you have questions that you'd like to see answered on a future episode of DevQuestions, go to suggestions.imtimcorey.com and ask your question there. So let's talk about integrating into a new code base, understanding it, learning it, figure out what it does and how to start working on it. Now, I think there's three initial steps that you need to go through. Now the first one is read the documentation. If there's documentation, read it through. Try to understand what it's talking about, figure out what parts are useful, because maybe not all documentation is useful, but try and figure out what's useful to you and understand it as best you can. Number two, talk to the existing users. What I recommend doing is every time you're not sure, go ask a senior developer, but take with you a notepad. Write down what they say. Try to make sure they understand that you're not going to just use them as your Google, that you are trying to learn once from them on each topic. Because usually people don't have a problem with you learning from them. They want to make sure you're up to speed, they want to help you. Where the frustration comes in is when you keep coming back with the same question. So if you take notes, if you write it down, if you document what you have learned, so you can go back to the document instead of to them, that will definitely increase your ability to use them as a resource because they'll see that you are wanting to learn and grow. And the number three place to look is unit tests. Look for unit tests in the project and see if they exist. And if they do, what do they test? Because those tests will tell you how specific methods are supposed to work. So you'll see what the inputs and outputs should be based upon expectations, and then what they shouldn't be based upon what the rules are testing to make sure doesn't happen. Now, it's at this point that you're probably thinking, Tim, I have zero for three. There is nobody in the previous position, there is no documentation, and I have, of course, no unit tests. So what do I do? Because none of these exist, and this is not an uncommon situation. Maybe it's a little bit uncommon to walk into a code base with no previous developers, but it does happen. But a lot of times there is no documentation, there are no unit tests. So at that point, you're reliant entirely on the people that came before, and maybe they're grumpy and don't want to talk to you. So now you're still over three when it comes to learning this new code. So what do you do? Well, I have four self-discovery tips that I hope will help you. So the first one is make sure that you have a development environment first. Don't do this in production. Okay. But make sure you have a development environment. If you don't, talk to your boss and say, listen, I'm new. I'm trying to learn, I'm gonna mess things up. You don't want that in production, right? So help me help you. So let's set up something where I can test things without breaking real things. So get some type of development environment set up, hopefully on your machine or something local, where you can break it and not affect others. And then practice. Try things out, see what happens when you make changes. Just try it and see if things work or they don't work and why they work or don't work. So that's number one, get a practice environment and then practice. Number two, step through the code. If you're not familiar with how to do this, use breakpoints. So wherever you want to try to figure out what the flow is for something, start at the very put a breakpoint at the very beginning where you think it starts, and then execute that step and see if the code breaks. And if it doesn't, you know that you have a bad assumption about where even the code started. But then once you get the right spot, you put the breakpoint, step through the code. Go step by step by step. Yes, it can be a long process, but understanding what each step does, inspect the variables, inspect how things change, and take notes and track down what's going on with this code. How is this flow through the application? What are the things it looks through? How does it evaluate and understand how this code works? So stepping through the code will really help you because that's the at the end of the day, that's what your code is doing at a much faster pace. So if you understand that flow, then you'll understand what your code is doing. So that's number two. Number one is practice in a development environment. Number two is step through the code using breakpoints and other tools to help you understand that flow of the code. Number three, write unit tests. If you don't have any unit tests, start writing them. Not just because you need to have unit tests. Not because you think that you know test-driven development is the only way to go and you must have them. Don't be obstinate about this. But instead, use unit tests as your learning process. Create little tests and have them test a specific method for inputs and outputs. Make sure that the method does what you expect it to do by creating a unit test that tries it out. And then if it doesn't do what's expected, figure out why and if it's the unit test that's wrong or if it's the code that's wrong. But start writing these unit tests to start practicing your understanding of the code. This will do two things. One, it will help get you used to the code. But two, it will also create a system that'll make it easier to make changes to the code because when you change code that's under unit tests, the unit tests that we're working may break. And if they do, you realize that the changes you made have fundamentally changed how the methods work, which is probably not what was intended. So by having these unit tests in place, you're more likely to be able to change things with less fear. So it really helps you in a couple of different ways to create unit tests. So that's number three. And number four is document everything you learn. Even if you had documentation to begin with, even if you had coworkers that were willing to help you out, even if you had existing unit tests, still document what you learn. Either way, it will be helpful for you, and it will be helpful for the next person. Maybe they had documentation, but it's kind of out of date, which happens. Improve it. Make changes. Make sure that you put the latest information in your documentation and share it with everybody. Then if someone reads over and says, I don't think that's how it's supposed to be, then you can grow together. Either they can say, Oh no, you're right, and they can understand better, or they can help you with an assumption that you had that was incorrect. So even if you don't have anybody there to help you, there are steps you can take to learn and grow in a code base to better understand it. Now I know that some of this is gonna seem like it's unattainable because of how long it might take. You might say, Tim, I just don't have the time to do that when I'm trying to get up to speed and fix problems. But you can do some of this while you're doing that. When you go to fix a problem, write a unit test for it. When you are trying to track something down, document what you learn trying to track it down. So there's things you can do along the way that will help your overall goal of understanding the system better and helping others, including the person that comes behind you. Because at some point, you'll be the person that knows a lot about your code base, and they'll be the new person that doesn't understand and needs help. If you can give them this information, you can make it easier for them, and you can reduce the amount of work it takes to get them up to speed, which means you can reduce the amount of time it takes before you get help in your day-to-day job. So it's really a win-win-win all around for everyone involved. So those are the steps that I recommend for coming into a new code base, trying to learn it and understand it, and grow into it. I hope that was helpful. If you have a question, again, go to suggestions.com and post your suggestion there or upvote an existing suggestion, and hopefully you'll see your question answered here on DevQuestions in the future. Thanks for listening. As always, I am Tim Corey.

SPEAKER_01 10:20

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamtimCore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.