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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Algorithmes et structures de données Discussion :

Le code est-t-il notre ennemi ?


Sujet :

Algorithmes et structures de données

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2014
    Messages : 194
    Points : 12 291
    Points
    12 291
    Par défaut Le code est-t-il notre ennemi ?
    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 ?

  2. #2
    Rédacteur/Modérateur

    Homme Profil pro
    Ingénieur qualité méthodes
    Inscrit en
    Décembre 2013
    Messages
    4 038
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur qualité méthodes
    Secteur : Conseil

    Informations forums :
    Inscription : Décembre 2013
    Messages : 4 038
    Points : 9 347
    Points
    9 347
    Par défaut
    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.
    N'oubliez pas le bouton Résolu si vous avez obtenu une réponse à votre question.

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 187
    Points : 434
    Points
    434
    Par défaut
    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.

  4. #4
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    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.
    One Web to rule them all

  5. #5
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    Août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : Août 2007
    Messages : 272
    Points : 526
    Points
    526
    Par défaut
    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.

  6. #6
    Membre expert
    Profil pro
    undef
    Inscrit en
    Février 2013
    Messages
    957
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : Février 2013
    Messages : 957
    Points : 3 523
    Points
    3 523
    Par défaut
    ç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.

  7. #7
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2006
    Messages
    5 239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2006
    Messages : 5 239
    Points : 19 100
    Points
    19 100
    Billets dans le blog
    17
    Par défaut
    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é...)
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  8. #8
    Expert confirmé
    Inscrit en
    Avril 2008
    Messages
    2 564
    Détails du profil
    Informations personnelles :
    Âge : 64

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 564
    Points : 4 441
    Points
    4 441
    Par défaut
    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...

  9. #9
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    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..

  10. #10
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    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.

  11. #11
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    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

  12. #12
    Invité
    Invité(e)
    Par défaut
    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.

  13. #13
    Membre régulier
    Inscrit en
    Mars 2002
    Messages
    53
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 53
    Points : 112
    Points
    112
    Par défaut
    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.

  14. #14
    Membre à l'essai
    Profil pro
    Inscrit en
    Août 2008
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 19
    Points : 14
    Points
    14
    Par défaut
    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...

  15. #15
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par LeFredd Voir le message
    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.

Discussions similaires

  1. [VB.Net 1.1/ASP.Net/Excel] Pourquoi mon exécution de code est si lente ?
    Par calison3 dans le forum Accès aux données
    Réponses: 2
    Dernier message: 12/08/2006, 13h41
  2. Ce code est-il compatible ?
    Par pablo8 dans le forum Mon site
    Réponses: 18
    Dernier message: 23/06/2006, 17h39
  3. [Dates] calcul de date est ce que mon code est bon?
    Par carmen256 dans le forum Langage
    Réponses: 2
    Dernier message: 09/06/2006, 12h30
  4. [MVC] Ce code est-il conforme?
    Par vallica dans le forum Servlets/JSP
    Réponses: 6
    Dernier message: 04/04/2006, 07h40
  5. new Option : ne marche pas quand le code est en alpha ???
    Par Leoxp dans le forum Général JavaScript
    Réponses: 4
    Dernier message: 19/12/2005, 16h23

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo