Category Archives: Code Review

WSU x AMPATH || Sprint 3 Retrospective

Sams Ships (11)Hey guys! This sprint retrospective will cover what the WSU Coders Without Borders team has done from the week before spring break and up until this week.

As the project is propelling forward even more than before–due to us having more concrete plans to begin working on the project, it has been an exciting transition. We saw our options from Greg’s wireframes and explanations through his YouTube videos. From there, we created Zeplin accounts so we could visually understand and remember certain parts of the app in progress.

Since it was my first time using Zeplin, I wanted to add a little review of it. As someone who loves to organize things, I found that it is a great tool to have for sorting projects and handing off designs and style-guides to other users. It seems like an effective way to share ideas directly with people.

The overall WSU team now has a GitHub section for dividing up the components and issues we will be working on. So far, my team is going to tackle the search bar and everything else it would entail to create. It was nice being able to collaborate amongst one another to find a component that we agreed to work on (and the fact that a few other components had already been assigned to some teams helped our decision be made faster).

From there, we were figuring out what we need to do and how we can get things done. We discussed some potential ideas with Professor Wurst and from there continued to brainstorm for the search bar. There is nothing that comes to my mind that I would have chose to proceeded differently with if I could go back.

We are continuing our meetings as they have been scheduled and are actively participating in our stand-ups. I like being able to scroll through the log of my team’s answers because it shows our progression throughout the semester as well as serving as a reminder of when we did something specifically. I am happy to say that my team does not seem to have run into any issues or potential miscommunication among one another. It really shows how we are all working to achieve something together and effectively communicate what is happening.

In this sprint retrospective I also wanted to discuss how what we learned may be applied in other situations like in the workforce. We have to make sure we are checking in with teammates to have them understand the project more and be able to express their opinions and concerns when they arise. Similar to the bystander effect in psychology, if there is no direct communication between members when it comes to getting things done, how will there be any progression versus just observing what is happening? All it takes is being comfortable to ask different individuals if they have anything to share or add to the open conversation.

Overall, I am excited to move forward and see what is in store for me and my team during these weeks up until the end of the semester!

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Effective Code Reviews

Effective Code Reviews

On my way of finding a podcast for my first assignment, I passed by this podcast about Code Review. I decided to choose it for my first blog entry because it had some interesting opinions about code reviews. By listening to this, I learned about other benefits of code reviews, beside bugs detection and code improvement. Below was the link of the podcast:

In this podcast hosted by Michael Kennedy, Dougal Matthews shared his thoughts and experience about the benefits of code reviews and the elements effective code reviews should have. Dougal gave an interesting scenario that code reviews could save the day. For example, there were two persons, one knew more about C++, one knew more about Python. Even though they might not understand deeply what the other person is doing, they should have a code review with lighter level in case that one of them was ill or left the company. He also brought up one of the reason he thought that many people did not like doing code reviews. They expected bugs detection for their codes, but they usually received code improvement more than bugs for their valid codes. Michael and Dougal also had some interesting ideas for an effective code reviews.

To be honest, I haven’t thought that code reviews could be used as a tool to back-up basic information of a project like Dougal mentioned. Usually, the first thing that came to my mind when hearing code reviews would be bugs detection. But his scenario pointed out a special case, which some small groups might have, that code reviews could help fixing it.

About one of the reasons many people did not like doing code reviews, I understood their feelings when they just wanted to test if their codes had bugs or not, not to re-do the whole project again just because they received a better solution to solve their problems. But I thought that we should be more flexible about that. If we had another solution, which was better than our original one in one or many ways, then we should choose that solution. Beside improving the code, we also gained experience from it. The next time we countered something that was similar, we could jump directly to the better solution and reduce the time we might spend for the worse solutions that we had used before.

I thought that the code review checklist which was mentioned by Michael and Dougal would be very helpful. Like they said, it kept the reviewers and the developers on the same page. This certainly reduced the time everyone spending to ask around the same question about the progress. I also agreed with their idea about having more than one people doing code review for a same project. Different people had different points of view, and people might make mistakes. By having more people involved in the reviewing process, we could increase the quality of the review, and share our knowledge to each other.

From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.