Week 5 [Mon, Feb 10th] - Tutorial
The tutorial is held F2F from this week onwards. See the tutorials page for more info.
1 Discuss code quality problems of iP PRs
Find the PR you have been allocated to discuss (expand the panel below). If the allocated PR is not available or suitable, you can choose the fallback option, and failing that, any random PR.
10 minutes Find instances of the three code quality problems listed below: Go through the code in the diff view (i.e., the files changed tab), and find instances of following code quality problems (ignore other types of code quality problems)
a) weak SLAP
b) nesting problems: arrow-head style code or too-deep nesting (what's the difference?)
c) too-long methods- If you can't find at least one example, you can try the fallback option provided, and failing that, another random iP PR.
- You may select borderline and possibly problematic cases too.
Paste screenshots of problematic code in the
.pptxthe tutor will share with you via MSTeams.To identify nesting problems or long methods, zoom out and scroll through the entire PR code to do a visual inspection (no need to read the code line-by-line). After visually locating a method that looks too long/deep, have a closer look to see it can be improved by using better abstraction.
If existing PR comments are getting in your way, you can hide them using the following option:
You can use the following setting to try the two different views available and pick the one you like.
10 minutes Discussion: The tutor will lead a short discussion to go through the problematic code you found.
After the tutorial, you can apply the insights gained from this activity to improve the code quality of your own iP, if necessary.
You are not required to (but welcome to) post review comments in the PRs you examined.
2 User stories exercise
- Consider the following user stories a team came up with, for a tP that aims to build a software for tracking travel plans.
| 1 | As a … | I can … | So that I can … | notes |
|---|---|---|---|---|
| 2 | first-time user | see some sample trips when I open the app | easily try out its features without needing to add my data first | |
| 3 | first-time user | see a help message explaining which features I should try first | start by trying features that are more suited for new users | e.g., "hey you seem to be new. Try adding a trip first" |
| 4 | new user ready to adopt the app for my own use | purge all data | get rid of sample/dummy data and start adding my real data | |
| 5 | busy user | track all trip-related data inside the app | save time looking for data | |
| 6 | user | sending trip info to friends | via email or telegram | |
| 7 | user | add a trip | ||
| 8 | user | delete a trip | get rid of trip no longer needed to track | |
| 9 | user | edit trip details | correct mistakes I made when adding a trip | |
| 10 | user | view all trip details | recall details of trips | |
| 11 | user | see the next upcoming trip details when I open the app | save the step of searching for the trip | reason: the next upcoming trips is the most likely trip the user may want to see |
- Think of the answers to the following questions. These will be discussed during the tutorial.
- Which user stories don’t follow the correct format?
- Any of them too big for the tP planning? i.e., cannot be implemented by one person within 1-2 days
- Which are must-have features i.e., impossible to use the app without it
3 Prioritize tP user stories
- If you haven't done so already, brainstorm for user stories.
If you want to refine your user stories (based on what you learned from the tutorial activity above) that you brainstormed earlier, do that first.
If you haven't done so already, prioritize tP user stories as explained in the panel below.
4 time permitting Create a feature list for the MVP version
- If there is time left, do the following tP task that is scheduled for the following week.