Lab 1 in OSD600 open source class focused on reviewing and testing the Static Site Generator Github repository of another student. My partner for this in refining my code was Gustavo Tavares whom I have known for coming up on 2 years now at Seneca. I was confident in his ability to help me simplify my code and test for bugs.
First, I tested his code which was a fun experience. One of my favorite things about code reviewing is seeing how others approach the same problem that I do but in a different way. A surprise I did not expect was that originally he did not use "fs" module to read the files, and instead used the built in "Yargs" library functions. However, this presented some issues with the naming of the files after generating HTML https://github.com/GMOTGIT/GMOT-SSG/issues/1. The filename was: "filename.txt.html". Furthermore, there were some unused variables and code that I requested be deleted. https://github.com/GMOTGIT/GMOT-SSG/issues/3
When it came to reviewing my own code, Gustavo found a few more "crucial" issues which included my "output" option being coded incorrectly. It was attempting to generate a folder, rather than output to an existing folder on the system which is what the requirement specifies. Another issue was that I needed a check in place to see if the file or folder actually existed on the system and print an error if it doesn't. I had the "throw error" statement but changed it to a console log which is easier to read.
https://github.com/AndreWillomitzer/textToHTML_V2/issues/1
One issue that was raised that I think is not an issue is the tool taking only 1 file or folder at the same time. The requirements and examples show 1 of each, not multiples. So this is more of a feature improvement request than a bug and did not get fixed.
In the end I was able to fix all of my issues which was nice. There are now checks in place for files that don't exist, and my output option can use another folder besides default "./dist". I'm sure there are more issues I haven't found but for this lab I fixed all the ones Gustavo and I found.
What I learned through this process is that there are multiple ways to achieve the same result. It's nice having a second set of eyes to review your code and refactor it to make it better. Sometimes a reviewer will spot something you didn't see because you wrote the code so it seems like it should work properly and makes sense to you. It was also useful testing someone else' code because it gave me an idea of some things I should test in my own code that didn't occur to me.
Top comments (0)