Discussion :

[Amine Horseman]

Que faut-il faire pour avoir de meilleurs logiciels ?
Selon un senior, il faut miser sur les techniques d’ingénierie du génie logiciel

Dans son blog nommé Building Real Software, Jim Bird, directeur de technologie chez BIDS Trading, nous interpelle avec cette question : « Si vous ne pouviez faire qu'une seule chose pour avoir de meilleurs logiciels, que serait-elle ? »

Selon lui, on devrait commencer par l’intégration continue puisqu’il faut d’abord « construire le logiciel et le faire fonctionner avant de pouvoir faire quelque chose d'utile avec ». Pour cela, il conseille de « faire en sorte que les développeurs enregistrent et synchronisent leur travail plus souvent » en gardant en tête qu’il faut construire le système (Build) le plus fréquemment possible : « au moins une fois par jour pour commencer, puis lors de chaque Check-in » déclare-t-il. Ceci implique selon lui de simplifier et automatiser le Build du système, et faire en sorte que l’opération s’effectue de manière correcte.

Il ajoute ensuite qu’on ne peut pas être Agile sans l’intégration continue, et qu’on a « besoin de la mettre en place avant de pouvoir aller sur le chemin du DevOps pour assurer la livraison ou le déploiement continu ».

La deuxième chose la plus importante à faire pour avoir de meilleurs logiciels selon Jim Bird c’est de « charger les développeurs de tester leur propre travail, et automatiser cela autant que possible en s’appuyant sur l’intégration continue », ceci serait selon lui « la seule façon de fournir des logiciels plus rapidement et réduire les coûts ». Toutefois, il rappelle que ces tests ne sont pas exhaustifs et qu’il faudra quand même quelqu’un pour vérifier manuellement la sécurité, l’utilisabilité, l’intégration ainsi que le negative testing et le stress testing, « à moins que vous vous attendiez à ce que vos clients trouvent les bugs pour vous ».

La troisième chose à faire c’est les Code Reviews. Le but étant de relire le code pour repérer les erreurs à un stade précoce, ceci permettra de créer une forme de « protection défensive de codage » selon l’auteur du blog. Il a tenu à rappeler que les reviews coûtent quand même cher et qu’il ne faut pas faire perdre le temps des reviewers à chercher des problèmes futiles.
Une autre technique citée par Jim Bird pour assurer la qualité du code est le Pair Programming. « Le pairing n’est pas la même que le reviewing » assure-t-il, « un bon reviewer pourra trouver des problèmes même dans le code développé grâce à la programmation en pair » puisque « le but et les objectifs sont différents ».

La dernière chose à faire avec laquelle l’auteur conclut l’article est de ne pas oublier le ‘refactoring’ qu’il voit comme un investissement à long terme : « Il permet de conserver -et parfois de rétablir- la conception, et de sauvegarder la maintenabilité du code […] Vous payez un peu aujourd'hui pour gagner beaucoup plus dans l'avenir ».

Source : Building Real Software Blog

Et vous ?

Êtes-vous d’accord avec l’avis de Jim Bird ?
Que faut-il faire pour avoir de meilleurs logiciels selon vous ?

[Luckyluke34]

Que faut-t-il faire pour avoir de meilleurs logiciels selon vous ?

• Trouver sa propre définition de "meilleur". Meilleur dans l'absolu ne veut rien dire.
  
  Cela dépend de l'environnement, des utilisateurs, du domaine métier, des objectifs de l'entreprise, du type d'application, etc.
  
  Fixer cette définition collectivement et en déterminer de grands objectifs à atteindre par l'équipe qui réalise le logiciel en question.

• Choisir les pratiques, techniques, approches, architectures... adaptées en conséquence.
  
  Le blog en propose quelques-unes mais il y en a des milliers d'autres. Cela nécessite pas mal d'expérience, de recherche et de remise en question (une pratique valable aujourd'hui peut très bien être rendue obsolète demain par de nouveaux paramètres).

[Logan Mauzaize]

Que faut-t-il faire pour avoir de meilleurs logiciels selon vous ?

Au delà de pratiques particulières, je pense qu'il faut former les intervenants à tenir compte de l'ensemble des domaines de la fabrique d'un logiciel. Qu'il s'agisse d'architecture, conception, analyse, développement, test, intégration, déploiement, maintenance, support, robustesse, etc.
Quand on envisage une tâche, il faut tenir compte de l'impact sur tous ces domaines.

Donc pour avoir de meilleurs logiciels, il faudrait former ce que certains appellent des artisans logiciels.

Enfin un autre point, l'amélioration continue (ou la remise en cause perpétuelle). Qu'il s'agisse de processus, de son propre travail ou de celui des voisins. Ayant cet objectif en tête, l'utilisation des techniques citées deviendra assurément une évidence, et permettra surement la création de nouvelles techniques.

[zeecrowddev]

Peux être plus simplement : Écouter ses utilisateurs :-)

Un bon logiciel est un logiciel qui plaît à ses utilisateurs quelque soit l'architecture, le langage, le design ...

Pour cela les méthodes agiles, le "Lean Startup" ....

Le plus souvent les développeurs (et j'en fait parti ) interprètent ce que leurs utilisateurs veulent et se réfugient vers ce qu'ils connaissent : La technique.

[Sodium]

Il faut avoir des gens compétents tout au long de la chaîne, c'est à dire aussi bien les développeurs que les commerciaux et l'utilisateur final.
Un client intelligent qui connait ses besoins, est capable d'apporter des informations précises quant au fonctionnement de son métier et les obstacles menant obligatoirement à des délais supplémentaire, ça augmente significativement la vitesse et la solidité du développement nécessaire tout en diminuant la quantité de développement inutile.

[Potomac]

Que faut-t-il faire pour avoir de meilleurs logiciels selon vous ?

- bannir les SSII qui poussent au low-cost et qui méprisent le métier de développeur, réduit à un simple ouvrier qu'on jette une fois le travail terminé

- sensibiliser le développeur sur l’intérêt des tests unitaires, étape souvent bâclée, surtout si on est dans une SSII lamentable

- un calendrier raisonnable et réaliste

- favoriser la licence open-source ( code source en libre accès ) pour une transparence absolue et un meilleur contrôle

[marc.collin]

de nombreux ouvrages sur le sujet existent... faut juste que les décideurs pressés les lis

[yahiko]

Que faut-il faire pour avoir de meilleurs topics ?

Plus sérieusement, sujet beaucoup trop vaste, vague et sans réponse unique et précise car énormément dépendante du contexte.
Selon le domaine, Web, scientifique, ERP, embarqué, jeux vidéo, etc, la signification peut être très variable.

Il y a tout au plus de "bonnes pratiques" qui elles aussi ont leurs limites, mais certainement pas un guide universel pour "bien programmer".

[mermich]

Pourtant c'est si facile:

Pour bien programmer il suffit de ne pas programmer, comme ca aucunes erreur CQFD.

[captaindidou]

Vous voulez du logiciel mature plus vite ?

Ce n'est pas compliqué. Misez sur des techno mûres et des développeurs d'expérience.

Faites du neuf avec du vieux.

Le développement logiciel est surtout affaire d'expérience et de méthode au même titre que n'importe quelle activité d'ingénierie.

Cependant, la tendance n'est pas à faire confiance à l'expérience.

[Excellion]

Pour un de mes profs de fac, un bon programme devait dans l'ordre être :
Robuste
Optimisé
Rapide
Fonctionner correctement
...

Ce serait bien que les développeurs d'aujourd'hui s'en inspirent.
Trop de branquignols se prenant pour des informaticiens oublient que la règle première d'un programme est de ne pas planter, et la seconde qu'il soit ecrit de la meilleure manière possible.

Ensuite, il ne faut pas oublier que tout part de la conception et donc du papier.
Sans une bonne conception, c'est 90% d'echec assuré.

Beaucoup trop de programmeurs se lancent à l'assaut d'un développement comme ils le feraient de l'Anapurna, avec le même résultat désastreux...

[theMonz31]

Pour avoir de meilleur logiciel, que faut-il faire ?

C'est simple... être meilleur...

alors, certains vont partir dans la direction de l'amélioration des processus (agile, TDD, autres)...

d'autres vont pointer la formation des développeurs, la reconnaissance, etc...

d'autres vont miser sur le temps, l'écoute, le partage...

d'autres vont miser sur la reconnaissance de l'expérience qui permet, normalement (mais pas toujours), d'obtenir de meilleurs choses plus on a l'habitude d'en faire...

-------------

Après, on tape sur les SSII.. mais finalement, la SSII n'est que la réponse a un besoin exprimé par un client...

Les SSSI aimeraient bien vendre des développeurs expérimentés à 500€/jours à leurs clients... sauf que le client (principalement les gros industriels plus que les petites boites) a tendance à croire que développer, c'est simple, facile, rapide et donc, "hurle" dès qu'on lui mets des tarifs élevés.. (d'ailleurs, souvent les entreprises "compensent" le TJM bas par plus de jours de prestations !!!

[BLeguillou]

Je retiendrai:


Misez sur des techno mûres et des développeurs d'expérience. Faites du neuf avec du vieux. (Captaindidou).

bannir les SSII qui poussent au low-cost et qui méprisent le métier de développeur, réduit à un simple ouvrier qu'on jette une fois le travail terminé
(Potomac).

Écouter ses utilisateurs (zeecrowddev)

Trop de branquignols se prenant pour des informaticiens oublient que la règle première d'un programme est de ne pas planter, et la seconde qu'il soit ecrit de la meilleure manière possible.
Sans une bonne conception, c'est 90% d'echec assuré. (Excellion)

Pour themonz31:
Les SSII tirent toujours des deux côtés: au client, elles facturent 500/j ou plus et au développeur, 100/j. Elles méprisent les développeurs. (pour info, j'ai 30 ans d'expérience et je les ai trop souvent fréquenté).

[super_navide]

Pour avoir de meilleur logiciels c simple.

Mieux documenter (outil UML , outil de documentation autre que word ou powerpoint , versionning de la documentation )
Mieux tester ( outil de test automatiques )

[gangsoleil]

Moui, à mon avis, il manque une donnée essentielle, c'est le temps.

Lorsqu'un projet est estimé à X jours, et que la décision des financiers est de le faire en X/2 ou X/3, c'est forcément au détriment de la qualité, indépendamment de tout ce qu'on peut imaginer comme méthodologie, outils, ou n'importe quoi d'autre.

[Washmid]

Pour un de mes profs de fac, un bon programme devait dans l'ordre être :
Robuste
Optimisé
Rapide
Fonctionner correctement
...

Personnellement j'aurais mis "maintenable" en haut de la liste (comprenez documenté, sans trop de code spaguetti, etc.)

Un logiciel maintenable mais pas très robuste, ça se renforce, pas de soucis.
Un logiciel robuste mais impossible à maintenir, c'est la poubelle direct à la moindre évolution importante.

Enfin bon c'est un point de vue

[Saverok]

Comme dit par d'autres, tout dépend de la définition de "meilleurs" car ce jugement de valeur est lié au contexte du logiciel :
- fréquence d'utilisation
- niveau de disponibilité requis
- volume de données manipulées
- pour quel(s) type(s) d'utilisateur (madame michu et/ou utilisateur spécifiquement formé pour ?)
- niveau de sécurité (appli accessible depuis l'extérieur du SI ? criticité des données ? etc)
- pour quel device(s) ?
- etc.
etc.

Bref, ce n'est que lorsque l'on a répondu à toutes ces questions (liste ci-dessus non exhaustive) que l'on peut qualifier son application et le niveau d'attention à apporter au soft à produire.
Glabalement, les critères sont tjrs les mêmes quelque soit le logiciel mais l'ordre de criticité diffère celons les besoins :
- maintenabilité
- robustesse
- sécurité
- performance
- IHM
- fonctionnalité

[salve34]

Vous voulez du logiciel mature plus vite ?

Ce n'est pas compliqué. Misez sur des techno mûres et des développeurs d'expérience.

Faites du neuf avec du vieux.

Le développement logiciel est surtout affaire d'expérience et de méthode au même titre que n'importe quelle activité d'ingénierie.

Cependant, la tendance n'est pas à faire confiance à l'expérience.

Ce n'est pas une histoire de confiance, c'est une histoire de sous.

[bruneltouopi]

Tres bonne idee.mais il faut surtout mettre en place une veritable strategie de test

[Logan Mauzaize]

Pour un de mes profs de fac, un bon programme devait dans l'ordre être :
Robuste
Optimisé
Rapide
Fonctionner correctement
...

Personnellement j'aurais mis "maintenable" en haut de la liste (comprenez documenté, sans trop de code spaguetti, etc.)

Etrangement j'aurais mis qu'il fonctionne ... sinon il ne sert à rien. Exemple :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

function helloWorld() { return "Good bye !" }

Trop de branquignols se prenant pour des informaticiens oublient que la règle première d'un programme est de ne pas planter

Non, non et encore non ! Une première chose à retenir "fail-fast" et "Let it crash".
Les programmes les moins stables ont été écrits dans cette philosophie. A force de vouloir essayer de récupérer ce qui ne peut l'être, on finit par corrompre ce qui fonctionne encore.

Trop de branquignols se prenant pour des informaticiens oublient que [...] la seconde [règle est] qu'il soit ecrit de la meilleure manière possible.

Un peu évident que pour faire des choses meilleures, il faut les faire de façon meilleure ...

Comme dit par d'autres, tout dépend de la définition de "meilleurs" car ce jugement de valeur est lié au contexte du logiciel :
- fréquence d'utilisation
- niveau de disponibilité requis
- volume de données manipulées
- pour quel(s) type(s) d'utilisateur (madame michu et/ou utilisateur spécifiquement formé pour ?)
- niveau de sécurité (appli accessible depuis l'extérieur du SI ? criticité des données ? etc)
- pour quel device(s) ?
- etc.

Est-ce que commencer par se poser ces questions n'est pas déjà un moyen de faire de meilleurs logiciels ?