Sprint 6 Retrospective

For the last sprint of the semester, I spent most of my time working on my part for our groups final presentation. There was one minor bug fix that I made involving an incorrect mapping for one of the product endpoints found from a user reported issue, but otherwise the rest of my time was spent on the presentation. This bug in particular could have easily been avoided if the project contained tests for each of the endpoints maybe by using a mock database. If, for example, we had a test that tested what would be an expected successful response, then the test would have failed for the given endpoint because it gave a 404 not found response instead.

For the presentation, since my task was separate from the main project for the food pantry, my section felt like it was a short, stand-alone presentation contained in a longer one. Looking back on what I did for the project, I definitely feel like it wasn’t too complicated and if I needed to do something similar now it wouldn’t take me nearly as long.

That being said, I think there are several major things that I should take away from this project. First of all, although the resources that I followed through were helpful in its creation, I wish that I had started from the ground up to understand how everything actually worked. It’s very easy to get something to do what you want from making minor changes to resources you’ve already found, but being able to actually understand how everything is working together and also being able to explain it well are much harder and take time. Another big takeaway is to make sure to have good tests and to make sure everything is still working properly by running through those tests after making any changes. The fact that the bug with the typo in one of the get mappings exists is proof that I hadn’t properly tested the code to make sure that everything was still working as intended when I pushed my code and created a pull request. I was very fortunate to have run into this issue at the end of the project because if I hadn’t then I might have gone on to make the same mistake in the future.

If anyone happens to work on the project in the future, the first thing they should definitely do is implement the automated semantic versioning that I neglected to do myself. It’ll save them a lot of headache if they make any changes because they won’t have to remember to update the version in multiple locations. Without a doubt, when I saw that issue, it was clear that it was poorly designed. There’s no reason for the current version of the project to be hard coded in multiple locations. Actually, when I pushed the changes for the endpoint bug fix, I ended up forgetting to update the version number and the pull request had already been merged, so definitely fix that first.

Link to project GitHub repository:
https://github.com/LibreFoodPantry/FoodKeeper-API

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s