2020 past

# 1

You should try and avoid merging the feature branch so close to the sprint end, as you run into the issue of not knowing whether or not your code works together.
Instead you should try and merge into the development branch sooner.

You should avoid having so many manual tests during development as they are expensive in terms of time, you should try and implement more automated tests especially when implementing features in isolation.

I don't think it is correct for all development to stop to merge tasks, I think this is a symptom of an issue described above and that merges should be done early and often to avoid having one large effort to merge everything at the end of the sprint when you aren't even sure if it will work. To fix this the team as a whole should commit to frequent and early merges into the development branch.

If some code is not working it should not just be commented out, large swathes of commented out code should not even exist in the code base as in the future whoever looks at that code will not know what is happening. You should just keep the broken code on a different branch and scrub it off of the development branch so when it is time to work on the broken story in the following sprint it is already in some othe rbranch waiting.

I think it is a flaw also that they are manually testing after the merge as if they had automated tests you would know with far less effort whether or not the merge was successful. Manual tests should only be testing stuff that is hard to test, ie. flaky user flows not the entirety of the code. To remedy this I think that they as a team need to change the culture around testing by implementing TDD or some test driven style of development.

# 2

# 2.1

There are two types of backlogs, sprint backlog and the product backlog. The main difference between these two is that the product backlog contains all of the user stories for the product, while the sprint backlog is scoped to be within a sprint and takes stories from the product backlog, stories that fail in a sprint is taken back into the product backlog to complete in a subsequent sprint.

# 2.2

The goals of a retrospective is to have a clear understanding of what went wrong, what could be done better, and what went good in the past sprint. The expected output of a retrospective is to have a set of actionable tasks that you can take into the following sprints, these tasks are to address anything that went wrong, could have been better, or something to keep doing as it was working well. The output of the retrospective should be documented somewhere every team member is able to have access to it, so that it can be seen as a reminder during the sprints and discussed in any following sprints.

# 3

# 3.1

? Is this even LCM

0 case: (a=0, b=0) => 0
1 case: (a=1, b=1) => 1
blue sky: (a=2, b=3) => 6
negative case: (a=-2, b=3) => 6

# 3.2

Code looks good so far. Though I would a method doc quickly explaining the purpose of the function.
Also it needs to handle the case where one of the numbers is negative, ie. a=-1 or b=1.
Can you also look at a different way to handle the double for loop on line 11, as double loops will end up very slow once you start putting in some slightly larger numbers.
Also the title of the function seems to not be doing what it says? I have not heard of "longestCommonMultiple" before, the code seems to be returning the lowest common multiple? Though I could be wrong here.

# 4

Code review is not only to check code to make sure that it is correct, but also for knowledge sharing, which is helpful to avoid silos where only one person understands some portion of the code.
The delivery of feedback is as important as the feedback itself as software developers are still people and can feel emotion when someone is giving feedback in a demeaning/negative/condescending tone, this is not at all professional behaviour and can hurt collaboration and trust within a team.

# 5

# 5.1

## AbstractFactory to create the different RVC types..

AbstractFactory: RVCFactory
ConcreteFactory1: DomesticRVCFactory
ConcreteFactory2: CommercialRVCFactory
ConcreteFactory3: IndustrialRVCFactory
AbstractProduct: RVC
ConcreteProduct1: DomesticRVC
ConcreteProduct2: CommercialRVC
ConcreteProduct3: IndustrialRVC

## T

BaseRVC {
emailReport(); // this gets overridden on the subclass
}

## Builder - for accessories

Builder to actually construct them depending on whether a large capacity bag is fitted or not.

## Observer for Coordinating RVCs

# 6

# 7

A large class smell is when some class is becoming too large that it is hurting maintainability and readability. It would be easiest to identify by the classes that have a lot of complexity, ie. interacts with lots of other components. Classes that needlessly interact with other components is the best indicator for a large class smell.

# 8

# 8.1

The common goal between persona and user profile is to identify the users of the software and what concessions we need to make to accomodate them.

# 8.2

Coming to a stand-up unprepared shows a lack of commitment to the team and product, as well as a lack respect for their team members time and efforts.

# 8.3

Information hiding is when you make certain members private and provide access to those members via. a function that you defined. It is important as you limit the access to private members you reduce readability as the scope of who can access these members is lessened and only provide access to those via. the way that you want them to access it ie. defined in the accessor method.

# 8.4

A sprint interference chart is a chart showing the amount of time spent on non-sprint backlog tasks ie. not directly contributing to the sprints goal, and it is used to monitor the amount of time spent on non sprint backlog tasks.

# 8.5

Smoke tests are last minute checks ran before deployment just to make sure the surface level is up and running, this doesn't test anything complex just that the app is actually running and not crashed.

# 9

# 9.1

The contract of a method comprise of it's pre-conditions, post-conditions, and invariants. Contracts can either be expressed in the code if it is supported or documented in the method doc of the method if it is not. The original contract should still be upheld by the inheritors, but they are allowed to loosen the pre-conditions and tighten the invariants and postconditions

# 9.2

MP3Player:
Precondition: A media source is available and an album has been selected
Postcondition: Plays all tracks on the album in order

PayPerPlay:
Precondition: A media source is available and an album has been selected and a coin has been inserted
Postcondition: Plays all tracks on the album in order until the album is finished or 20 minutes have elapsed

ShufflePlayer:
precondition: The media source is available
postcondition: plays all tracks on the album in order until the album is finished and then plays all other albums by the same artist.

# 9.3

The system makes good use of contracts to ensure the system doesn't fall into some error state, ie. making sure that it is valid to play music before playing.

It could be improved by using some interface `MusicOutput` which contains a `play()` method, the various music outputs can then abide by this `MusicOutput` interface to ensure that any future music output that gets added will also use this interface, so that the context calling play on the music just needs to know that it has to use the `play()` method of whatever music output it is using at the moment.