Chapter 2 Methodology

2.1 Make a code review to verify that the developer tasks are well done.

  • Build and run the code to make sure everything is working well
  • Set some internal coding rules (We can use google or linux kernel coding rules as reference).
  1. For the form: linter (coding style)
  2. Should we initialize at the beginning of function or in the body of the function?
  3. Do we systematically check Api return type? How is Api return type computed?

Verify that coding rules and good practices (jean-philippe Aumasson secure coding practices for example) are respected.

2.2 Trace order of usage of code coverage and analysis tools

Kcov/sonar – Asan – checkmarx we should run code coverage tools first to make sure we have huge/acceptable coverage percentage before using analysis tools. If not, we are just analysing a part of the code

2.3 Check the output board of the analysis tools and the CI chain and report if there is something to be done

2.4 Suggest and revise API and library structure

Start with Jérôme and Ravindra suggestions

2.5 Make sure perf test, constant-time test, test on different platforms are done monthly rather than after tag for release (we can tag monthly)

2.6 Define (or contribute to) API versioning

current version 2.9

2.7 sensible but will impact CI

Note what we deliver to clients and what are their requirement (past, present and future clients)