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 !

L'écriture du code est-elle la fonction première du travail du développeur ?
Pour un senior, « notre but est d'écrire le moins de code possible »

Le , par Amine Horseman

0PARTAGES

10  0 
L’une des premières choses qu’on apprend lorsqu’on veut devenir développeur c’est d’apprendre à programmer, et l’une des premières questions dont les apprentis se posent c’est sans doute « quel est le meilleur langage de programmation pour commencer mon apprentissage ? ».

Selon, Mike Grouchy, blogueur et contributeur à pycoders, tous les débutants tombent dans le piège de croire que l’écriture du code est la fonction première du travail d’un développeur. « Ecrire du code est une chose puissante […] vous vous sentez comme productif. Cependant, ce que j’ai appris au fil des années, c’est que le travail d'un développeur de logiciels est d'écrire le moins de code possible ».

Cela peut sembler contradictoire aux premiers abords, mais dans la suite de son billet de blog, Mike explique qu’écrire moins de code ne veut pas dire minimiser le nombre de caractères au point où le code produit devient illisible, mais plutôt trouver le juste milieu entre un code long et difficile à maintenir plus tard et un code court et complètement indéchiffrable.

« Regardez vos outils et vos environnements, tous essaient de vous faire écrire moins de code. Votre travail est de penser, votre travail consiste à réfléchir sur le problème à portée de main, concevoir une solution élégante et puis convertir cette solution en logiciel », déclare Mike, avant de rappeler que l’écriture du code n’est qu’une des nombreuses étapes de la création de logiciels.

Il affirme ensuite que « le code n’est pas si important que cela […] Certes le code est génial, mais c’est aussi un ennemi. Il faut du temps pour l’écrire, il peut être fragile, il peut ne pas être clair et ne pas être particulièrement robuste ». L'écriture du code peut donc être fastidieuse et poser beaucoup de problèmes.

Toutefois, Mike est conscient qu’on ne peut pas supprimer cette étape, essentielle, lors d’un projet informatique. D’ailleurs, ce n’est pas le but de son mantra qui appelle à « écrire moins de code ». Son objectif c’est de rester concentré pour écrire un code plus court et plus clair. Pour cela, il nous appelle à « penser plus, refactoriser plus, et retirer du vieux code pour le remplacer par un nouveau qui soit plus court ».

Source : Article de Mike Grouchy sur Medium

L’écriture du code est-elle la fonction première du travail d’un développeur ? Pour un senior, « notre but est d’écrire le moins de code possible »
Et vous ?

Êtes-vous d’accord avec Mike Grouchy ?

Écrire moins de code serait-elle la solution pour un code plus lisible ?

Quels conseils donneriez-vous pour avoir un code plus lisible ?

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

Avatar de tbc92
Rédacteur/Modérateur https://www.developpez.com
Le 23/12/2014 à 20:56
Bonsoir,
Le code est-il notre ennemi ? NON.

Autant je suis d'accord à 99% avec le contenu de l'article, autant je trouve que le titre n'est pas du tout fidèle à l'article lui-même.

Le code n'est pas le seul élément du développement, mais c'est un élément important, incontournable. Il ne faut pas le considérer comme un ennemi, mais comme un partenaire parmi d'autres.

Il y a un point que je formulerais différemment.

D’ailleurs ce n’est pas le but de son mantra qui appelle à « écrire moins de code ». Son objectif c’est de rester concentré pour écrire un code plus court et plus clair.
Un code clair, oui, ok, rien à redire.
Ca paraît une lapalissade, mais il faut le dire et le redire.
Surtout que ce qui paraît clair le jour J, quand on est en plein dans le projet, peut paraître totalement incompréhensible 1 an plus tard.

Et encode plus incompréhensible quand, un an plus tard, c'est un autre programmeur qui devra faire évoluer le produit.

Un code court, c'est moins évident.
J'insisterais plus sur les redondances. Quand il y a 20 lignes de codes qui sont communes entre la procédure A et la procédure B, oui, il faut créer une procédure qui exécute ces 20 lignes de codes.

