Quel est le meilleur conseil quand on programme ?

Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux


 Discussion forum

Le , par mitkl, Rédacteur
Le site Internet InformIT est un train de réaliser une série intéressante d'articles basée sur le même thème : Quel est le meilleur conseil que vous ayez reçu ?

Ainsi, plusieurs experts venant de différents horizons ont été conviés à répondre à cette question, voici un rapide résumé :

  • Erik Buck Erik Buck est un développeur iOS auteur de quelques livres sur ce domaine. Pour lui, le meilleur conseil tient en trois mots : "write less code" ou "Écrire moins de code" pour rendre une source plus simple et plus facile à maintenir.
  • Obie Fernandez Obie Fernandez est un développeur de Ruby et Ruby On Rails et auteur aussi de livres sur ces deux technologies. Son conseil : toujours prendre le temps de réfléchir quand on a une erreur avant de rajouter du code supplémentaire.
  • Danny Kalev Danny Kalev est un développeur C++ expérimenté, il est auteur de livre et a aussi participé au comité de standardisation du C++. Pour Danny Kalev, il faut lire des livres, lire des magazines, apprendre encore et toujours de nouvelles techniques. Il conclut avec cette phrase : "read much more than you write" ou "Lisez plus que vous ne codez".
  • Eric Lippert Eric Lippert est un développeur C# qui a travaillé chez Microsoft. Son avis : pour devenir meilleur, participer sur des forums ou des groupes de discussions en aidant ceux qui ont des questions, si vous avez la réponse, dites là, si vous ne l'avez pas, rechercher sa réponse sur Internet.
  • Mark Summerfield Mark Summerfield est un développeur et a écrit un livre sur le langage Go. Il n'a pas un mais deux conseils à adresser. Le premier : refactoriser son code rejoignant un peu l'idée d'Erik Buck de rendre le code plus facile à comprendre et donc à maintenir. Le deuxième : écrire des tests unitaires pour son code avant de l'intégrer au projet.
  • Bill Wagner Bill Wagner est auteur de livre sur le langage C#. Son conseil : d'abord rendre son code fonctionnel avant de vouloir l'améliorer ! Ça peut paraitre stupide mais il faut toujours garder cela en tête !


Source : The Best Programming Advice I Ever Got

Et vous ?

Avec qui êtes-vous le plus d'accord ?
Quel est le meilleur conseil que vous ayez reçu ?
Pour vous, quel est le meilleur conseil que l'on peut donner ?


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


 Poster une réponse

Avatar de DonQuiche DonQuiche
http://www.developpez.com
Expert Confirmé
le 08/05/2014 17:31
Citation Envoyé par pomauguet  Voir le message
C'est un peu radical de ne pas mettre de commentaire , mais je plussoie sur l'idée derrière ta règle.

En fait tu as de plus en plus de gens qui soutiennent cette idée.

Les arguments principaux en faveur de l'abandon en général des commentaires (sauf exception) sont :
a) 95% des commentaires systématiques (JavaDoc/XmlDoc) sont inutiles (ClientAccount clientAccount : the client's account).

b) 95% des commentaires sont avantageusement remplacés par de bons choix de noms et une fine granularité (méthodes courtes ne faisant qu'une seule chose - celle indiquée par le nom - et classes à responsabilité unique).

c) Les IDE modernes avec leurs outils de navigation dans le code (surtout pour typage statique) ont contribué à rendre obsolètes un nombre toujours croissant de commentaires.

d) Les longs commentaires (notamment JavaDoc et XmlDoc) nuisent à la lisibilité du code.

e) Comme tout artefact de documentation, les commentaires tendent à devenir obsolètes et source de désinformation.

f) A budget équivalent d'autres dépenses sont plus judicieuses : programmation par paire, revues de code, effort sur les tests, ou autres artefacts de documentation (diagrammes par exemple).

g) Métriques à l'appui, les commentaires sont rarement lus, surtout si le code est bien écrit.

En pratique, sur une équipe de taille raisonnable, je n'ai vu que des avantages après l'abandon des commentaires.

