Throughout my time writing codes, it's always a solo project. It's always the professor providing us with a doc of how our code should work. My only interaction with other people's code is when I try to help a classmate figure out a problem that they're currently facing.
This week I had the opportunity to write on someone's else repository.
This week we are tasked to update our partner's repository to implement a function that allows us to convert a markdown file (.md) to a .html. We are told to choose a feature that we want to add.
I didn't have much issue in terms of understanding my partner's code, for they are quite organized in terms of the structure of their files and directories. Also, the comments that they have are quite helpful in allowing me to understand how it all works.
The Process
I first started by looking through the "ssg.js" to figure out where the process of "input" occurs, and work from there.
I re-wrote his file.js to now consider a markdown file, and removed his static regex value of /\.txt$/ to now instead be refer to path.extname of a path string that passes through the condition.
For the folder section, I used an if statement to prevent non-valid files from occurring, but my partner suggested that using a regex allows for a much cleaner code '/**/*.{txt,md}'. Aside from that, everything functions similarly to how I handle file.
I was planning on adding a condition at the ssg.js to compensate for the if statement that I had prior, but considering that all of it can be simply scrap by using a regex, I had to remove it.
Now that I am able to convert a .md to an .html. I now have to check where my partner does all the writing from, and I found it at the textParser.js.
Within the file I noticed that he uses "type" and "content" key as some sort of a way to convert to the dom. I traced where he was doing this from and saw it at the dom.js files that he has.
Within it I noticed that he was only using a ternary operation when creating an element for the dom. To ensure that it allows for multiple options, I had to remove and replace it with a variable that goes through an if statement; it checks what type is given and gives the element corresponding to it.
After doing so, I go back to the previous file and create an if statement that removes the "#" from a line and pushes the type that will be used in the if statement within the dom.js. Now the program is finished.
Learning Experience
What I learned from this is that it takes a bit of time to figure out how the code works. Moving backwards one step at a time ensures that I'm able to figure out how the entire process is done, even if I never written the code.
To ensure that there's not problem for next time, I'll keep a level headed mindset, and ask my partner for the stuff he wrote to ensure I don't waste time.
Merge Pulling Request
What I expected from my partner when adding components, is to simply add what is specified within the doc. However, base on the feedback I got from my professor and partner, it seems my code has been unorganized, and uses wrong naming conventions, and overall structure of my directories.
I understand where they are coming from by changing the structure of my code so I had no problems with it. I'll use this as a way to make my code much better for the future.
Top comments (0)