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
- 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?
- Are the requirements understood and linked to the tasks?
- Have tasks been estimated>
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
References
- Clean Architecture, Robert C. Martin,
- SOLID, GRASP, and Other Basic Principles of Object-Oriented Design, Muhammad Umair
- Wikipedia (of course!)
Intro
These design priciples help make software more understandable, flexible and maintainable: they tell us how to arrange the components of our programs.
- Single Responsibility Principle (SRP)
- Open/Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- 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,
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.
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
- MSC Generator. A tool that draws Message Sequence Charts or generic Graphs from textual descriptions.
- UMLet
- PlantText. Convert text for diagrams, from PlantUML
- ASCII Diagram GUI.... awesome!!
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/