Organisation d'un projet C++

Version imprimable

20/06/2018, 12h14
awawawa

Organisation d'un projet C++

Avant tout bonjour tout le monde,

Je pense que je faire ici le post de ma vie 8O.

Physicien de formation (donc non informaticien), je prenais, il y a quelques mois, en charge dans ma startup le développement informatique d’une application d’imagerie […], le tout en c++ avec une surcouche Qt sous MS Visual.

Jusqu’à là tout allait bien : j’ai bien programmé mes classes (une bonne cinquantaine !), avec les héritages qui vont bien, les gestions d’erreurs et des exceptions, la parallélisation de certaines tâches, puis est venu la documentation du code (doxygene), le versionning (avec git), la création de programme de test (avec le framework de msvisual) puis le déploiement avec succès du programme chez le client.

Unitairement parlant, je n’ai pas trop de mal à réaliser ces tâches. Il est très facile de trouver sur internet comment versionner un programme par exemple ou effectuer un test unitaire sur une classe ou créer une DLLs. Là où j’ai un peu plus de mal à me documenter c’est sur comment articuler toutes ces tâches les unes avec les autres, comment organiser son projet (dossiers et DLLs) etc etc...
Aujourd’hui, j’ai un dossier rempli de .h et de .cpp que j’ajoute à un projet (j’y joins éventuellement les bibliothèques tiereses dont j’ai besoin) et que je compile. J’obtiens alors un exe qui donne satisfaction à mon client. Cependant, moi je ne suis pas convaincu. J’aimerais vraiment automatiser ma façon de travailler et mon cycle en V (je vais le simplifier ici : création d’une nouvelle fonction, conversion cpp vers DLLs, test unitaire puis si test validé intégration et test d’intégration et enfin déploiement).

Plusieurs questions se posent alors à moi :

En ce qui concerne les DLLs :

Mon instrument d’imagerie est composé de plusieurs périphériques, lesquels sont liés par des relations d’héritages et de sororité (ça se dit ça ?). Dois-je créer une DLL par famille de périphérique (ce que j’ai cru comprendre) ou par périphérique ou une DLL globale?

Dans le cas où il faudrait créer une DLL par famille de périphérique : il est dit que dans git, il faut ignorer les DLLs. Cela veut dire que lorsque j’intègre une DLL dans mon programme final (lequel utilise l’ensemble des DLLs générées dans la question 1), si je versionne mon programme final, alors lui ne verra pas de changement. C’est un peu embêtant non ? Que faut-il alors versionner ? Comment faut-il s’y prendre ?

Dans la stratégie, un espace nom doit-il englober une seule classe ou un ensemble de classe ayant la même fonction ?

Versionning :
Pourquoi, on utilise un numéro de version type 1.01.1 au lieu d’utiliser directement le numéro de commit que git donne ? Est-ce non recommandé ? Dans le cas où ça ne serait pas non recommandé, est-il possible de récupérer ce numéro ?

Organisation des DLLs :
Est-il possible de placer les dll ailleurs que dans le répertoire qui contient le .exe et dans ce cas, quel est selon vous la meilleure stratégie d’organisation ?

Logs:
Il manque un fichier log dans mon programme principal, j’ai lu les tutoriels concernant la programmation de ces logs ici et là. Je n’arrive cependant pas à saisir l’utilité et la puissance de ces objets : pourquoi utiliser des logs au lieu d’écrire directement dans un journal lorsqu’une exception est déclenché ? Quel est l’apport en plus ?

Metadonnées :
Est-il possible qu’une DLL ou un .exe indique l’heure à laquelle il a été compilé ?

Alors il y a beaucoup de question, je le sais mais j'aimerais qu'il serve de base pour ceux qui aimeraient commencer un projet, qui n'ont pas de difficulté en code mais qui aimerait avoir une petite checkliste de chose à verifier.

Bonne après midi et bon match de foot pour ceux qui aiment ça
20/06/2018, 13h12
Bktero
Bonjour,

Je ne fais jamais de DLL, je passe mon tour sur ces points :)

Versionning : un numéro de version comme 1.10.2, c'est normalement ce qu'on apppelle du semantic versioning. Rien ne t'oblige à faire comme ça.

Logs: dur en effet de voir l'intérêt quand tu n'as jamais pratiqué. On peut voir plusieurs intérêts :
1. Chaque à un niveau de criticité. Cela permet de filtrer (soit en demandant à ce que les logs d'un niveau inférieur à un seuil soit jeté, soit en faisant un grep (-v) sur un fichier contenant tous les logs)
2. On utiliser en général plusieurs loggers dans une application, pour classer les logs par thématiques.
3. On peut faire un sorte que le même log partent dans plusieurs canaux de publications (en Java, on parle de Handlers, en Python aussi, certains bibliothèques ont d'autres noms comme SPD qui parlent de sinks) pour par exemple logguer tous les logs dans un fichier texte mais envoyer un mail à l'exploitant pour les logs avec un niveau de criticité élevé).
En mixant tout ça, tu arrives à beaucoup plus de souplesse et de finesse dans ce que contient ton journal de logs (ou du coup tes journaux de logs).

Là par exemple je suis sur un MCU, j'affiche sur une liaison série et un hyperterminal sur mon PC. Je vois des choses comme ça :
Code:

1 2 3 4 4 (aborted 4) Voltage = 51216 Monitoring [INFO] Drive temperature = 31 Monitoring [INFO] Motor temperature = 26
Les 2 premiers sont des simples printf(), les 2 suivants sont des logs. Les 2 premiers, si je veux les désactiver, je dois commenter le code ; les 2 suivants, je n'ai qu'à désactiver le logguer appelé "Monitoring" sans changer au reste de mon code...et surtout je peux faire ça dynamiquement (pas de besoin de recompiler) !

Honnêtement, ça peut vraiment être un plus. Il faut essayer ;)
20/06/2018, 17h17
Seabirds

Bonjour !

Citation:

Envoyé par Bktero

Je ne fais jamais de DLL, je passe mon tour sur ces points :)

Peux-tu expliquer ce choix s'il te plaît ? :)
20/06/2018, 18h38
Pyramidev
Bonjour,

Citation:

Envoyé par awawawa

Dois-je créer une DLL par famille de périphérique (ce que j’ai cru comprendre) ou par périphérique ou une DLL globale?

D'abord, il faudrait déterminer si la création d'une DLL, même une seule, est vraiment pertinente.

Cela peut être pertinent si le contenu de la DLL est à la fois très stable et utilisé par plein d'exécutables. Sinon, cela ne fait que compliquer la vie.

Les avantages d'une DLL sont les suivants :
- Les exécutables qui utilisent la DLL sont plus petits car, au lieu de stocker toutes les opérations sur place, certaines opérations sont stockées dans la DLL.
- Quand on corrige un bogue ou qu'on améliore les performances d'une opération partagée par plusieurs exécutables, au lieu de recompiler et redéployer chacun de ces exécutables, on recompile la DLL et on redéploie la DLL.
Citation:

Envoyé par awawawa

un espace nom doit-il englober une seule classe ou un ensemble de classe ayant la même fonction ?

Quand une paire de fichiers .h/.cpp ne contient que des fonctions globales, alors il est souvent pertinent de créer un espace de nom spécifique à cette paire de fichiers.
Comme ça, quand on lit Truc::maFonction, on sait qu'il s'agit d'une fonction de Truc.h et Truc.cpp.
Par contre, si une paire de fichiers .h/.cpp ne fait que définir une classe, alors il est inutile de créer un espace de nom spécifique à cette classe.

De plus, chaque projet devrait avoir un espace de nom spécifique. Rq : une bibliothèque est aussi un projet.
L'intérêt est d'éviter les collisions de noms, par exemple quand une classe dans le code spécifique d'un projet porte le même nom qu'une classe d'une bibliothèque utilisée par ce projet.

Citation:

Envoyé par awawawa

pourquoi utiliser des logs au lieu d’écrire directement dans un journal lorsqu’une exception est déclenché ?

Un log est justement une sorte de journal.

En général, chaque entrée d'un fichier de log a au moins ces trois informations :
- la date et l'heure du message,
- le niveau de log (ex : erreur, avertissement, info, debug) et
- le message.
L'un des buts est d'aider à analyser des problèmes quand les utilisateurs donnent des informations incomplètes (ce qui arrive souvent) voire fausses (ce qui arrive parfois). En plus des exceptions levées, je conseille de loguer aussi les actions des utilisateurs.

Citation:

Envoyé par awawawa

Est-il possible qu’une DLL ou un .exe indique l’heure à laquelle il a été compilé ?

Normalement, tout ce dont tu as besoin, c'est le numéro de version.
Sur Windows : clic droit >> Propriétés >> Détails >> Version du fichier.
20/06/2018, 19h48
Bktero

Citation:

Envoyé par Seabirds

Peux-tu expliquer ce choix s'il te plaît ? :)

Micro-contrôleur, pas de loader dynamique, toussa toussa 8-)
21/06/2018, 09h59
awawawa

Salut tout le monde,

Merci pour vos différentes réponses.

@Bktero je vais essayer de digérer ce que tu m'a dis. Je reviendrai surement vers toi quand j'aurais un peu plus compris :D

@ Pyramidev et Seabirds : merci
17/09/2018, 18h07
bacelar

Citation:

j’ai un peu plus de mal à me documenter c’est sur comment articuler toutes ces tâches les unes avec les autres, comment organiser son projet (dossiers et DLLs) etc etc...

