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

Definition Of Ready

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?

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

References

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!

Liskov Substitution Principle (LSP)

Interface Segration Principle (ISP)

Dependency Inversion

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/

UML/Diagraming Tools

Good Review Items

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