Ce que je trouve peu intéressant en fait à l'usage, c'est de faire une conception UML sur un outil. Pour ma part, il me suffit d'un crayon et d'un papier pour faire une première esquisse. Puis je code (en commençant par les fonctions de plus haut niveau, qui me permet de me concentrer sur le Quoi plutôt que sur le Comment), et j'itère jusqu'à ce que ça me convienne.
Quand j'ai dû utiliser un outil comme Rose, je suis toujours tombé sur des modèles qui n'étaient pas à jour. Modifier une conception devient une tâche lourde de gestion de projet. La conception ne devrait être que le reflet du code, d'où mes doutes sur ce genre d'outil.

Ah ! UML ! Une très bonne idée au départ sauf qu'on a voulu en faire tout et n'importe quoi, en particulier un support pour les documents contractuels, un outil de validation et un générateur de code. Et l'agnosticisme codifié dans le marbre atteint vite ses limites. Au final c'est un mauvais outil pour la conception, les éditeurs sont beaucoup trop lourdingues, moches (ça compte pour la créativité) et rigides, et cette norme n'est même pas un bon outil de communication. Bref, un méfait de plus de la bureaucratie.

Par ailleurs les problèmes les plus complexes à mon avis relèvent de toute façon davantage de la bonne façon de traiter de l'information, de la faire circuler et d'en disposer au bon moment. Alors que le choix d'un bon découpage des classes est plutôt simple avec de l'expérience, et même le plus souvent automatique. Donc aucun diagramme de classe ne m'aidera, ce n'est qu'un outil de communication à mes yeux. En termes d'aide à la conception je ne vois que les diagrammes libres pour illustrer des exemples, des cas particuliers ou des algorithmes, voire un diagramme de séquence dans les cas parallèles/asynchrones (mais j'évite de suivre fidèlement les conventions UML en la matière, trop lourdingues).

Du coup j'utilise Visio ou draw.io pour les diagrammes libres et les diagrammes de séquence. De toute façon la synchronisation avec le code est toujours médiocre pour les diagrammes de séquence et je n'ai trouvé aucun bon éditeur. Concernant les diagrammes de classe je tape directement l'esquisse du code et je laisse VS générer automatiquement les diagrammes plutôt que de chercher à travailler en UML.

Quoiqu'il en, soit, le jour où un bon éditeur apparaîtra, je sais qu'il aura un rapport flexible avec UML et ne cherchera pas à faire le café et le repassage en même temps.
Avatar de sevyc64 sevyc64
http://www.developpez.com
Modérateur
le 08/05/2014 18:52
Citation Envoyé par DonQuiche  Voir le message
En pratique, sur une équipe de taille raisonnable, je n'ai vu que des avantages après l'abandon des commentaires.

Face à cet argument, je serais comme mon collègue

Citation Envoyé par pomauguet  Voir le message
C'est un peu radical de ne pas mettre de commentaire , mais je plussoie sur l'idée derrière ta règle.

Comme tu l'as dit, 95% des commentaires sont inutiles. Et de ceux-là, on s'en passe aisément.

Mais il reste les 5%. Et ceux-là ont toutes leurs importances, bien supérieure souvent à n'importe quelle règle de bonne écriture de code.

Qui n'a jamais eu affaire à un algorithme subtil à coder ou quelques lignes de commentaire en début de fonction, indiquant les particularités, épargnent des heures de réflexion et d'épluchage de doc pour savoir comment ça marche ...
Qui ne sait jamais retrouver devant une fonction censée traiter tout un tableau mais ne commençant qu'à l'index 1 et non pas 0 ...

Il ne faut pas bannir les commentaires, juste les inutiles.

Et encore, moi, perso, j'en met, de particulièrement inutiles.
J'aime bien, juste avant la signature de chaque méthode, mettre une ligne de * ou de # sur toute la largeur de ma page, pour bien découper mon fichier source et identifier immédiatement le début de chaque méthode. Utile lorsqu'on doit passer en revue du code source sur des IDE qui ne savant pas trop gérer la coloration syntaxique.
Il m'arrive aussi de faire de même dans les grosses fonctions (je maintiens, contre les "bonnes pensées" actuelles qu'il n'est pas forcément toujours pertinent de découper des longues fonctions en sous-fonctions), notamment dans des fonctions de traitement séquentiel par exemple, de mettre une petite ligne de commentaire (*, #, ., -, ou autre) pour bien identifier et séparer chaque étape.
(Sachant que personnellement, j'ai une horreur viscérale de l'accumulation de lignes vides dans le but de séparer du code)
Avatar de CodeurPlusPlus CodeurPlusPlus
http://www.developpez.com
Membre éprouvé
le 08/05/2014 19:04
Citation Envoyé par Mr_Exal  Voir le message
Va dire ça aux deux guignols qui ont évalué mon projet de BTS (synthèse et reconnaissance vocale en Java), ils m'ont dit clairement que si je ne mettais aucun commentaire ils ne m'embaucheraient jamais (alors que toutes les fonctions étaient clairement nommées et le code bien plus que lisible).

Un peu d'humilité ne te ferait pas de mal. Tu ne peux pas évaluer objectivement la lisibilité du code que tu produis. Et si tu penses que tu peux faire lisible sans aucun commentaire, c'est que tu te sur-estimes complètement. Mais ce débat a déjà été fait et refait maintes fois.

Tu te permets de traiter de "guignols" des personnes qui connaissent mieux que toi leur métier.
Avatar de DonQuiche DonQuiche
http://www.developpez.com
Expert Confirmé
le 09/05/2014 8:16
Citation Envoyé par sevyc64  Voir le message
Mais il reste les 5%. Et ceux-là ont toutes leurs importances, bien supérieure souvent à n'importe quelle règle de bonne écriture de code.

Nous sommes d'accord : quand j'ai parlé d'abandon des commentaires je ne voulais pas dire leur éradication totale, seulement l'arrêt des commentaires systématiques (JavaDoc/XmlDoc) et la recherche en priorité d'alternatives par le renommage ou le redécoupage.

Nous ne sommes pas commenticides !

Quant aux séparateurs que tu affectionnes, c'est une affaire de préférence, comme les espaces. A chaque équipe son choix en la matière.
Avatar de ptah35 ptah35
http://www.developpez.com
Membre chevronné
le 10/05/2014 9:47
S'agissant des commentaires j'applique le principe suivant : "Si tu peux le dire en code, dis le en code et utilise les commentaire pour le reste". Le reste c'est, par exemple, les en-tête de fichier (description, contexte, auteur, date de dernière modification, ...), selon les langages, les pré-condition, post-condition et invariant des méthodes, fonction ou procédure, des références bibliographiques ou des explications à propos d'un algorithme, du JavaDoc/XmlDoc pour la partie documentée d'une API, etc.

Pour les conseils, je pense que la refactorisation est très importante mais pour la pratiquer réellement il faut avant tout de bons tests unitaires et d'intégration. Faire de la refactorisation efficace nécessite de pouvoir autant que possible se libérer l'esprit de la peur de casser le code existant, sans tests cette peur est plus que légitime. Avec de bon tests en revanches, on sait que si après une modification les tests passent, sans pour autant avoir de certitude, on a un niveau de confiance raisonnable que l'on a rien cassé et s'il s'avère par la suite que c'était le cas, on pourra alors corriger le test fautif et/ou ajouter un ou plusieurs tests pour traiter spécifiquement le problème.
Avatar de sevyc64 sevyc64
http://www.developpez.com
Modérateur
le 10/05/2014 10:30
Citation Envoyé par ptah35  Voir le message
Le reste c'est, par exemple, les en-tête de fichier (description, contexte, auteur, date de dernière modification, ...),

Le genre de commentaire que, personnellement, je considère justement parfaitement inutile (et je sais de quoi je parle, j'en ai gérer pendant plusieurs années pour un client). La notion d'auteur peut être très vague lorsqu'on est dans une équipe de plusieurs développeurs, voire dans une boite comportant plusieurs équipes de plusieurs développeurs. Et si en plus en considère le turn-over de la boite .... Sauf à y renseigner l'annuaire, ça sert pas à grand chose.
Les notions de modifications, dernière modification, etc, sont souvent rarement à jour au delà de la 4 ou 5ème version du fichier, surtout lorsque les entêtes en question concerne à la fois le fichier lui-même mais aussi chaque méthode dans le fichier.

De plus, dans une structure organisée, qui possède un gestionnaire de source type svn ou github, ce genre de commentaire est rendu obsolète par le gestionnaire de source, bien plus efficace à ce niveau là.

Mais après, effectivement, chacun voit son propre intérêt dans sa façon de faire.

Pour le cas que j'ai eu à gérer durant plusieurs années, sur ce point là et sur la doc qui allait avec, il n'était pas rare qu'il me faille 1/2h pour faire une modif, et ensuite 3 jours pour gérer toutes ces notions de versions, tant dans les sources que sur la doc qu'il fallait modifier entièrement. Sans compter les tests, qui, au delà du test fonctionnel de la modif, consistaient à redérouler l'entièreté des tests pour la non régression, une inspection de code, un file-compare, une relecture complète de la doc, ...
Bref rien de très productif.
Alors qu'avec un gestionnaire de source, il suffit de produire un rapport d'évolution entre les 2 releases, ça prend 30sec !
Avatar de ptah35 ptah35
http://www.developpez.com
Membre chevronné
le 10/05/2014 12:34
Citation Envoyé par sevyc64  Voir le message
Le genre de commentaire que, personnellement, je considère justement parfaitement inutile (et je sais de quoi je parle, j'en ai gérer pendant plusieurs années pour un client). La notion d'auteur peut être très vague lorsqu'on est dans une équipe de plusieurs développeurs, voire dans une boite comportant plusieurs équipes de plusieurs développeurs. Et si en plus en considère le turn-over de la boite .... Sauf à y renseigner l'annuaire, ça sert pas à grand chose.
Les notions de modifications, dernière modification, etc, sont souvent rarement à jour au delà de la 4 ou 5ème version du fichier, surtout lorsque les entêtes en question concerne à la fois le fichier lui-même mais aussi chaque méthode dans le fichier.

De plus, dans une structure organisée, qui possède un gestionnaire de source type svn ou github, ce genre de commentaire est rendu obsolète par le gestionnaire de source, bien plus efficace à ce niveau là.

Mais après, effectivement, chacun voit son propre intérêt dans sa façon de faire.

Pour le cas que j'ai eu à gérer durant plusieurs années, sur ce point là et sur la doc qui allait avec, il n'était pas rare qu'il me faille 1/2h pour faire une modif, et ensuite 3 jours pour gérer toutes ces notions de versions, tant dans les sources que sur la doc qu'il fallait modifier entièrement. Sans compter les tests, qui, au delà du test fonctionnel de la modif, consistaient à redérouler l'entièreté des tests pour la non régression, une inspection de code, un file-compare, une relecture complète de la doc, ...
Bref rien de très productif.
Alors qu'avec un gestionnaire de source, il suffit de produire un rapport d'évolution entre les 2 releases, ça prend 30sec !

Pour l'auteur et la date je pensais pour les deux à la dernière modification mais j'admet que ce n'est pas forcément nécessaire, l'information étant effectivement dans le système de gestion de version qui est, selon moi, une absolue nécessité si l'on est professionnel et je ne vois que peu de raison de s'en passer dans les autre cas. Je pense néanmoins qu'une description du contexte dans lequel on utilise le fichier et une brève description de son contenu reste utile. D'une manière générale ce que l'on écrit sous forme de commentaire doit être relativement stable et c'est le cas de la description du contexte d'un fichier, du JavaDoc d'une API qui est publiée ou des pré-conditions, post-conditions et invariants d'une méthode. Mais le principe est :

"Si tu peux le dire en code, dis le en code et utilise les commentaires pour le reste"

A chacun de décider ce qui est utile ou non dans le reste, mais le fait de dire uniquement en code ce qui peut être dit en code évide déjà une bonne partie des commentaires susceptibles de devenir obsolètes.
Avatar de Mr_Exal Mr_Exal
http://www.developpez.com
Expert Confirmé
le 19/05/2014 9:10
Citation Envoyé par CodeurPlusPlus  Voir le message
Un peu d'humilité ne te ferait pas de mal. Tu ne peux pas évaluer objectivement la lisibilité du code que tu produis. Et si tu penses que tu peux faire lisible sans aucun commentaire, c'est que tu te sur-estimes complètement. Mais ce débat a déjà été fait et refait maintes fois.

Tu te permets de traiter de "guignols" des personnes qui connaissent mieux que toi leur métier.

J'en ai discuté (et montré ce que j'avais produis autant en terme de code que d'oral) avec plusieurs personnes du métier et crois moi oui ce sont deux guignols. Rien qu'à travers les questions qu'ils m'ont posé ils n'ont strictement rien écouté de ce que je leur ai raconté (et crois mois que j'avais passé des oraux blancs devant des personnes ne connaissant pas du tout mon sujet avant, qui ont un QI moyen normal et qui ont tout à fait compris de quoi il s'agissait).
Avatar de el_slapper el_slapper
http://www.developpez.com
Expert Confirmé Sénior
le 19/05/2014 11:35
Citation Envoyé par Mr_Exal  Voir le message
J'en ai discuté (et montré ce que j'avais produis autant en terme de code que d'oral) avec plusieurs personnes du métier et crois moi oui ce sont deux guignols. Rien qu'à travers les questions qu'ils m'ont posé ils n'ont strictement rien écouté de ce que je leur ai raconté (et crois mois que j'avais passé des oraux blancs devant des personnes ne connaissant pas du tout mon sujet avant, qui ont un QI moyen normal et qui ont tout à fait compris de quoi il s'agissait).

Je n'aime pas tailler, mais je vais le faire quand même : tu est un mauvais programmeur parceque tu manques cruellement d'humilité. On a toujours plein de trucs à apprendre, y compris de gens qui ne pensent pas comme nous. En partant du principe qu'ils n'ont rien à t'apprendre, alors tu te limites toi-même, dans un univers ou l'apprentissage est essentiel.
Avatar de Mr_Exal Mr_Exal
http://www.developpez.com
Expert Confirmé
le 19/05/2014 13:12
Citation Envoyé par el_slapper  Voir le message
Je n'aime pas tailler, mais je vais le faire quand même : tu est un mauvais programmeur parceque tu manques cruellement d'humilité. On a toujours plein de trucs à apprendre, y compris de gens qui ne pensent pas comme nous. En partant du principe qu'ils n'ont rien à t'apprendre, alors tu te limites toi-même, dans un univers ou l'apprentissage est essentiel.

Je n'appelle pas ça du manque d'humilité, juste savoir faire la part des choses.

Je suis bien conscient que la formation est permanente dans nos métiers et qu'il vaut mieux être ouvert à tout et à chacun.

Seulement, pour entendre les réflexions qu'ils m'ont fait pendant mon oral j'avais un peu autre chose à faire que de me faire casser comme une merde pendant 45 minutes (après, soit, c'était peut être le but de l'exercice, mais même mes profs ont halluciné quand je leur ai raconté ce qu'il s'est passé (des réflexions du genre "Ah c'est ça vos Schémas UML ? Mais c'est de la merde.")).

Je ne vois pas trop en quoi c'est pertinent de se foutre de la gueule du candidat que tu as en face de toi pendant tout le long de son oral et de le casser à chaque fois que tu ouvres ta bouche.

Maintenant j'en suis pas à dire "Bouhouhou les vilains jurys ils ont été méchants."

[troll] Je ne fais pas (encore) de marketing je n'ai pas (encore) besoin d'étudier les cons pour chercher à comprendre comment ils fonctionnent. [/troll]
Offres d'emploi IT
Administrateur middleware J2EE
CDI
CTS NORD - Ile de France - Paris (75000)
Parue le 07/07/2014
Comptable Mandants (H/F) - CDI
CDI
Grey Consulting - Ile de France - Montrouge (92120)
Parue le 29/07/2014
Chef de projet / lead developer
CDI
Omniciel - Provence Alpes Côte d'Azur - Marseille (13000)
Parue le 03/07/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula