IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Trolldi : pourquoi coder lentement c'est coder plus vite,
Mais aucun développeur ne peut le faire dans la réalité

Le , par Michael Guilloux

285PARTAGES

25  0 
Votre avis
En voulant coder vite, on perd toujours plus de temps à corriger ses erreurs
65 %
Aller lentement sera interprété comme de la paresse ou de la sous-performance
52 %
Un développeur rapide est vu comme un développeur motivé
43 %
Les développeurs ne sont jamais assez rapides pour le management
41 %
La norme c'est de livrer rapidement, des patchs suivront pour corriger les bogues
30 %
Il faut d'abord convaincre le management
20 %
Autre (à préciser)
2 %
Pas d'avis
4 %
Voter 54 votants
En tant que développeur, vous avez certainement déjà senti la nécessité de coder rapidement. Le plus souvent, cela se produit lorsque les délais sont très serrés et que vous sentez que vous ne serez pas en mesure de fournir un livrable attendu à temps. Mais parfois, ce comportement peut s’avérer très coûteux.

C’est le cas par exemple si la pression d’aller vite vous amène à sous-estimer le travail à faire ou à mal l’évaluer, ne pas respecter la conception, les règles de codage, etc. Une complexité cachée découverte plus tard vous conduit alors à revenir en arrière. Ainsi, la volonté d'aller plus vite vous aura tout simplement fait prendre du retard.

À l'inverse, vous arrivez à terminer le projet dans les délais, mais avec une forte dette technique. Il faut en effet rappeler que dans un projet, la qualité augmente la charge de travail, ce qui peut avoir un impact sur le délai immédiat. Ainsi, lors de la survenue imminente d'une nouvelle version d'un logiciel par exemple, respecter la conception idéale peut mettre en péril la livraison d'une nouvelle version du logiciel. À ce moment précis, ne pas respecter la conception idéale peut permettre d'atteindre l'objectif prioritaire à court terme (sortir une nouvelle version), mais vous contractez une dette technique que vous allez rembourser tout au long de la vie du produit sous forme de temps de développement de plus en plus long et de bogues de plus en plus fréquents.

La solution serait donc d’aller lentement mais sûrement ? Une chose est sure, cela va permettre d’éviter les pièges ou limiter les erreurs. Dans un billet de blog sur Programmerfu.com, Garrett Lancaster, créateur d'une application SaaS, essaie d'ailleurs d'expliquer qu'en programmation, « aller lentement, c'est aller plus vite », ce que beaucoup d'entre nous ne mettront peut-être pas en doute. Il faut donc « ralentir pour être un programmeur meilleur et plus heureux », a-t-il suggéré dans une discussion sur Reddit.

Il explique que cela ne sera pas seulement bénéfique pour le développeur lui-même, mais aussi pour les autres développeurs qui auront à travailler sur son code, que ça soit pour ajouter de nouvelles fonctionnalités ou pour le maintenir. Il n’est en effet pas nécessaire de rappeler comment cela peut être pénible de travailler sur un code de mauvaise qualité, et en plus écrit par une autre personne. Mais dans la réalité, vu les contraintes extérieures, la suggestion de Garrett Lancaster est-elle applicable ? Cela s'aligne-t-il avec la vision de l’entreprise et du management ? C'est sur ce point que la suggestion de Garrett Lancaster a été débattue.

Le fait est que le plus souvent, c’est l’entreprise et le management qui créent un environnement sous pression avec des délais très serrés obligeant les équipes de développeurs à essayer d’aller le plus vite possible. Il faut donc avant tout les persuader que cette manière de travailler peut affecter la qualité du code et pourrait nécessiter plus de travail plus tard. Pour un développeur qui essaie d’aller lentement pour éviter de commettre des erreurs graves, comment sera-t-il perçu par son manager ou son entreprise ? Comme quelqu’un de paresseux, sous-performant, non motivé ?

Et vous ?

Qu'en pensez-vous ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de pierreact
Membre du Club https://www.developpez.com
Le 16/06/2017 à 10:07
Informatique: On a le temps de faire mal 3 fois mais on a pas le temps de faire bien 1 fois.
12  0 
Avatar de Cincinnatus
Membre expérimenté https://www.developpez.com
Le 16/06/2017 à 10:25
Il ne s'agit pas de coder lentement, même si Garrett Lancaster parle de "taper lentement". Il s'agit d'abord de ne pas se précipiter, et comme il l'écrit également, de rassembler un maximum d'informations avant de planifier et se concentrer (sans interruptions extérieures).
En fait, réfléchir avant d'agir.
Effectivement, c'est parfois possible, mais pas dans tous les environnements de travail, malheureusement.

C'est cependant du bon sens, que je rapprocherais de DDD : Domain-Driven Design : on étudie le problème en large et en travers avant de concevoir et avant de programmer. ça semble un peu contradictoire avec TDD par contre
.
7  0 
Avatar de jovanovic.radoslav
Membre à l'essai https://www.developpez.com
Le 23/06/2017 à 17:38
je programme depuis 30 ans. Je regarde la façon de faire des jeunes loups. Sans avoir lu le sujet jusqu'au bout il commence à coder, son but : fournir un exe le plus vite possible. Oui il doit montrer au chef qu'il peut le faire. Et il le fait. bon c'est un peu bancale, y'a des bout de ficelle partout, y'a qu'une fonction, bon elle a 5000 lignes; mais il en en fière, ça marche !!! Et quand je lui dit que je préfère de loin un code bien écrit et qui ne marche pas à un code qui marche mais mal écrit, il ne comprend pas. Mais six mois plus tard, quand il doit modifier son code dont il était assez fière, je le vois s'arracher les cheveux c'est la qu'il comprend la nécessité de découper son code en de nombreuses fonctions et de bien lire le cahier des charges. Comme le dit le proverbe c'est en forgeant que l'on devient forgeron. Il faut du temps pour devenir un pro. Quand devient on pro ? Quand on a compris que l'important en programmation n'est pas un exe qui marche ni un minimum de temps pour le faire mais un code que même un débutant peu comprendre et modifier, quand le code écrit est votre fierté et non l'exe, quand vous avez compris que vous êtes capable de faire. Alors il ne vous reste plus qu' à bien faire et la vitesse viendra d'elle-même.
5  0 
Avatar de clorr
Membre averti https://www.developpez.com
Le 16/06/2017 à 12:00
D'accord avec Cincinnatus, il ne s'agit pas de coder "lentement" mais de ne pas se precipiter vers la 1e intuition venue et se retrouver dans une voie sans issue.

Après, il est difficile de trouver un compromis évident entre "se précipiter" et "prévoir tous les risques auxquels on pourrait être confronté", surtout que dans le 2e cas, on peut passer longtemps a ne rien faire et finir par se décourager.

Personnellement, j'essaie avant tout de modulariser l'application de manière a limiter la complexité unitaire de chaque module. Avec un bon découpage de modules et des contrats clairs entre modules, on peut se permettre de coder "vite fait, bien fait" à l'intérieur des modules car la dette technique restera circonscrite et facilement addressable par la suite
4  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 16/06/2017 à 23:41
Je suis croyant pratiquant du "rien ne sert de courir, il faut partir à point".

Je considère que du code doit, in fine, toujours être bien fait. Si urgence il y a, il faut le faire vite en prévoyant d'y revenir nécessairement plus tard, même si on pense l'avoir bien fait du premier coup. Il faut donc chiffrer le travail en partant du principe qu'on prendra le temps de le faire, puis y ajouter les frais supplémentaires pour fournir une version vite fait d'abord. Voilà comment je le conçois : soit c'est bien fait, soit c'est d'abord vite fait puis bien fait.
4  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 17/06/2017 à 17:22
Citation Envoyé par foetus Voir le message
Si je code lentement, c'est parce que je développe en "eXtrem Programming"
L'eXtreme Programming se base sur les principes suivants :
  • Le développement itératif. C'est ce que tu viens de décrire dans ton message.
  • Le développement piloté par les tests (Test Driven Development) : on écrit les tests unitaires d'abord et on code la fonctionnalité ensuite. A court terme, c'est plus long que ne pas écrire de tests unitaires. A long terme, on détecte vite les régressions.
  • Le binômage (pair programming) : deux développeurs par PC ! Il y en a un qui code et l'autre qui surveille les erreurs et propose des alternatives.
  • Les binômes changent régulièrement de façon à ce que tout le monde connaisse un peu tout le programme. Ainsi, lors d'une itération, si la plupart des demandes se concentrent sur la même portion du programme, au lieu que seul le spécialiste de cette portion travaille dessus, une plus grosse partie de l'équipe peut intervenir.


C'est étrange que ton message focalise la lenteur à court terme sur le développement itératif alors que c'est surtout le binômage qui ralentit le plus à court terme. Développes-tu vraiment en eXtrem Programming ?

Citation Envoyé par Damoy Voir le message
en faisant des erreurs, on apprend, et en apprenant les fois prochaines on sera beaucoup plus efficace, coder lentement c'est perdre son temps
Dans le contexte de l'article, l'expression coder lentement est trompeuse car, sémantiquement, elle suggère qu'il s'agit de réaliser les même tâches que coder rapidement, de manière moins rapide et plus soigneuse, alors qu'il s'agit en fait de réaliser plus de tâches.