Il faut factoriser, pour reprendre le verbe de l'article ; je dirais même que l'ennemi du programmeur, ce n'est pas le code, mais c'est l'outil 'Copier/coller'.

Mais si une procédure est claire et lisible, avec 20 lignes de codes, vouloir réduire cette procédure à 15 lignes, en y mettant des if fct(i++,j--) > 0 ... pas d'accord.
3  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 24/12/2014 à 12:36
Citation Envoyé par tbc92 Voir le message
l'ennemi du programmeur, ce n'est pas le code, mais c'est l'outil 'Copier/coller'.
Bien d'accord ! Presque tous les refactoring ont pour cause un ou plusieurs CTRL+C/CTRL+V vite faits mal faits

Concernant le fait d'écrire le moins de code possible, j'imagine qu'il parle en nombre d'instructions et pas en nombre de caractères. Bien que jouer au golf soit amusant, il est clair que ça n'a rien de productif et de maintenable.
2  0 
Avatar de Washmid
Membre averti https://www.developpez.com
Le 24/12/2014 à 12:10
Pour écrire un code plus lisible ?

Je dirais se poser une petite alerte dans sa tête :

Je copie colle 2 ou 3 lignes ? je crée une méthode de 10-20 ligne ? J'ai une classe de 500-1000 lignes ?

---> Est-ce réellement justifié ? (code généré, contraintes de références ou technique, etc.)
N'y a-t-il pas moyen de faire autrement sans sacrifier en clarté ?

Et au delà de ces limites (4 lignes identiques dupliquées, 20+ lignes par méthode et 1000+ ligne par classe), sans un énorme pavé de commentaire justifiant la conception c'est un travail à revoir qui va un jour où l'autre causer une régression.
0  0 
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 24/12/2014 à 18:28
ça me rappelle l'histoire de ce développeur américain très bien payé parce son code était très apprécié mais dont il s'est avéré lors d'un audit de sécurité qu'il sous-traitait en fait son job à une société chinoise pour un tiers de son salaire.
0  0 
Avatar de imikado
Rédacteur https://www.developpez.com
Le 26/12/2014 à 8:52
Autant je suis d'accord, qu'avec le temps on apprend à prendre du recul avant de coder: essayer de plus investir de temps à la conception avant de retrousser ses manches, autant je n'aime pas l'affirmation "le code est votre enemi"

Le code, c'est le produit final, il faut l'aimer/l'apprécier et l'écrire avec plaisir, sinon il lui faut changer de métier ou de technologie

Commit strip avait publié une bd où l'on voyait des codeurs s'extasier devant un code bien commenté/indenté...
Le code, c'est le restultat final de votre reflexion, c'est lui qui va travailler/ faire s'afficher votre application avec (si gui) son interface plus ou moins bien pensé.
Un bon code peut permettre d'avoir une application plus légère, agréable à utiliser , elle peut aussi ravir l'équipe qui la maintient (bien documenté, bien refactorisé...)
0  0 
Avatar de MABROUKI
Membre expert https://www.developpez.com
Le 27/12/2014 à 21:08
bonjour

En fait ce que veux dire ce "gus" dans son blog est à lire entre les lignes :
-le dernier obstacle dans la mise au point d'un logiciel c'est bien le "sale virage" de l'ecriture du code,de l'api à disposition ,de l'edi et des tests...
Vu sous cette optique sombre ,il y a de quoi ne pas ecrire de code du tout et le faire sous-traiter en Inde...
0  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 27/12/2014 à 22:16
bonsoir, voilà un bon débat pour la fin de l'année..

