Discussion :

[Eduardo Rocha]

La programmation en C++ est difficile, le génie logiciel en C++ est encore plus difficile

EDUARDO ROCHA 26-06-2023 Génie logiciel
Mis à jour le 6 juillet 2023.

Il existe probablement une corrélation entre les compétences en programmation C++ d’une personne donnée et sa capacité à développer des logiciels dans ce langage. Cependant, ces deux aspects sont distincts et n'évoluent pas toujours ensemble. Il est naturel de supposer que la maîtrise de C​++ se traduit directement par la capacité de développer des logiciels en C​++, mais les deux ne sont pas toujours synonymes. Cet article explique comment la complexité du C​++ crée des défis pour le génie logiciel. Il traite également de l'importance de la simplicité pour la maintenabilité et le succès à long terme.

Le génie logiciel et la programmation ne sont pas la même chose.
« Le génie logiciel peut être considéré comme une "programmation intégrée au fil du temps". »
_ Génie logiciel chez Google

C++ est complexe, le génie logiciel n’aime pas ça

C++ est un cas particulier en raison de sa complexité. Il offre de nombreuses façons d'accomplir la même chose et il comporte également de nombreux pièges. C++ est un langage si puissant que les développeurs ont mis au point une infinité de modèles de programmation. Toutefois, le génie logiciel n'aime pas la complexité et ne s'entend pas naturellement avec le C++. Peut-être que cela n'est pas visible dans les petits projets ou les équipes, mais considérez les défis lorsque des dizaines, voire des centaines d'ingénieurs travaillent sur la même base de code comprenant des centaines de milliers de lignes.

Tout comme C, C++ attend du développeur qu'il soit un expert et qu'il l'utilise avec soin. Se tirer une balle dans le pied est assez facile. Pour les projets à grande échelle avec plusieurs développeurs, où seulement quelques-uns seront des experts, le soin et l'attention de toutes les personnes impliquées sont indispensables.
Par exemple, considérez les principes de génie logiciel suivants :

1. «Vous n'en aurez pas besoin. » “You aren’t gonna need it” (YAGNI) stipule qu'un programmeur ne doit pas ajouter de fonctionnalités avant de les avoir jugées nécessaires. C++ propose de nombreuses manières différentes d’aller à l’encontre de ce principe. Il est tentant de faire d'une fonction ou d'une classe un modèle afin qu'il puisse être réutilisé pour différents types de données, même s'il est actuellement utilisé pour un seul type. Cela rend le code plus difficile à lire, augmente le temps de compilation et dégrade l'utilisation d'outils tels que les analyseurs statiques et les compléteurs de code. Par conséquent, cela ne devrait pas être fait à moins qu'il n'y ait un besoin pour cela.
2. Évitez l'optimisation prématurée. C'est un principe bien connu qui peut être ignoré dans n'importe quel langage de programmation. Toutefois, si vous utilisez C++ dans un projet, c’est probablement parce que vous avez besoin de bonnes performances. Donc, un certain niveau d'optimisation est nécessaire ; parfois, il faudra même beaucoup d'optimisation. Le problème est qu'il est difficile de délimiter, au sein d'un projet, le code qui doit être optimisé et le code qui n’en aura pas besoin. C++ nous donne les outils pour tout optimiser et nous optimisons souvent plus que nécessaire.

J'adore C++ et c'est mon langage de prédilection par défaut. S'il est utilisé correctement, il fera au moins aussi bien que la plupart des autres langages. Cependant, reconnaître les dangers et les pièges potentiels du langage est la première étape vers un développement sain.

La simplicité est la clé d'une bonne ingénierie logicielle et C++ par défaut n'est pas simple.

Simplifiez lorsque cela est possible !

Le parcours d'apprentissage de C++ a souvent plusieurs pics de confiance. Plus vous apprenez, plus vous réalisez à quel point vous ne savez pas. Et je crois que cela crée un modèle intéressant. Les développeurs expérimentés ont tendance à se limiter à des sous-ensembles du langage et à des sous-ensembles de modèles de programmation suffisants et sûrs. Cette approche est efficace pour simplifier le langage pour un développement facile et maintenable.
Je ne fournirai pas de recette pour le faire. Je ne suis pas sûr d'être qualifié pour le faire. Une chose que je peux dire, c'est qu'un code simple est généralement meilleur que le code optimal et le plus performant. En C++, le code optimal est souvent difficile à lire, difficile à comprendre et, surtout, difficile à maintenir. Je dirais qu'une grande partie de la programmation C++ peut être décrite comme une optimisation précoce à petite échelle.

