Retour audit Code Reckons

[jfalcou]

État des lieux du code sources et des artefacts afférents

Numération

Nombre total de fichiers total : 3084 Nombre total de fichiers efficaces : 2309

• Système de build
  • CMake : 158
  • Make : 119
  • M4 : 19
• Fichiers sources :
  • .hpp/.h : 1055
    • Code : 428
    • Tests : 609
    • Documentation : 18
  • .cpp/.c : 928
    • Code : 619
    • Tests : 270
    • Documentation : 39
  • Python : 16
    • Documentation : 4
    • Tests : 6
    • Code : 3
    • Build : 3
  • FORTRAN 77 : 4
  • FORTRAN 90 : 1
• Autres : 9

L'ensembles des fichiers sources représentes 237069 LOC de code effectif dont 77134 de commentaires soit un taux de commentaires in situ de 32.5%

La quantité de commentaire est bonne pour un projet de cette envergure.

Qualité du code

• Le langage principal est C++. La norme utilisée est C++17.

  Le niveau d'utilisation de C++ est très bon et de multiples idiomes modernes sont utilisés.

  • gestion de la mémoire par pointeur à sémantique riche
  • sémantique de transfert
  • méta-programmation pour l'aide à la génération de code

  Un élément central est le moteur de Expression Templates. C'est un élément complexe et fondamental mais dont la complexité est maîtrisé.

• MFRONT dépend des bibliothèques suivantes:

  • pthread
  • MKL
  • Boost 1.36 (?) pour boost::python, boost::numpy
  • Madnex (format EDF de stockage)
  • vera++
  • les éléments d'interfaçage python
  • les éléments d'interfaçage JAVA (JNI)

La quantité de dépendances est acceptable. La majorité d'entre elle sont optionnelles et ces options sont gérés de manière adéquat au niveau CMake.

Les dépendances gérant l'interaction avec python sont à réévaluées. De nouvelles bibliothèques d'interaction C++/Python plus flexible comme pybind11 où nanobind sont à explorer.

Qualité de la maintenance

• On note la présence de:

  • Un process de construction de la documentation.
  • Un système de build portable (CMake). Un support M4 et Make est aussi présent mais doit être éliminée.
  • On note l'utilisation de cppcheck comme analyseur statique/linter, potentiellement à automatiser via du CI.
  • Un jeu de tests conséquents. Ces tests sont néanmoins des tests d'intégration/validation plus que des tests unitaires. Ils faudrait essayer d'augmenter leur nombres et leur atomicité.
  • Il serait une bonne idée de faire fuzzing et, à terme, l'automatiser.

• Le déploiement, prise en main et vérification de la bibliothèque a un niveau acceptable d'automatisation

• Un effort est à entamer pour augmenter la quantité et la granularité des tests unitaires

• Une unification définitive de la stratégie de build est à envisager. M4 est une technologie sur le déclin et son maintien doit se justifier.

• La qualité et la quantité de la documentation est excellente. Il serait potentiellement bénéfique de fournir une documentation type "Rationale" sur les choix d'implémentations interne et/ou une documentation orientée contributeur.

• Le processus de release est basée sur un rythme annuel. La numérotation majeur est liée au standard C++ supporté. Cette stratégie est extrêmement importante car elle limite la quantité de code mort // core rot.

• La quantité d'Issues est acceptable, leur gestion est planifiée et leur temps moyen de complétion est maîtrisé.

[jfalcou]

Actions suggérées

• Documentation

  • Rendre la documentation plus fluide et plus progressive. L'effort sur le "Mfront Book" est un pas dans la bonne direction.
  • Fournir une documentation type "Rationale" sur les choix d'implémentations interne et/ou une documentation orientée contributeur.

• Qualité

  • Investir du temps sur l'automatisation et la systématisation de l'utilisation d'outils d'analyses. CPPCHECK est un bon début et passé sur des solutions plus industrielles comme PVSStudio ou Sonar serait à envisager.
  • Rendre systématique le CI sur les sanitizers.
  • Rendre automatique et systématique l'utilisation de fuzzers.
  • Un effort est à entamer pour augmenter la quantité et la granularité des tests unitaires.

• Autre points

  • le support des systèmes et architectures doit être facilité par une simplification de l'accès au machines nécessaires (cf tests et déploiement Windows).

[jfalcou]

Conclusion

La qualité globale de la gestion du projet est très élevée. L'effort mis sur la structuration du code, la volonté de suivre les évolutions du langage, la qualité et la quantité de la documentation et des tests contribuent à cet état de fait.

De mon point vu d'expert, MFRONT est un logiciel d'une qualité exemplaire compatible avec une utilisation dans un contexte industriel à fort enjeu de sureté.

Il est important de permettre à ce projet de poursuivre ces efforts afin de continuer à fournir un logiciel de qualité.