Citation Envoyé par Amine Horseman Voir le message
Écrire moins de code serait-elle la solution pour un code plus lisible ?
ça parait idiot mais moins on écrit de code moins il y a de bugs potentiels
donc oui il faut trouver le bon compromis et une taille optimale du code source.
Refactoriser n'est pas toujours facile...on ne va pas refaire le débat sur l'usage des copier-coller
Ceci dit étant donné qu'on utilise de plus en plus de frameworks, bibliothèques voire d'ERP la tendance est à écrire le moins de code possible..
« Regardez vos outils et vos environnements, tous essaient de vous faire écrire moins de code.
c'est le but d'outils comme Resharper pour .NET notamment

Citation Envoyé par Bono_BX Voir le message

FAUX : ce qui est important, c'est de factoriser son code. Comme dit dans de nombreux autres commentaires, le copier-coller de code, c'est le mal. Si tu écris beaucoup de code correct, bien factoriser et organisé, tu vas couvrir un plus grand périmètre donc tu seras plus productif. Le but n'est pas d'écrire moins de code, mais moins de code sale et inutile.
salut ce que tu écris je l'ai écris dans d'autres fils de discussion et je suis largement d'accord avec toi..

de toute façon on devrait apprendre à n'importe qui qui commence à programmer de comprendre l'architecture d'un projet informatique, ceci avant d'écrire la moindre ligne de code et puis également les méthodes de développement...

je vais pas me répèter mais j'ai vu des projets de développements dont un récent qu'on pourrait qualifier de "titanic" à cause de code mal structuré, mal factorisé et mal architecturé..donc derrière une maintenance très lourde comme l'écrit l'auteur du blog

quand aux copier-coller il y a tout un fil de discussion mais ça mène un projet à la catastrophe...

un code peut être parfaitement lisible mais très mal factorisé comme tu l'écris si bien.
De toute façon écrire des commentaires, faire un code lisibile ça fait partie des tautologies de la programmation
Factoriser du code , architecturer là c'est plus diffcile à faire...
Citation Envoyé par SylvainPV Voir le message
Bien d'accord ! Presque tous les refactoring ont pour cause un ou plusieurs CTRL+C/CTRL+V vite faits mal faits
.
malheureusement ça semble être le cas de nombreux projets professionnels....
et faire du "refactoring" eh bien au final ça coûte cher à l'entreprise parce qu'il faut passer du temps à refaire des parties de code..
0  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 28/12/2014 à 17:38
Pour moi la priorité c'est :
Un code qui bug pas, qui fait ce qu'on lui ordonne
Un code claire
Un code optimiser si nécessaire (si c'est pour gagner 30 secondes oui, 0.2 seconde non).
Et enfin un code le plus court possible.

Je préfère faire un programme de 2000 lignes de code simple plutôt que 500 lignes qui ne veulent rien dire.
0  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 29/12/2014 à 11:31
Mike Grouchy ne fait que rappeler la base du développement : la factorisation
Il publie un article super long pour ne pas dire grand chose finalement

Comme dit par d'autres, les 2 plus grandes qualité d'un code sont sa clarté et sa maintenabilité
Avoir un code convenablement factorisé est indispensable pour atteindre ces 2 objectifs

On ne juge pas la productivité d'un développeur au nombre de lignes de code écrites mais au nombre de fonctionnalités (en tenant compte de la complexité de celles-ci, bien évidemment), ce qui fait une grande différence
0  0 
Avatar de jv2759
Membre régulier https://www.developpez.com
Le 05/01/2015 à 13:40
Je pense qu'il faut bien regarder la cible. "L’une des premières choses qu’on apprend", "les apprentis", "les débutants".

J'ai eu l'occasion de travailler avec des personnes fraichement sorties des cartons écoles, et en effet ce que l'on constate c'est que la première chose qu'ils cherchent à faire c'est à coder. Ou à pisser du code devrais-je plutôt dire. Il cherche à utiliser telle quel le peux d'outils qu'ils ont appris sans vraiment réfléchir, ils cherchent à appliquer avant de savoir pourquoi ils utilisent cela.

Donc oui je suis d'accord, penser que le code est notre but est une grave erreur.
0  0