Discussion :

[sam__th]

Bonjour a tous,

Tout d'abord, veuillez me pardonner mais j’écris actuellement avec un clavier QWERTY. Je vais essayer de faire tout mon possible pour corriger ce que je peux.

Ceci étant dit, je vous décrit rapidement ma situation suivi des questions. Je suis gestionnaire d'une petite PME et j'aurais besoin d'avis sur une série de question, histoire d'alimenter un débat. Je ne peux en dire plus, mais si vous pouviez simplement répondre aux questions de votre choix et expliquer, en termes simple (cela s'adressera a des néophytes), le pourquoi de votre réponse, cela serait vraiment aimable de votre part et cela me permettrais de mettre de l'eau a mon moulin. Il va s'en dire que j'ai près de vingt ans dans le métier et sans compter mon expérience hors métier, je connais bien entendu les réponses, le but étant bien entendu de collecter les avis différents. Même si d'autres ont déjà répondu, je cherche a collecter le plus de réponses possible, donc, votre avis est précieux!

Votre aide me serait plus que précieuse, voici donc les questions. Pour répondre, faire précéder la réponse de la lettre correspondant a la question ou quottez la simplement.

A) Deux logiciels sont développés en C++/QT. En comparant les source de maniérè brutes, c'est a dire de la manière textuelle la plus basique, on met en exergue 5% de lignes communes, aucune ne formant de blocs contigus ni de noms de fonctions. Les deux logiciels ne sont pas des copies l'un de l'autre. Comment se fait-il que nous ayons malgré tout des lignes en commun?

B) Que vous invoque le "#include<XXX>", pourquoi est-il utilisé. Si on retrouve tout ces lignes dans la documentation d'un outil, que cela signifie-t-il?

C) Pour un développeur c++ (pratiquant ce langage depuis des années) changeant de projet, est-il raisonnable, en dehors de tout impératif éventuels lié a un employeur, de changer de langage et/ou d'outils pour démarrer un nouveau projet? Ceci, bien sur, en dehors de projets non commerciaux visant simplement a expérimenter ou apprendre un nouveau langage ou un outil.

D) Est ce qu’après un changement d'employeur, un développeur a tendance a continuer dans son langage de prédilection, cumulant ainsi son expérience ou celui-ci vas-t-il changer de langage?

E) Les outils tel que SQLITE, Postgres ou Qt sont-ils des outils rependus et utilises? Sont-ils gratuits?

F) Apprends-t-on a l’école des "formules" tel que boucles ou autre "code clef en main" que l'on aura tendance a trainer toute sa vie de développeur, les réadaptant si la situation l'exige?

G) Peut-on parler de "Réflexes de développement", une manière qu'aura un développeur de noter ses variables ou simplement d’écrire son code? Est ce que ces réflexes se retrouveront dans tout les logiciels développés par ledit développeur?

Je ne peux dire plus sur ce qui me pousse a faire ce questionnaire en ligne, mais je puis vous assurer que votre aide sera des plus énorme. Par pitié, ne répondez qu'aux questions a laquelle vous avez la réponse et d'une manière claire et concise.

Encore un immense merci a vous d'avance pour votre future aide.

[DonQuiche]

Bonjour à toi.

a) 5% de lignes communes mais éparpillées ? Genre for (int i = 0; i < count; ++i) ou int index = 0; ?

Alors oui, ça n'a rien de surprenant, on trouvera de telles similitudes entre tous les projets, surtout s'ils sont écrits dans le même langage.

Les bonnes pratiques prônent d'écrire des lignes courtes, d'utiliser des noms standards (donc un vocabulaire limité) et la grammaire d'un langage de programmation est de toute façon limitée. Tout cela concourt à fortement réduire le nombre de permutations possibles par ligne et débouche naturellement sur de fréquentes similitudes. Sans parler des idiomes généraux qui font eux aussi partie des bonnes pratiques (la boucle for donnée en exemple est une parfaite illustration - quelques variantes existent). Ou encore du fait que la programmation amène parfois à faire et refaire les mêmes choses.

En plus de cela on pourrait avoir à petite dose de larges groupes de lignes identiques parce que tirés des exemples de la doc officielle ou trouvés sur Internet. Ce qui est souvent légal et judicieux, et gage d'efficacité (autant prendre une solution éprouvée).


