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, Chroniqueur Actualités
Votre avis
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de pierreact 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.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 16/06/2017 à 10:10
Moi qui ai toujours cru que je codais lentement vis-à-vis des perfs des autres...
Un bon RAD (plein d'affinités et intuitifs) et voilà que les choses changes.

Durée de vie du RAD estimé a combien d'année sur le marché du travail ?

(Windev, RAD Studio, ...) C'est bien sa le problème de la demande... Le second n'y est vraiment pas souvent, alors ses ancêtres...
Avatar de Cincinnatus Cincinnatus - Membre confirmé 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
.
Avatar de John Bournet John Bournet - Membre habitué 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.
Avatar de clorr clorr - Membre à l'essai 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
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 16/06/2017 à 12:48
C'est un peu la notion de culture générale en matière d'algorithmique, selon les précédents commentaires.
Pas faux aussi... Utilisation de framework et librairies tierces ou pas étant là encore ce qui peut faire la différence...
Avatar de Orionos 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.
Avatar de Songbird_ Songbird_ - Rédacteur/Modérateur https://www.developpez.com
le 16/06/2017 à 17:14


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.
Je fais à peu près la même chose. Soit je laisse ça sur une feuille, quand ce sont des petits projets personnels, soit j'intègre ma feuille de route directement dans mon bug tracker et je lis chaque issue à un ou plusieurs commits lorsque je commence à coder, pour les retrouver facilement par la suite.

Sinon pour noter les spécificités de son programme, il y a Cucumber qui a l'air d'être vraiment pratique. Je ne l'ai pas encore utilisé donc je ne connais pas ses limites, mais ça me tente bien.
Avatar de Excellion Excellion - Membre actif https://www.developpez.com
le 16/06/2017 à 21:39
Massacrer le clavier, copier-coller. Massacrer le clavier, copier-coller. Copier-coller, copier-coller, copier-coller, massacrer le clavier...

Compiler.

Merde ça marche pas... 🤣

Patcher. Compiler. Patcher. Compiler. Publier.

"Alors, maintenant on va faire une petite modif. Rien, hein! Ça prendra 5 minutes. Il faut juste changer ça, et rajouter ça. Ho, et puis ça, finalement, ce n'est plus utile. C'est bon ? Je reviens dans 5 minutes...." 🤣
Avatar de CodeurPlusPlus CodeurPlusPlus - Membre chevronné https://www.developpez.com
le 16/06/2017 à 21:55
Il ne faut coder ni trop vite ni trop lentement, réfléchir suffisamment sans devenir contre-productif, et se rappeler que, quoi que l'on fasse, il y a toujours quelqu'un qui code à la fois plus vite et mieux que soi.

Voilà, j'ai fait plaisir à tout le monde en énumérant des banalités ?
Offres d'emploi IT
Scrum master
GROUPE KEYRUS - Ile de France - Levallois-Perret (92300)
Développeur confirmé Access 97
JobOuaga - France - Ouagadougou (Burkina Faso)
Développeur d'application web F/H
Link-consulting - Midi Pyrénées - Rodez (12000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil