# Software Engineering Notes

## Agile

This article is really cool: https://www.niceideas.ch/roller2/badtrash/entry/agile-software-development-lessons-learned

This video is also super helpful summary of agile process:

This video is a good explanation of what a Minimum Viable Product (MVP) is and how to (and not to!) deliver it:

In the above video it helpfully explains that one should think of the MVP as the Easliest Testable Product, the idea being to get the customer testing and most implortantly providing feedback as early as possible. Thus, the MVP is the smallest thing the team can think of that will get the customer testing things and giving feedback.

TODO

http://www.agileadvice.com/2015/04/15/referenceinformation/summary-of-user-stories-the-three-cs-and-invest/

## Ready To Start / Correct Completion

• Does it have clear acceptance criteria?
• Is the work item specific/small enough - can it be broken down further
• Is the work item independent? If not identify criticla path.
• Is it testable?
• Have test cases been defined?

### Definition Of Done

Answers the question "What does done mean?". In other words, how do we know when a task or story is absolutely complete?

• Think about what you've done - why? is there a better way? how could it be improved?
• Have you run a spell checked over it?
• As const as possible?
• Scope as small as possible?
• Array bound checking?
• Assumptions - Ass/u/me
• Has all trailing whitespace been removed?
• Are all function commented - decr, parms, return, pre, post etc?
• Are all structures/classes data members commented?
• Is code S.O.L.I.D?
• Tests:
• Have unit tests been written and passed?
• At a minimum, does each public API have a test that exercises all input parameters and tests for appropriate output regardless of how "simple" the interface may appear?
• Acceptance tests?
• Functional tests?
• Non-Functional requirements met?
• Have all acceptance criteria been met?
• Has product owner accepted?
• Have coverage statistics been generated? E.g. using gprof?
• Has a linter such as FlexLint or CPPCheck been run over the code where appropriate?
• Has Vera++ been run over the code where appropriate?
• Have we completed CI tests for the new feature? Are they passing?
• Has code been peer reviewed by at least on other engineer?
• For Linux: Has coding style script been run over code?
• For Linux: Has SMASH been run over code?
• Has code been merged back to trunk?

### Functional v.s. Non-Functional v.s. Acceptance

To paraphrase the SO thread Difference between acceptance test and functional test?, functional testing is verification, i.e. does it work correctly - did we build it right? Acceptance testing is a validation activity. Did we build the right thing?

Functional: Did we build it right? Verification: Did we build the right thing?

To paraphrase the SO thread What is the difference between functional and non functional requirement?: A functional requirement describes what a software system should do, while non-functional requirements place constraints on how the system will do so..

## S.O.L.I.D

### Intro

These design priciples help make software more understandable, flexible and maintainable: they tell us how to arrange the components of our programs.

1. Single Responsibility Principle (SRP)
2. Open/Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion (DI)

### Single Responsibility (SRP)

Rob martin, in his book "Clean Architecture" says:

A module should be responsible to one, and only one, actor .

For example, if a module register is used by a student and teacher, then it is responsible to more than one actor.

Such modules may suffer from,

1. Accidental dependency:

This can occur when common code is shared by two actors. If the code is change because one actor needs some feature, it may break it for the other actor.

2. Merges:

Two or more developers make changes to the code on behalf of separate actors and the requirements either clash or modify the same code in subtly different ways.

The solution is to always separate code that supports different actors. To accomplish this, use the facade pattern. In our example, the classroom object would be a facade for two objects, one which implements the functionality required by a student and the other impementing the functionality required by a tracher.

### Open/Closed Principle (OCP)

A software artificat should be open for extension but closed for modification.

Why? We want to be be able to upgrade or otherwise extend our project but without having to incur the risk of changing whats there already and presumably already mature and tested!

## Code Quality

Spell check comments: CSpell (requires NodeJS) or SCS Spell (requires Python 2 or 3) or https://github.com/louis-langholtz/pyspellcode.git.

Remove trailing white space: sed -i 's/[[:space:]]*\$//' <filename>.

Coding style: KWStyle.

Static code analysers!

Spell checker:

aspell check --mode ccpp <filename>

Mutation tesing?

https://github.com/mull-project/mull
https://github.com/nlohmann/mutate_cpp

Quickly reformat your source code: https://sourceforge.net/projects/uncrustify/

## Good Review Items

• What went well?
• What didn't go so well?
• Did we enjoy it?
• Did we learn anything?
• Internal processes.
• Improvements?
• Missing?

## Versioning and Change Logs

https://keepachangelog.com/

https://semver.org/