b) Le include est utilisé pour lier les morceaux entre eux, qu'il s'agisse de morceaux internes au projet, ou de composants externes (bibliothèques, systèmes d'exploitation, etc). On trouvera donc des réguliers (voire standards) tels que "windows.h", "boost.h", "qt.h", "io.h", "memory.h" mais aussi souvent des "common.h", "main.h" et compagnie. Mais hormis les exemples je ne vois pas trop ce que ça vient faire dans la doc mais il y a peut-être une raison liée à un outil externe (ghostdoc ?).


c) Beaucoup de gens répondraient qu'il vaut mieux utiliser le langage que tu connais et ça se défend. Mais pour ma part j'estime que le C++ pose trop de problèmes pour que ton expérience seule justifie son utilisation. Même si au départ ta productivité en souffrira et que tu risques de faire des âneries, mieux vaut utiliser un langage comme Java ou C# si ceux-ci se prêtent au projet. Le C++ devrait être réservé aux projets où il excelle encore (hautes performances, interaction bas-niveau avec le matériel, portabilité, quelques autres cas) ou à la maintenance de projets existants.


d) La plupart des développeurs se spécialiseront dans les solutions qu'ils connaissent et la plupart des employeurs exigeront des développeurs spécialisés dans les solutions dont ils ont besoin. A titre personnel je trouve dommage de ne jamais changer après dix ans mais après tout le C++ est toujours un langage très vivant, toujours dans le top 5 des plus populaires, avec des évolutions récentes importantes. Et puis les langages de programmation évoluent lentement : il faut quinze à vingt ans pour voir des changements notables dans le paysage.


e) Qt, Postgresql et Sqlite sont des choix solides et répandus. Des incontournables. Postgre et SQlite sont gratuits. Quant à Qt, ça dépend : c'est compliqué.


f) Un développeur acquiert effectivement des idiomes qu'il va réutiliser tout au long de sa vie. Certains sont appris par l'exemple, à l'école ou au travail, d'autres sont plus personnels.


g) Un développeur acquiert bel et bien un style propre après quelques années. Dans une petite équipe on apprend à reconnaître d'un coup d’œil l'auteur de certaines lignes. Et une étude récente a prouvé que ce style allait en s'affirmant avec l'âge et l'expérience, et était corrélé avec un nombre réduit de défauts (le bénéfice de l'expérience sans doute).

[sam__th]

Bonjour,

Merci pour cette première réponse! Je précise que je suis développeur C++/QT (C++ depuis plus de vingt ans, plus de dix ans en entreprise, Qt depuis sa quasi création) et que les questions ne portent absolument pas sur mon cas personnel (non, je ne changerai pas maintenant, plus maintenant...), mais serviront simplement a illustrer un cas précis se déroulant actuellement dans mon entreprise et ou vos différent apports permettrons de clarifier par le nombre une situation au près d'une personne hors métier.

Encore merci pour cette première réponse, en attente, avec plaisir, d'en lire encore plus!

[bretus]

C) Pour un développeur c++ (pratiquant ce langage depuis des années) changeant de projet, est-il raisonnable, en dehors de tout impératif éventuels lié a un employeur, de changer de langage et/ou d'outils pour démarrer un nouveau projet? Ceci, bien sur, en dehors de projets non commerciaux visant simplement a expérimenter ou apprendre un nouveau langage ou un outil.

J'oscille entre des projets "calculatoires", d'intégration/croisement de données et des projets web faisant des vitrines sur tout ça. Je dois avouer que je découvre des concepts et bonnes pratiques dans des langages comme Java, PHP et même JavaScript qui me resservent en C++.

Pour ce que j'observe avec la plupart des développeurs de mon entourage qui ne font que du C++, c'est que l'intérêt de nombreuses bonnes pratiques courantes dans d'autres langages ont tendance à leurs échapper. En outre, ça me perturbe que de nombreux développeurs écrivent gaiement des scripts de compilation plus compliqué qu'un gestionnaire de dépendance (maven, npm, pym, composer, etc.) qui manque cruellement au langage. Je me demande même si cet enfermement de C++ sur lui même n'est pas lié au fait qu'on ajoute des "variadic template" avant la notion de "bibliothèque" avec des métadonnées ("nom", "version", "dépendances", "compilateur", "version du compilateur", etc.) permettant une gestion des dépendances. Mais bref...