Pour ajouter des fonctionnalités à un programme, un développeur qui travaille correctement ne fait pas que coder ce qui sera visible le jour de la livraison, et il ne fait pas que coder tout court. En effet, il faut penser aux tâches suivantes (la liste n'est pas exhaustive) :
  • L'analyse du besoin. Quand le supérieur demande d'ajouter une fonctionnalité qui semble étrange, il faut demander quel est le besoin derrière au lieu de répondre "OK." et de foncer tête baissée dans le code. Parce que peut-être qu'il faudrait coder autre chose voire même qu'il n'y a pas besoin de changer le code.
  • La factorisation du code entre plusieurs applications. Au lieu que chaque équipe de développement réinvente la roue carrée dans son coin pour son projet à elle, il faut discuter entre équipes pour mettre du code en commun. Ainsi, quand on corrige un bogue ou quand on ajoute une fonctionnalité dans le code commun, c'est effectif chez tout le monde.
  • La documentation. Cela permet d'éviter que, quand un développeur quitte la boîte, les connaissances indispensables au bon déroulement du projet disparaissent avec lui.
  • Le traitement des erreurs. Par exemple, au lieu de supposer que tous les fichiers en entrée sont au bon format et laisser le programme crasher lamentablement quand le format est incorrect, il faut construire un message d'erreur avec l'adresse du fichier et en quoi son contenu est incorrect. De même, quand une sauvegarde échoue, il faut afficher un message d'erreur pour avertir qu'elle a échouée au lieu de laisser l'utilisateur croire que tout va bien puis appeler le help desk quelques jours plus tard.
  • Le programme doit aussi écrire un fichier de log qui décrit les actions des utilisateurs et les erreurs détectées. C'est parfois indispensable pour analyser des problèmes quand un utilisateur appelle le help desk.
  • Les tests unitaires. C'est pour détecter plus facilement les régressions.

Quand un développeur fait tout ce travail, la hiérarchie peut avoir l'impression qu'il "code lentement" dans le sens où le code est "fini" plus tard. Mais, en réalité, il code plus de choses (par exemple, il traite les erreurs) et il fait aussi du travail qui ne consiste pas à écrire du code (par exemple, il documente).
Dans certaines boîtes, pour la hiérarchie, un développeur qui "code vite" est en fait un développeur qui ne fait que la moitié du travail et laisse une grosse dette technique. Mais la hiérarchie a l'impression qu'il a fait tout le travail car elle ne voit pas tout le suite les conséquences de cette dette technique.
4  0 
Avatar de
https://www.developpez.com
Le 16/06/2017 à 10:38
Je suis globalement d'accord avec le billet, mais je pense qu'il manque une variable essentielle : quel est le surcoût de la qualité ?

S'il est exagéré (procédures délirantes), alors oui, les développeurs seront tentés de s'en passer pour gagner du temps.
Si on trouve un juste milieu, alors cela devient dérisoire. Sauf projet microscopique, quand on développe on passe plus de temps à réfléchir à comment coder les choses, comment les agencer, comment les afficher, comprendre le besoin utilisateur précis, qu'à écrire du code (propre ou non). C'est pour cela que la surcouche "qualité" peut devenir négligeable en temps : les normes de codage, l'organisation "intelligente" du code, les tests unitaires, les interfaces, les commentaires, la doc, ... tout cela n'est que du déroulage, lorsqu'on est un minimum rodé, et peut donc se faire rapidement.
2  0 
Avatar de Orionos
Membre habitué https://www.developpez.com
Le 16/06/2017 à 16:40
Les problématique sont différentes selon les outils utilisés. Par exemple, si on fait une faute de frappe et que le projet met 10 minutes à build, alors oui il vaut mieux bien se relire et pas taper sur le clavier comme un décérébré. Perso, en Delphi a peu près n'importe quoi compile en un claquement de doigt. A tel point que je compile parfois juste pour mettre le curseur la ou je m'étais arrêté au milieu d'une ligne

Pour ce qui est de l'organisation de son temps, j’essaie une "nouvelle" technique.
Pour ne pas partir à droite à gauche j'ai une feuille de route de mon dev. C'est simplement une liste des choses que je sais à l'avance que je vais devoir faire. Chaque élément de la liste occupe entre 5 minutes et 4 heures.
Après le but c'est de s'y tenir, dans l'ordre, et sans déborder.

Ça m'aide à rester concentrer, et à ne rien oublier.
2  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 17/06/2017 à 12:24
Coder lentement ne veut pas dire ne pas faire d'erreur. D'ailleurs, il ne s'agit pas simplement de coder lentement ou rapidement, qui ne veut rien dire en soit, mais de choisir entre prendre le temps de concevoir complètement avant de coder ou de se lancer dans le code tout de suite en concevant la solution à la volée. Les erreurs sont toujours possibles, dans les deux cas, mais la seconde pratique tant à faire du code qui sera jeté plus tard. Si le projet dure longtemps, les dépendances à ce code jetable s'agrémentant, il finira par devenir à la fois nécessaire à jeter mais impossible à jeter, mettant l'équipe dans l'embarras car il faudra non seulement refaire ce bout là mais aussi tous ceux qui en dépendent, et ainsi de suite.
2  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 18/06/2017 à 12:17
Je suis aussi un croyant pratiquant du "tout vient à point à qui sait attendre". Le truc, c'est que ça ne dit pas "à qui attend" mais "à qui sait attendre". Il s'agit d'une patience raisonnée, pas d'attendre que les autres fassent le boulot à ta place. Il faut du temps pour que certaines choses bougent, ou que des opportunités se manifestent. Le tout étant de se focaliser sur ce qui augmente tes chances d'obtenir ces opportunités plutôt que d'essayer de forcer la main. Il y a une inertie dans tout, et ça aussi il faut en être conscient et l'exploiter.
2  0