- How did you go about finding someone to work with?
I have been collaborating with my partner since my first semester in Seneca.
- What was it like testing and reviewing someone else's code? Did you run into any problems? Did anything surprise you?
I think the most interesting for me to review someone’s work is that from the work I review I can always learn something new which includes a new language or even how the code is designed, and I think those new things could significantly broaden my horizon, essentially this is why I love collaborating with others in an open source project. The testing went quite smooth other than a few minor issues I found in my partner’s software, everything worked out. There is one thing that surprised me, it’s that the code volume for implementing this project in Python is way less than C++ because in C++ I have to manually parse file path but in Python there’s ready-to-use functions to do the same job which makes everything way much more convenient.
- What was it like having someone test and review your code? Were you surprised by anything?
Actually my code is not as good as I thought it would be although I preconceived myself that my code is robust and it should be functionally sound, however, quite surprising after Piotr tested my application, there were 5 issues in it, I wasn’t expected that to be honest, but I really appreciate that Piotr could generously point out the issues in my application to make my project more robust.
- What kind of issues came up in your the testing and review? Discuss a few of them in detail.
The first issue I found was that the program accept non txt file as input, which means not only the .txt file will be converted to html but also non txt file is converted, I think maybe Piotr needs to filter out those non txt file extensions and it wouldn’t be difficult to fix. (Mine also has the same issue).
Another issue was that the program does not accept full qualitied path(absolute path). Every time I pass a full qualified path, it will show me the file or directory doesn’t exist, I think that’s because the input path was concatenated based on the working directory(current path of the command line), so that the fully qualified path becomes part of the current working directory. I fix is actually quite simply, just don’t always concatenated path with current working directory.
Although it’s not required by the Wiki, I found there is one more thing should be improved to make it more making sense. In any scenario, when -h or —help shows up in the argument, other arguments should be discarded and only the help manual will be shown.
- Provide links to issues you filed, and discuss what you found
Issues · P-DR0ZD/pdrozd-ssg (github.com)
I found 2 issues and 3 minor things that need to be improved.
- Provide links to issues that were filed on your repo, and what they were about
Issues · liutng/SSGifier (github.com)
There are 2 functional issues(issue #3 and #4) and 3 useability issues(#5, #2 and #1).
- Were you able to fix all your issues? What was that like?
The fixing of all my issues was pretty straightforward, I fixed them up at the day Piotr submits it this is because of the fact I actually noticed the issues myself after I pushed my code to git repo, and also since it was me who finished this project entirely, I know what causes the problems and how to fix them.
For the file extension issue(#3 ) I found that it was actually caused by me being uncareful because this requirement is written in the wiki as the required function. But luckily it’s easy to fix where I just add a filter in the file scanning process.
For the folder clearing function issue(#4), I found this is also caused by my another uncarefulness, this is also part of the required functions, however, fixing it just takes a delete-function-call before the writing process.
Others issues are all related to my help description where I did not provide enough information to users.
- What did you learn through the process of doing the testing and reviewing?
I’ve actually learned a lot from my first ever project, first, I learned how inconvenient to use C++ to write program, and I may not consider to use C++ to implement high level programs. Also, I learned how to use GitHub and how do I actually collab with someone and asking the person who collab with to test my program for me. However, the most important thing I learned from this project is that I realized how important it is to track my issues, to make my bug-fixing more traceable and high efficiency I use Notion in conjunction with GitHub issues, when I see an issue coming in, I will just add it to the list of unfixed bug in my Notion and when I finished fixing it, I will drag it to the fixed catergory, so every time when I want to know where were I at after a break, I just take a glance at my Notion and I can go back to my work immediately.
Top comments (0)