Accessoirement, je trouve préjudiciable d'être condamné à tout écrire en C++ : Avoir au moins un langage de script dans sa trousse à outil est un gros plus pour écrire rapidement des moulinettes et des services web ou encore pour monter des systèmes de plugins.

D) Est ce qu’après un changement d'employeur, un développeur a tendance a continuer dans son langage de prédilection, cumulant ainsi son expérience ou celui-ci vas-t-il changer de langage?

Il y a des gens qui aiment bien rester dans le langage qu'ils connaissent, d'autres qui préfèrent se frotter à des nouveaux concepts et nouvelles approches... Je pense qu'on progresse différemment dans les deux cas et que les deux profils sont intéressants : Le premier finira par connaître toutes les astuces d'optimisation et subtilité du langage C++, le second cumulera les bonnes pratiques des deux langages.

Pour autant, on ne perd pas tout quand on passe de C++ à Java par exemple : On établit des correspondances entre ce qui existe dans les deux langages et on fait le point sur les différences.

E) Les outils tel que SQLITE, Postgres ou Qt sont-ils des outils rependus et utilises? Sont-ils gratuits?

SQLITE : Devient la référence pour SQL en HTML5, stockage de base pour android, etc.
Postgres : Très utilisé via PostGIS dans le domaine SIG.

F) Apprends-t-on a l’école des "formules" tel que boucles ou autre "code clef en main" que l'on aura tendance a trainer toute sa vie de développeur, les réadaptant si la situation l'exige?

Les codes clés en main (boucle pour concaténé une chaîne avec un séparateur), il y a en a beaucoup moins que les structures clés en main (représenter des listes chaînés, des arbres, des graphes, etc.). A un niveau plus large, on retrouve ces formules sous le nom "patrons de conception" qui vont du micro (Singleton : comment s'assurer qu'une classe n'a qu'une instance) au niveau macro (MVC: comment gérer des interfaces graphiques faisant traitement sur des modèles de données?).

Pour le reste, j'ai l'impression que la gymnastique s'acquière avec la pratique et qu'en bref, on applique les mêmes questionnements avant de faire des choix de conception (code de retour ou exception? template ou virtual? shared_ptr, unique_ptr,...?). Aussi, on finit par accumuler une batterie de règles de conception (SOLID, DRY, KISS, RAI, etc.) qui guident dans les choix.

Après, on évolue toujours : On choisit des noms plus parlant, on écrit plus de log, on fait du code plus facilement testable (en écrivant les tests en même temps que le code), on s'arrange pour pouvoir faire de l'injection de dépendance (et des mocks), etc.

Tout ça pour dire : L'expérience ne se résume pas à des "formules" et "morceaux de code" qu'on va pouvoir copier/coller.

G) Peut-on parler de "Réflexes de développement", une manière qu'aura un développeur de noter ses variables ou simplement d’écrire son code? Est ce que ces réflexes se retrouveront dans tout les logiciels développés par ledit développeur?

En C++, il y a une grande hétérogénéité dans les styles de codage. C'est lié à deux points à mon avis : L'absence de convention de nommage et le côté multi-paradygme. Les outils utilisés influencent généralement le style d'un codeur : On peut vite parier sur le fait qu'un développeur utilise plutôt Qt, plutôt Boost, plutôt des MFC, etc.

Avec d'autres langages et framework, quand les conventions sont plus rigides (exemple de règles avec PHP/Symfony2) et qu'il y a moins de choix de conception à faire, je trouve que les styles s'effacent aux imperfections près (non respect de certaines conventions, approche non optimisée : tester si une liste est vide en comptant les éléments, non utilisation d'une fonction disponible en standard, etc.)

Pour dire ça simplement : Je reconnais facilement qui parmi mes collègues a écrit quel code C++ mais beaucoup plus difficilement qui a écrit quel code PHP ou quel code Java.

[sam__th]

Merci de votre réponse, plus qu’enrichissante.

Je vais vous proposer de recentrer la conversation, et proposer de répondre uniquement aux points a,b,e,f et g.

A tout ceux qui lisent ce post, je proposeraient, s'ils le souhaitent, de laisser même un petite "D'accord avec XXX" (si c'est bien sur le cas!). Le nombre de réponses m'est assez important.

D'avance Merci.