Un autre problème est que l'écriture de code complexe peut être amusante et, parfois, belle. De nombreux développeurs tombent amoureux de C++ pour cela. Beaucoup d'entre nous trouveront de la joie en utilisant des motifs complexes pour le plaisir. Néanmoins, le problème est que le code devient souvent plus compliqué qu'il ne devrait l'être. Moi-même, j'en suis coupable. Les développeurs qui entrent dans ce groupe devraient au moins être conscients de ce qu'ils font afin qu'ils puissent réfléchir à deux fois avant de trop compliquer les choses pour le plaisir. J'ai travaillé avec des gens qui s'intègrent très bien dans ce groupe, mais qui ne le savent pas. Beaucoup perçoivent l'ajout d'une complexité inutile comme une démonstration de compétence et ne voient pas ses inconvénients (ou ne s'en soucient tout simplement pas).


« Le débogage est deux fois plus difficile que l'écriture du code. Par conséquent, si vous écrivez le code aussi intelligemment que possible, vous n'êtes, par définition, pas assez intelligent pour le déboguer.
— Brian Kernighan

Si la simplification n'est pas possible, encapsulez les bits complexes

Si vous utilisez C++, c’est probablement parce votre projet nécessite de bonnes performances. En outre, des modèles de conception plus complexes peuvent être nécessaires ou peuvent entraîner un code plus simple. Dans ces cas, C++ fournira les bons outils pour le travail, mais le code résultant peut ne pas être facilement lisible ou facile à lire ou à comprendre.

Heureusement, C++ fournit également les outils pour encapsuler correctement et cacher cette complexité. Ici, suivre les principes de l'ingénierie logicielle comme SOLID avec une attention et un soin supplémentaires peut guider le développeur vers le succès.

Le temps supplémentaire nécessaire pour le faire correctement pour les pans les plus complexes (par exemple, une conception plus approfondie et des révisions de code) en vaut la peine à long terme.

Principaux points à retenir

1. C++ est connu pour sa grande complexité et offre de nombreux modèles de programmation. Cependant, le génie logiciel, qui met l'accent sur la simplicité et la maintenabilité, peut ne pas s'aligner facilement avec les subtilités du C++.
2. Simplifiez C++ pour un développement maintenable. L'écriture de code facile à comprendre et à maintenir est généralement plus précieuse pour le succès à long terme que l'écriture de code optimal et allégé.
3. Soyez conscient de la complication excessive et de l'optimisation précoce. Tenez-vous et vos collègues responsables.

La prochaine fois que vous interviewerez quelqu'un pour un poste senior en C++, ne demandez pas au candidat à quel point il est bon en C++, posez-lui des questions sur les pièges du C++ pour le génie logiciel. Il sera très facile d'identifier des ingénieurs ayant une expérience de développement pertinente.

Faire ce qui précède est plus facile à dire qu'à faire. Parfois, des modèles de programmation complexes avec des fonctionnalités de langage complexes se traduiront par un code plus simple et meilleur. Apprendre à le faire nécessite non seulement de l'expérience, mais aussi de la sensibilisation. J'espère que ce billet augmentera votre sensibilisation.

Je tiens à souligner que cet article a été écrit sur la base de mes propres fortes opinions. Donc, si vous êtes d'accord ou si vous avez un point de vue différent, j'aimerais l'entendre ! N'hésitez pas à laisser un commentaire ou à nous contacter.

La version originale de cet article

Et vous ?

Que pensez-vous de la programmation en C++ ?
Pensez-vous que la programmation en C++ est vraiment difficile ? Partagez vos avis.

[epsilon68]

J'ai vraiment aimé le c++, j'ai commencé dans ce language. Je me suis même éclaté, j'avais tout fait entièrement.

La conception logiciel est la clef de tout développement, et elle est plus dure en C++ car il faut définir qui est le propriétaire de chaque objet (Cependant, même si les gens ne le font pas en java ou c#, c'est un méga tort, et fait du code peu fiable.) et définir une bonne API est une chose complexe, mais dans tous les languages.

Après je pense que la difficulté ultime est la reprise du code par quelqu'un d'autre. Ma dernière expérience était en C# et était tout bonnement horrible, cependant il est assez aisé de faire du refactoring en C#.

J'avoue que je me suis dit, tellement j'ai souffert, qu'au vu de ce que des personnes peuvent faire en C#, je n'imagine pas ce qu'ils peuvent faire en C++. Aurais-je réussi à modifier et faire évoluer le programme ? je n'en suis pas sûr car le code est 10x plus difficile à lire, mais aussi 10x plus difficile à refactorer en C++.

Je ne sais pas si je reviendrais un jour à programmer en C++, je ferais surement un audit du code avant de me décider 🫣

ps: à tous les managers et DSI : vous êtes responsable de la situation dans laquelle vous avez mis vos équipes, être dans le déni ne sert à rien, la réalité reviendra toujours au plus mauvais moment avec des conséquences toujours plus grandes.

[Madmac]

Je ne sais pas si je reviendrais un jour à programmer en C++, je ferais surement un audit du code avant de me décider 🫣

[Madmac]

1. «Vous n'en aurez pas besoin. » “You aren’t gonna need it” (YAGNI) stipule qu'un programmeur ne doit pas ajouter de fonctionnalités avant de les avoir jugées nécessaires. C++ propose de nombreuses manières différentes d’aller à l’encontre de ce principe. Il est tentant de faire d'une fonction ou d'une classe un modèle afin qu'il puisse être réutilisé pour différents types de données, même s'il est actuellement utilisé pour un seul type. Cela rend le code plus difficile à lire, augmente le temps de compilation et dégrade l'utilisation d'outils tels que les analyseurs statiques et les compléteurs de code. Par conséquent, cela ne devrait pas être fait à moins qu'il n'y ait un besoin pour cela.
2. Évitez l'optimisation prématurée. C'est un principe bien connu qui peut être ignoré dans n'importe quel langage de programmation. Toutefois, si vous utilisez C++ dans un projet, c’est probablement parce que vous avez besoin de bonnes performances. Donc, un certain niveau d'optimisation est nécessaire ; parfois, il faudra même beaucoup d'optimisation. Le problème est qu'il est difficile de délimiter, au sein d'un projet, le code qui doit être optimisé et le code qui n’en aura pas besoin. C++ nous donne les outils pour tout optimiser et nous optimisons souvent plus que nécessaire.

Le deuxième paragraphe est valable, mais pas le premier. La vitesse de compilations n'est pas un argument valable. La vitesse du code est la seule chose qui compte quand il est question de compilation. Un général, les programmeurs d'expérience font ce genre de truc en sachant que cette classe aura des descendants. Ou pour éviter de fabriquer des constantes et variables globales Et parce que cela permet de définir les noms des méthodes et de variables, à l'avance, afin encadrer les programmeurs qui travailleront avec ce code.

Si vous utilisez C++, c’est probablement parce votre projet nécessite de bonnes performances. En outre, des modèles de conception plus complexes peuvent être nécessaires ou peuvent entraîner un code plus simple. Dans ces cas, C++ fournira les bons outils pour le travail, mais le code résultant peut ne pas être facilement lisible ou facile à lire ou à comprendre.

Heureusement, C++ fournit également les outils pour encapsuler correctement et cacher cette complexité. Ici, suivre les principes de l'ingénierie logicielle comme SOLID avec une attention et un soin supplémentaires peut guider le développeur vers le succès.

La POO a été inventer avant tout pour produire du code avec des groupes de programmeurs. Si la vitesse est votre premier soucie, SOLID est à éviter comme la peste. Il est difficile à optimiser. Et DRY est encore pire. La POO a la réputation de produire des programmes lents alors qu'en réalité la cause principale est l'adoption de SOLID. SOLID permet la PRODUCTION de code plus rapidement. POINT!.

Mark Zuckerberg a fait la première version de Facebook en Ruby alors que le langage était trois fois plus lent. parce qu'il avait compris que la première qualité qu'un programme se doit d'avoir est de fonctionner.

“Done is better than perfect.”

-Mark Zuckerberg

[ternel]

L'objectif de SOLID est de produire du code solide: résistant au passage du temps, au changement de développeurs, etc. On dit aussi "maintenable".
Il permet de réduire les bugs (disparition totale de classes entières de bugs comme l'oubli de fermeture d'une session, d'une connexion, etc)

Je n'ai jamais vu SOLID rendre un programme écrit en POO plus lent, moins optimisé. As-tu des témoignages, des études ou des exemples concrets la-dessus?

[jo_link_noir]

Les principes SOLID ont une approche très OO dans leur description, mais en fait, ce n'est pas SOLID qui rend moins opti ou plus lent, mais la POO dans certains contextes.

Par exemple, si on possède un tableau d'un type quelconque qui contient 3 états qu'on veut manipuler, on va généralement faire une boucle sur chaque élément qui manipule l'état 1, puis le 2, puis le 3. Si les calculs dépendent du résultat de l'état précédent, on va faire une boucle qui manipule l'état 1, puis une boucle pour l'état 2 et pareil pour le 3ème.

Il s'avère que cette approche est généralement moins optimale que 3 tableaux qui représente chacun un état, car elle engendre plus de perte de cache. C'est la différente entre SoA (Structure of Array) et AoS (Array of Structure).

À ce niveau, on s’intéresse plus aux valeurs que contiennent nos structures plutôt qu'à une abstraction qui permet de les manipuler de manière transparente. Dans ce contexte on se retrouve en opposition avec les principes SOLID. De toute manière, une approche OO ne fonctionne pas bien ici, on va plutôt faire de la programmation orientée data.

Par contre, quand l'OO est adapté, SOLID est utile et je suis du même avis que toi sur la maintenabilité.

Par contre, je ne vois en quoi SOLID permet la disparition totale des fermetures d'une connexion ? Pour moi c'est le RAII qui fait permet cela ou autre selon le langage (le mot clef finally, les contextes managés, etc)

[koala01]

Salut,

Humm, je ne suis pas aussi catégorique que toi..

Il est vrai que le L de SOLID (LSP, mis pour Liskov Substitution Principle) est -- très clairement orienté objet, vu qu'il parle du seule principe qui soit effectivement spécifique à l'OO : la substituabilité.

Mais pour les autres...

Il n'y a -- par exemple -- absolument aucune difficulté à s'assurer qu'une fonction fasse une chose et une seule, même dans un contexte "non OO", que l'on adopte l'approche AOS ou SOA ne changera sans doute absolument rien : une fonction sera toujours plus facile à tester et à maintenir si elle ne s'occupe effectivement que d'une chose et d'une seule.

Il en va d'ailleurs de même avec l'OCP : Il est "relativement facile" de s'arranger pour "fermer son code" aux modifications (eg : pour faire en sorte qu'un comportement écrit, testé et validé ne doive pas être modifié) mais pour "l'ouvrir" aux évolutions. Et dans ce cas encore, AOS ou SOA n'y changera rien ... à moins bien sur que l'on décide de passer de l'un à l'autre.

Quant aux deux derniers -- ISP et DSP --j'ai d'avantage tendance à les considérer comme les pistes privilégiées à envisager pour améliorer le respect des trois premiers ou, selon la situation, comme le "résultat naturel" d'une tentative (réussie) d'améliorer le respect des trois premiers.

Après, on peut bien sur discuter des heures sur "ce qui fait" réelleement "l'approche OO". M'étant déjà exprimé sur le sujet, je ne le ferai ici que si on m'en fait la demande Mais comme vous le savez, j'ai un avis "plutôt tranché" et sans doute très différents de la plupart des gens

Mais, quoi qu'il en soit, il faut se souvenir que SOLID sont -- d'abord et avant tout -- des principes de conception, ce qui implique que l'on doit (ou du moins, que l'on devrait) s'assurer :

1. que la manière dont on envisage de faire les choses les respecte les respecte avant d'écrire la moindre ligne de code et
2. que la manière dont on écrit effectivement le code continue à les respecter "tout au long du processus"

[jo_link_noir]

Il n'y a pas que L qui saute, il y a aussi le D et je ne vois pas vraiment comment appliquer l'ouverture du O sans point de variation disponible. Ça va être compliqué de faire des extensions sans faire de modification.

Pour moi il n'y a que le S (et le I qui va bien avec) qui est un principe plutôt logique, mais qui possède certaines limites: plus on possède de contexte plus il est "facile" de trouver des optimisations. Par conséquent, 2 fonctions peuvent être fusionnées pour faire la même chose de manière plus efficace. Je ne vais pas dire que cela arrive souvent, c'est même plutôt rare, mais c'est quelque chose qui arrive un peu plus souvent quand on se concentre sur nos données.

[Madmac]

L'objectif de SOLID est de produire du code solide: résistant au passage du temps, au changement de développeurs, etc. On dit aussi "maintenable".
Il permet de réduire les bugs (disparition totale de classes entières de bugs comme l'oubli de fermeture d'une session, d'une connexion, etc)

Ce que tu que tu décris sont les avantages d'un framework qui utilise l'héritage. Mais ce soucier de SOLID avant même d'avoir une idée claire du résultat final amène les même risques que les microservices. SOLID devrait être considéré au même moment que le l'on passer à l'étape de l'optimisation

Je n'ai jamais vu SOLID rendre un programme écrit en POO plus lent, moins optimisé. As-tu des témoignages, des études ou des exemples concrets la-dessus?

Le S de SOLID est le point le plus problématique. Si l'objet n'a qu'un type de responsabilité, cela exclus les conversion. Donc tu dois fabriquer des classes (et des objets additionnelles)pour gérer cette responsabilité. Alors que plusieurs constructeurs pourraient faire l'affaire.

Et dans le cas des langages qui supportent les fonctions imbriqués, de grosses classes qui contiennent plusieurs objets sont parfaitement logique, car cela permet de remplacer des constantes globales en constante locale. Et de réduire le nombre de paramètre des certaines fonctions.

Quelque fois utilisé une classe comme un domaine est la solution la plus performante. Plus on complexifie un programme, plus il devient difficile de l'optimiser. Donc avant de considérer SOLID, il est préférable de considérer Principe_KISS comme le critère le plus important.

[ternel]

KISS est tout autant l'essence du SRP.

J'applique SOID avec beaucoup d'intérêt sans avoir à définir le moindre héritage. J'ai même tendance à considérer l'héritage comme un problème (en tout cas, la virtualité et l'héritage publique)

RAII, dont les smart-pointers, sont un excellent moyen de supprimer les fuites de mémoire. Démontrable, robuste, OCP à fond, et sans héritage.
Une classe de connexion ssh aussi, toujours sans héritage.

SOLID est pour moi une préoccupation pendant que je conçois mon architecture.
C'est pour moi une application du principe d'encapsulation: si c'est fragile, je cloisonne et j'isole: SRP+OCP dans toutes les capsules. Pas d'héritage implique que L, I et D sont immédiatement respectés, puisque sans objet

[Madmac]

KISS est tout autant l'essence du SRP.

J'applique SOID avec beaucoup d'intérêt sans avoir à définir le moindre héritage. J'ai même tendance à considérer l'héritage comme un problème (en tout cas, la virtualité et l'héritage publique)

L'héritage n'est pas forcément un problème. Mais s'il est utilisé sur une portion de code très utilisé (genre à l'intérieur d'une énorme boucle). Ou que le programme doit chercher une méthode sur plus d'une génération. Alors il est préférable de recopier les méthodes communes à tous ces classes.Le truc est de savoir, où l'héritage est susceptible de nos faire perdre de la vitesse.

Les "smart pointers" ont les même handicaps que l'héritage. L'approche SOLID cohabite très avec les assemblages par composition (module en Ruby, Traits en Rust). En C++, c'est possible par l'inclusion d'une classe polymorphique avec idéalement un minimum de méthode. En terme de performance c'est le meilleur des mondes. Polymorphisme de l'héritage. Et la performance d'une fonction. Pourquoi? Parce que l'héritage n'est utilisé qu'à un seul endroit: Pendant la création de l'objet. Ce qui fait que le compilateur compile les méthodes de la même façon que des "fonctions amis".