Discussion :

[Amine Horseman]

Notre but est-il d'écrire le moins de code possible ?
Pour un sénior, « L'écriture du code n'est pas la fonction première d'un développeur »

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 ?

[tbc92]

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.

[Washmid]

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.

[SylvainPV]

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.

[Bono_BX]

Ben perso, je ne voudrais pas voir le code de ce type, vu ce qu'il écrit ...

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

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.

Regardez vos outils et vos environnements, tous essaient de vous faire écrire moins de code.

FAUX : même chose, il n'a pas compris que le but des IDE n'est pas de nous faire écrire moins de code, mais de nous rendre plus productif. Même si ça passe souvent par écrire moins de code, la différence est réelle.

le code n’est pas si important que cela

Ben moi, il me semble qu'à la base, les applications sont faites avec du code, m'enfin j'peux me tromper

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

Si un jour ce type bosse avec un générateur de code, il se suicide ... de plus, des tests unitaires permettent d'avoir un code solide, robuste et bien architecturé (si on fait du TDD avec des mocks en particulier).

penser plus, refactoriser plus, et retirer du vieux code pour le remplacer par un nouveau qui soit plus court

Lapalissade pour un bon programmeur.

[23JFK]

ç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.

[imikado]

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é...)

[MABROUKI]

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...

[Mat.M]

bonsoir, voilà un bon débat pour la fin de l'année..

É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

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...

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..

[RyzenOC]

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.

[Saverok]

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

[Invité]

Bonjour

Pour moi un code lisible est un ensemble d'instruction immédiate !
J'écris comme je pense, je pense comme je conçois, je conçois ce que j'écris.
Après les truc trop remplis de math et de toute manière je suis pilote, pas mécaniciens. D'un certain point de vu.
J'ai des base de not or and xor if else case break loop mod etc, mais on ne peut ! Pas tout savoir à un instant quelconque !
Même si on à vue la globalité un fois, bon ben on l'a vu !

J'ai peur du code parce qu'a chaque mot c'est un choix qui m'éloigne d'une vérité. Coder c'est percevoir la moitié au mieux (en binaire) des choses.

[jv2759]

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.

[LeFredd]

Pour ma part je suis débutant mais j'ai quand même mon avis.

Je suis pour le fait de bien réfléchir d'abord à ce qu'on doit produire avant la moindre ligne de code. Ca passe bien entendu par l'uml, les diagrammes de classes, les fonctionnalités etc...

Ca permet déjà de poser les choses et ensuite on peut commencer à développer.

Maintenant écrire plus ou moins de code... , tant que celui-ci respecte certaines conventions (indentation, refactorisation, non duplication...) et soit bien documenté, qu'est ce que cela peut faire ? S'il est performant et répond aux fonctionnalités demandées ???

Moi j'aime comprendre ce que je fais, normal je suis débutant, donc ça ne me dérange pas de taper des lignes, au moins je comprend et je vois ce que je fais, pour le moment je n'aime pas les boites noires.

Par contre un truc qui m'exaspère à un plus haut point quand on est débutant, c'est le taux d'abstraction que prennent certains frameworks qui sont la soit disant pour nous faire gagner du temps alors qu'en fait on passe plus de temps la tête plongée dans la documentation, qui en plus est plus ou moins bien faite, que de développer Honnêtement ça ne m'intéresse qu'à moitié ce côté boite noire, résultat quand tu cherches à faire une fonctionnalité t'es bon à mourir sur la doc et sur les forums en espérant trouver une réponse. Alors qu'en te creusant un peu je suis sur que ce serait plus rapide et sympa de développer le truc seul.
Ok quand on est expérimenté c'est différent, je pense qu'on a pas envie de se retaper le dév de choses qui existe déjà et qu'on comprend. Dans ce cas si on a bien compris son cahier des charges, on peut aller taper dans ces framework, bundle etc...

[Saverok]

Par contre un truc qui m'exaspère à un plus haut point quand on est débutant, c'est le taux d'abstraction que prennent certains frameworks qui sont la soit disant pour nous faire gagner du temps alors qu'en fait on passe plus de temps la tête plongée dans la documentation, qui en plus est plus ou moins bien faite, que de développer Honnêtement ça ne m'intéresse qu'à moitié ce côté boite noire, résultat quand tu cherches à faire une fonctionnalité t'es bon à mourir sur la doc et sur les forums en espérant trouver une réponse. Alors qu'en te creusant un peu je suis sur que ce serait plus rapide et sympa de développer le truc seul.
Ok quand on est expérimenté c'est différent, je pense qu'on a pas envie de se retaper le dév de choses qui existe déjà et qu'on comprend. Dans ce cas si on a bien compris son cahier des charges, on peut aller taper dans ces framework, bundle etc...

Le hic est que tu n'acquières jamais d'expérience sur un framework si tu ne l'utilises pas et pour l'utiliser de façon optimale, il faut bien se plonger dans sa doc (et pas qu'une seule fois car on ne retient pas tout en une seule fois).

Réinventer la roue, c'est bien pour se former mais à un moment donné, faut se décider à utiliser les solutions standards, même si la doc est compliquée, et le plus tôt est le mieux.
Quand tu débutes dans la vie pro, tu as l'étiquette "débutant" qui te permet justement de passer du temps à comprendre certaines choses, y compris les frameworks.
A ce moment là de ta carrière, tu as le temps de prendre du temps pour lire la doc.
Puis, très rapidement, souvent trop vite même, cette étiquette disparaît et le niveau d'exigence augmente assez vite. On attend d'un développeur confirmé qu'il développe une fonctionnalité plus rapidement qu'un débutant et qu'il utilise les frameworks et si tu ne t'es pas servi de tes premiers pas en tant que pro pour t'y coller, bonjour les soirées à rattraper ce temps perdu.

La maîtrise d'un framework c'est comme tout, plus on l'utilise et plus on en acquière de la maîtrise.
L'expérience n'est pas juste une histoire de temps, c'est une question de pratique.