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".