Lets get into this
I have been there and if you are not a newbie, you have probably been there but if you haven't been there, don't worry you will be there. There will always be a time in your life when you inherit code that was written by another developer. If the developer is smarter than you, that's a problem and if they are not, well that's a huge problem. This is a problem most developers face when they start a new job at a different company.
How did we get here?
Recently I was given a task to maintain a project that was written by another developer using a programming language that I am not familiar with. This article has some few things that helped me get up to speed with this new project as well as explaining these ways in case you encounter the same problem.
You have been given a project written by another Developer. What should you do?
We don't run away from the code, we run the code
Study the programming language used
The first thing you have to do before trying to add functionality to a project written by someone else is to understand the programming language that was used to write the project. Most people say programming languages are the same, learn one and you are good with all of them. I disagree, programming languages are different in terms of syntax but they use the same concepts like , OOP, if statements exception handling etc. Take your time to understand the syntax of the language before you try changing some lines of code in a project and this will save you a lot of time. This applies to all programming languages, Python, JavaScript, PHP, C# etc.
Study the source code
Once you get an understanding of the programming language, take your time to read through the project code. Go through the code as much as you can if possible from line 1 to line n, file 1 to file n. Going through the code thoroughly will help you understand the way the developer structures their code, their commenting style, strength and weaknesses. This will also help you know where to edit when you want to edit any features of the project.
Experiment with the project
Experiment with the project, make a backup then break it and fix it. If you break the project you will suffer, the suffering is necessary because it will help you understand the concepts and technologies used in the project when you are trying to fix the project. This will also help you to understand several modules of the project and their connection.
NB: There are several ways that can help one to get started with a project that was written by another developer but this is what worked for me.
Top comments (14)
Very helpful. I just completed my first month of my internship... I struggled with tasks at first because I tried to solve what I did not quite understand... Until I decided to learn the language then tackle the task. It's been better ever since I used this approach
Exactly bro
Thank you, im glad the approach is working well for you. All the best on your internship.
Using and/or adding automated tests is the most productive thing you can do. If there are no tests yet (an unfortunately common case) adding the first might be an expensive initial investment but generally proves out to be the best possible use of time.
Also, rather than reading the code as text, interact with it using a debugger. Configuring a debugger in your IDE isn't pleasant but usually not too hard if the src runs on your local system. (It can get painful if running remotely or in a Docker container but even so worth a try, look for articles.)
I always start from tests and putting breakpoints in random places and see how i can hit them :)
Nice. It's weird but setting up an IDE's debugger seems to have exceptionally high mental activation energy. Am guilty myself--didn't touch it for years. And when my wife started learning to code, she wasn't shy about telling me where to shove my debugger. :) For non-html projects, I've noticed too that only a small portion of even fairly senior coders set it up.
Additionally, I would advise to run the test suites if there are any in the project. And run them often, especially when you are messing around with the code when you are getting familiar with it.
And remember to take your time. You don't have to comprehend the whole codebase at once. Learn it bit by bit.
I've just inherited a Symfony 2 project where 3 dev worked on it before me. It is a monolithic project with absolute no concern about architecture, I have 1Ok+ repository class that does all sort of things, even sending emails. The average function is 500 lines. I have no choice but to work upon this spaghetti code base because I'm hired to add features to the website (to respond to business needs) and not do any architecture or cleaning. I assure you the task is very hard, you can't test anything at all, you investigate code that simply can't run, with no code style at all and a database with messy data that sounds very corrupted to me. Have you a good psychologist to recommend ? ^^ Have you encountered this kind of situation ? What would you do / react to ?
As a mentor I used to suggest the same methods for junior devs, so they can easily catch up with other developers code structures, ways of thinking, human logic behind everything and the number of cups of coffees they drank while doing these codes :) Seriously this is like #1 of a Jr. Developer 101 list. Unfrotunately lot of people do not get this, especially when they are not motivated for knowledge and self-improvement but propelled by 'getting tons of money'... Keep it up, these writings helps junior devs to start thinking like pros :)
I was doing that for the last 3-4 months of my internship. The difficult part is that I have 3 projects to support and I'm jumping between them.
Of course they were written by the different people with different JS stacks :D
Sound advice. I’d love to see, or maybe I’ll write, a post of how to make it so that your project is easy to get started with for another developer
Good idea, you should write about that
I am interested in coming up with a standard practice of understanding someone’s code. I came across a very short article and would like to get feedback from others.
Well said