How did I go about finding someone to work with?
I sent a message in the OSD600 Slack channel looking for a partner to work with. I found my partner in Alexander Samaniego who had created his application using Node.js.
What was it like testing and reviewing someone else's code?
In reviewing my partner's code, there was an initial issue with understanding the code, since I was not all that familiar applications written in Node.js. However, after reading the code it was fairly straightforward to understand. There were some Node modules that I did not have an entirely clear understanding of at first, but after looking into what the functionality of the modules were, it was not all that complex.
One problem that came up immediately was that I did not know how to use an application developed with Node.js. However, when I figured it out, the necessity of having to figure it became apparent as something missing in the instructions of the application. Finding different ways to run the application was also an issue since I wanted my testing to be extensive. The list of scenarios to test for the SSG application helped, but was not extensive enough to test every viable scenario.
Issues that I filed
1. This issue arose right from the start, since I had not known that npm install -g would need to be executed in the command line first before the application could be used. I figured that other people would also encounter such a problem.
2. This issue came from the initial testing that I did for all the options. According to the spec, both --version and -v had to have the same functionality, and the same went for --help and -h. Since --input/-i and --output/-i had already worked the same way, the same should be the case for --version/-v and --help/-h.
3. Similar to the previous issue, this one also came from initial testing. According to the specs for this release, the -v/--version had to output the name of the application as well as the version, which the application was missing.
4. This issue came from reviewing the source code for the application. I had noticed that one of the parameters for a function was unused, which is a very basic issue. However, it also exposed the problem that outputted files were named from the first line of the text file rather than the original file's name.
5. This issue came from more extensive testing. By using the -i option without inputting a file name to target would create an output directory without creating any files. This seemed unintuitive and I thought an error message or something of the like should be displayed whenever this behaviour occurs.
What was it like having someone test and review my code?
It was interesting having another person testing and reviewing my code, since typically my work would only be reviewed by myself. I was surprised that there were so many issues in my code. One issue that came up immediately was that the runtime library that I was using when compiling my code did not work on my partner's computer. I had to search for a solution for the issue and fortunately it was a simple change that fixed the problem
Issues that were filed for my repo
1. This was an issue that I knew was present in my code but I had yet to find a solution for. At the time of writing, it has been solved using an else if condition instead of an else.
2. This issue I had not thought of, since in many cases command-line applications can be executed from any location. However, without changing PATH variables (which may be too advanced for some users), this issue will remain present. So, I will have to do with simply placing a step in the instructions to execute the application directly through the command-line.
3. This issue was found to be intentional. It remains in place because it prevents .html files to be created out of sub-directory files in the initially inputted directory.
4. This issue was a little more difficult to solve without increasing the coupling of my Text module and main function. I had to resort to placing the open and closing HTML tags as a constant variable in the Text module's header file in order to reduce code repetition.
5. This issue was the similar to issue #5 that I posted on my partner's repo. Since I used a different programming language to code my application than my partner, I had to find my own solution to this issue. The fix itself was straightforward using the filesystem standard library's functions.
Was I able to fix all my issues?
I was able to fix all my issues. I had the most trouble fixing issue #4 without further increasing coupling between my main method and the Text module. Issue #3 was not an issue at all, since it was placed there intentionally with a purpose. The fixes did not take all that much thinking, but spotting the issues required another set of eyes. Through this experience, I saw the value having another person look my code.
What did I learn through the process?
I learned that there will always be issues that are present in the first versions of an application. Even though I may not see them as the author of the application, others may be able to spot these issues more easily or may have standards that I am not aware of. This is also a benefit of making an open source application, except instead of one person reviewing the code, many people could review it.
Top comments (0)