# Grace Shopper Code Review #2 Notes

## Tier 1: MVP Shopping Experience

### As a customer/visitor, I want to be able to:
- [ ] access a deployed version of the website so I can browse and purchase products.
- [ ] view all available products so I can pick from a variety.
- [ ] view a single product so I can see more details.
- [ ] add a product to my cart so I can collect my desired products in one place.
- [ ] edit my cart if I change my mind:
- [ ] change the quantity of a product in my cart.
- [ ] remove a product in my cart.
- [ ] *No one else should be able to edit my cart except me.*
- [ ] "checkout" the items in my cart so I can purchase my desired goods.
- [ ] *Think of a typical user experience on popular websites from a guest user and logged-in user perspective.*
- [ ] *You can just start with by simulating the experience of checking out with a simple confirmation page.*
- [ ] create an account so I can have a logged-in experience.

### As a logged-in customer, I want to be able to:
- [ ] have a persistent cart so I can revisit and pick up where I left off.
- [ ] *Logged-in-user across multiple devices: I'm logged in on my mobile device and add some items to my cart. When I open the browser on my laptop and log in, I want to see those items in my cart.*
- [ ] *No one else should be able to edit my cart except me.*

### As an administrator, I want to be able to:
- [ ] have validated data to ensure reliability.
- *i.e. each customer that creates an account should only be able to do so once with a single email address.*
- [ ] have full rights to make backend requests to add, edit, and remove products.
- *No one else should have access.*
- [ ] view user information.
- *No one else should have access.*

### As an engineer, I want to:
- [ ] have a well-seeded database so that I am able to simulate a number of different scenarios for the user stories below.
- [ ] *By doing this, you really set yourselves up to tackle many of the points throughout the tiers. In the long run, this will save you, potentially, tons of time.*
- [ ] *For example, seed hundreds of products with dummy data so that when you get to the “pagination” user story, you won’t have to worry about adding more products.*
- [ ] *Likewise, add a bunch of users with products in their carts so editing the cart can be worked on without already having the “add to cart” functionality built out.*
- [ ] user data to be secure so that no one can unrightfully manipulate information.

## Set Up

If the fellow is leading the code review, the instructor can take notes on each of the presentations while also noting some parts of the code that they may want to revisit.

If the fellow isn't, then the instructor can do below and bow in and out of "employee mode" and "instructor mode" to discuss code

If the team is very behind, then skip the fellow led script and jump into code review and a discussion on how to get most of tier 1 done. This essentially becomes a long group office hour

## Fellow Led Script (30 minutes max)

This is to actually have a creative way for the team to present their deployed project and to discuss bugs, breakages, etc with the fellow leading it

**Pretend you're a new employee to their e-commerce company. The goal here is to get them to talk about their contributions to the project and what are some of the most important parts of the project as well as get them to practice technical communication.**

**Give each of them no more than 10 minutes to describe an important feature or their contributions to the project.
You can ask them questions during their presentation as if you were a new employee such as "Why did you choose to do [insert some feature here] this way?"**

**If you really want to turn up the heat on your teams, you can have them present on a part of their codebase they didn't really touch especially if you know they ended up splitting into backend and frontend teams.**

**After all that is done, you can go back into fellow/instructor mode and look through their code or go back to things you've noticed while cosplaying as an employee and address that.**

## Code Review

This follows the fellow-led portion where now the instructor can audit the technical implementation and code quality of the project based on the notes taken in the fellow-led portion

## Security

Refer to [security](https://hackmd.io/iZ6xcgB1QBWp9aZIxkjWZg#Security) section on the first code review notes to get a handle on this

## UX Considerations

- Make sure getting to certain features doesn't take any more than 2 clicks (2 click rule)
- Toast Notifications for things like:
- Adding something to the cart
- Signing in/signing up
- Have the badge of how many things are in the cart on top the cart icon
- Page loading notifications

## Task Board

This sometimes falls of the rails after the first few days of coding. Make sure they get back on track as this is important.

Make sure they are leveraging a Kanban Board (GitHub Projects) and they are turning their tickets/cards into issues and having assignees and linking the tickets to pull requests.

## GitHub Contributions && Team Dynamics

- Check if they are splitting up work into vertical slices
- Check if they each have their own footprint in the database. You can have them run `git shortlog -sne` to check their commits relative to their email
- Check if they are doing pair programming
- You can an extended scrum meeting to talk about their future plans

## Coding Conventions

- RESTful routing
- Coding conventions
- Semicolon consistency
- Naming conventions
- Mishmash of ES5 & ES6 syntax
- Design Patterns
- Routes should be "minified" and Models should be "stacked"
- Functionality should be in the form of a class or instance method to be called in the route
- Too many if statements are generally not good practice; very error prone
- Using an key-value pair/object
- [What the **** is Dynamic Dispatch](https://whatthefuck.is/dynamic-dispatch)
- [Stop Putting So Many If Statements in Your JavaScript](https://betterprogramming.pub/stop-putting-so-many-if-statements-in-your-javascript-3b65aaa4b86b)
- You can more specifically look at the section called "Lookup Maps"
- Not enough React components
- Separate it out into different files
- Redux store to make sure that they are using something like .filter to modify/delete stuff

## Stretch Goals

To simulate "last minute Product features" that may happen in industry, pick out at least one or two stretch goals from other tiers and have a discussion with the team on implementation.

### Ticket Writing

Based on the stretch goals, either the instructor or the fellow can lead ticket writing authoring related User Stories and Tasks