Lecture 1#

This class is focusing on the following topics:

• Service architecture
• REST API
• Docker (Oh hey I make this site using a docker container!)
• Testing
• Domain specific
  • Secuirty
  • Distribuited systems
• Evolution of software
• Maitenenece

Assignments for the class#

We also went over the assignments and the major project for the class, this looks like it should be interesting!

Theres also a midterm and a final worth a fair chuck of the grade so I’m expecting this to be a busy semester! One thing I do wonder though is, with the idea of 3+ players does my prof mean multiplayer or like, game ai kinda thing?

Clean code#

It wouldn’t be a software engineering class without talking about clean code. We went over it kinda fast as it was covered in the pre-req for this class but the jist of it is as follows:

1. Readable
2. Simple and consise
3. Consistent
4. Well ogranized

We rely heavily on the SRP[single resplonsibility principle] principle to guide how we design classes and functions.

Good to keep in mind#

We want to make sure if statements say what they are trying to do for instance:

if (age > 20 && age < 30) {
  // Do stuff here
}

Should be turned into a bool instead to make the code more readable:

bool isYoungAdult = age > 20 && age < 30;
if (isYoungAdult) {
  // Do stuff here
}

This way it makes the code easier to understand at a glance

Lecture 2#

We want to avoid over engineering our code, like making un-needed abstractions or generalization.

We also need to handle errors gracefully, like using try catch blocks to avoid software crashing. Ideally in case something does break you’d also want to make sure the program cleans itself up nicely before exiting.

Test driven development#

Red, green, refactor

We want to start by writing unit tests that fails (red), then write the code so it passes (green), finally as we code more if we need to change the code we can do so (refactor).

Code review#

Code review is important as it lets us maintain quality on larger scale projects. But how does it work?

• Unit tests (can find 25% of quality issues)
• Function tests (can find 10% of issues) [Total issues found so far is 35%]
• Intigration tests (another 10%)
• Design and code review (15%) [For a grand total of 60% of the quality issues]

Basically it’s a part of a greater whole to ensure quality!

What is it?#

The process of examining code to find bugs, ensure coding standards, improve quality, and share knowladge.

The tools#

Pull / merge requests, depending on github or gitlab, are the main tools behind code review. Most review is done in either one of 3 ways:

• Online reviw using something like teams
• In person review in an informal setting
• Inspections, in a formal setting often with a checklist

Best practice for code review#

We want to limit our pull / merge requests to less then 400 lines of code. Ideally the smaller the better!

We also want to limit the time we look at code for review, no more then 60 - 90 min.

We want to define why we are doing the review:

• Readability
• Bugs
• Coding standards

We need to choose multiple reviewers, more eyes are better! But there is a limit, research (my prof didn’t site this sadly) says that after 4 people look at a review the effectiveness takes a nose dive.

What if you see an error outside of the review#

Unless its specific to the code you dont want to stop the review for it, but you should make a note of it or fix it yourself.

int eight = 9;

// changes start here
completely unrelated to above code

In this case we would not stop the review as the bug is not related to the review, however…

int calculateValue(int tax, int cartValue) {
  // all the code here got deleted but it didn't touch the line above
}

You would mention something as this directly is affected.

Final thoughts#

Overall most of the first lecture was review, but starting into how code review works was interesting! Im looking forward to seeing where we go next!