7 steps to contributing to code you didn't write
4 min read
1. Test it out
How does the software currently work? Especially around the area where you would like to fix or add to. It helps to get an idea of how it works or how its meant to work before diving in.
2. Adding or Removing Code? Try and understand whats going on technically first.
Try and understand the code before you change it - If you are looking for an implementation of a particular feature you want to add to or fix - Then ask yourself these questions
Where in the codebase is the functionality of the feature likely to be? Search the folders and check for hints, in VSCode hold down cmd/cltr (command for Mac, control for Windows) + the cursor, hover over a function or class you think might hold the code and it would take you to the original implementation.
What word or phrase in the frontend can I search for that would lead me to the implementation? If you have no idea where the code might be, this is a good place to start .... use grep/find if you are in a terminal to search for a word, phrase or potential files that might match what you would like to change.
# -n flag:- this helps output the line number where the match was found # -ir flag:- this says I want the match to be case insensitive and search for the match recursively # "Push notification":- the phrase i am looking for # . :- means the current directory grep -n -ir "Push notification" .
# find:- helps us look for files # .:- current working directory # -name flag:- This indicates we are searching for the name of a file # *.js:- Says we want to find all the files that end in .js find . -name "*.js"
BONUS using grep and find together
# The magic here is the | symbol. This feeds one command to another. # First find all files with filename ending with the extension .js then look for the work "Push notification" find . -name "*.js" | grep -n -ir "Push notification" .
Finally if you find what you are looking for and the implementation is similar, follow the convention the developers before you has already put in place. For example if there is an existing component that already has a style for a button you want to add to your feature import it and use it, don't try building yours from scratch. This applies always, unless you have a better idea of doing things of course.
3. Go ahead and start making your changes!
Don't be too worried you are going to break it. To put your mind at ease, make sure you aren't in the production branch - create a branch for development, or playground branch 😃 - be creative with it. Lastly, start small!
4. Don't judge
It might be tempting to want to rewrite everything from scratch, judging too early might cloud your approach to adding to the code
5. Read the documentation or comments if there are any
This part is important some developers might not be patient with you when asking questions about the codebase especially when it's well documented. But at least if you read it and you are still confused you can quote what you have read and then ask your question based on your confusion plus what has been documented.
6. Ask as many questions as possible
Asking the right questions can get you to the solution faster.
PS. Step 2 above is assuming there is no one to ask to point you to the right direction.
7. TEST, test, test
Make sure your changes didn't break other parts of the system
🥳 The End! Liked this guide, do me a HUGE favour and
- Share with your friends 👨💻👩💻
- React to the post 😍🥳👍
- Leave a comment if you have got other tips 💬