Ça, c'est fonction des méthodes de développement que vous voulez utiliser (XP, Scrum, RUP, Waterfall...)
Il y en a plein et elles ont chacune des avantages et des inconvénients.
Et ces méthodes sont souvent très très flou sur comment les mettre en pratique concrètement.

Des manière de faire pour une méthode peuvent ne pas être efficace ou faisable pour d'autres.
C'est assez difficile de mélanger des méthodes qui n'ont pas été conçues pour.

Je vous conseille de lire un peu de littérature sur le sujet, histoire de voir quelles pratiques correspondent à quels types de méthodes.

Il y a aussi les notions d'architectures logicielles, mais c'est aussi un peu l'auberge espagnole.

Le bon sens et l'expérience marche pas mal dans ce domaine.

Citation:

Aujourd’hui, j’ai un dossier rempli de .h et de .cpp que j’ajoute à un projet (j’y joins éventuellement les bibliothèques tiereses dont j’ai besoin) et que je compile.

Si vous pouvez découper cet ensemble de classes en modules les plus indépendants les uns des autres et regrouper les modules en fonction du niveau d'abstraction gérer par ces modules, vous aurez une base de code bien plus facilement réutilisables et maintenables.
Les espaces de noms, le regroupement en librairies, en Dll, les couches d'architecture logicielle sont des concepts qui renforce ce découpage en modules indépendants.

Citation:

J’aimerais vraiment automatiser ma façon de travailler et mon cycle en V

Le cycle en V, c'est très vieux comme méthodologies de développement, on est plus dans des approches agiles actuellement, et les écosystèmes des outils ont tendance à privilégier ces types de méthodes.

Je trouve que mes VDD ont une vue assez limité de l'utilisation des Dll, il y a aussi, entre autres, le partage de données entre exécutable, l’accélération du lacement d'une application, customisation d'une application via plug-ins, localisation d'une IHM, adaptation à des caractéristique particulière d'une plateforme hardware ou d'un OS particulier, utilisation de framework d'application composite, sécurisation (surrugate), traçabilité(man in the middle) , etc... etc...

Mais il n'y a pas une "bonne approche" de faire ou d'installer des Dll, c'est fonction de la finalité finale de la Dll.
Une Dll est un outils, rien d'autre.

>Dois-je créer une DLL par famille de périphérique (ce que j’ai cru comprendre) ou par périphérique ou une DLL globale?
Le problème n'est pas lié à l'usage de Dll ou pas.
C'est un problème de pure conception logicielle.
Si votre conception permet d'avoir des modules indépendants, les faire migrer dans une ou des Dll ne posera pas de problème particulier.

Citation:

il est dit que dans git, il faut ignorer les DLLs.

Git est un gestionnaire de code source. Ces outils et concept sont adaptés à du code source.
Mais rien ne vous empêche de coller ces fichiers Dll dans Git, mais c'est un peu cracra et les outils de Git seront pas d'une grande utilité.
Généralement, Git, n'est qu'un maillon de la chaine d'outils en charge de la gestion de la vie d'une application (et pas juste la gestion des versions des sources).
Dans beaucoup de méthodes de développement, l'étape de génération pour tests et pour les releases se fait via des outils d'Intégration Continue, où la génération des livrables est déportée dans des Usines de Build qui permettent une très grande traçabilité entre les livrables, le code sources, les résultats des tests automatiques, les fichiers de débugging terrain, etc...

Citation:

Est-il possible de placer les dll ailleurs que dans le répertoire qui contient le .exe et dans ce cas, quel est selon vous la meilleure stratégie d’organisation ?

Au que oui, et c'est la source de bien des emmerdes.
Il y a autant de stratégies que d'objectifs à l'utilisation d'une Dll ou une autre.
Il n'y a pas "une" réponse, c'est fonction de l'usage.
Mais, actuellement, avec le cout du stockage sur disque, l'approche à fusionner l'usage d'une Dll pour plusieurs applications est assez peu utile et induit pas mal d'approche indésirable.
Donc, actuellement, sous Windows, on est plus sur une approche où chaque application a sa propre version des Dll et utiliser des outils de mise à jour automatique des applications.
P.S.: c'est toujours mieux de mettre les Dll dans un sous répertoire dédié plutôt qu'à la racine d'installation de l'application.

Citation:

Est-il possible qu’une DLL ou un .exe indique l’heure à laquelle il a été compilé ?

Oui, le TimeDateStamp du format PE
https://docs.microsoft.com/en-us/win...ebug/pe-format
Mais c'est un peu "hardcode" et les outils qui ont besoin de ce type de donnée savent se dépatouiller avec.
L'outil DUMPBIN ( https://msdn.microsoft.com/fr-fr/library/c1h23y6c.aspx ) permet de décortiquer facilement ce format.