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 !

Quel est le meilleur conseil à suivre quand on programme ?
Plusieurs experts répondent à cette question, partagez-vous leurs opinions ?

Le , par mitkl

0PARTAGES

9  0 
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 ?

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

Avatar de _skip
Expert éminent https://www.developpez.com
Le 06/08/2012 à 10:09

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 "Ecrire moins de code" pour rendre une source plus simple et plus facile à maintenir.
Ouais je suis d'accord dans l'ensemble... mais il y a toujours quelques petites choses dont on se doit d'être prudent avec.

Plus concis, c'est pas forcément plus lisible.

j'ai l'impression de constater une manie déplorable, particulièrement présente dans certains langages de scripts ou d'inspiration fonctionnelle, de vouloir économiser les retours chariots en groupant un maximum d'opération sur une ligne.

Moins de code mais plus de configuration?

Le monde java en cause encore une fois, dans pas mal d'outils on peut faire un paquet de choses déclarativement à l'aide de fichier properties ou XML, y compris des choses qui ne sont pas destinées à être modifiées hors compilation. L'un des argument est là aussi de coder moins, mais est-ce qu'on y gagne toujours lorsqu'on remplace du code fortement typé et refactorable par des déclarations dans des fichiers qui sont transformées en magie noire par reflection ou instrumentation au runtime?

Moins de code mais moins de compréhension

Il y a une manie, de laisser faire le framework qui fait le café, la lessive et promène le chien. Et l'argument en leur faveur est exactement celui-ci : coder moins et laisser travailler le super outil conçu par les experts. On peut facilement (pas obligatoirement) être motivé par des succès rapides au début puis ensuite tomber dans des situations où ce que fait l'outil c'est pas exactement ce qu'on veut. Sait-on d'ailleurs ce qu'il fait ce gros jar de 500'000 lignes?


Quel est le meilleur conseil que vous ayez reçu ?
Pour vous, quel est le meilleur conseil que l'on peut donner ?
Ne pas tomber dans le piège de la surconception, ne pas gonfler artificiellement son code avec des couches d'abstraction qui n'apportent rien (Dieu sait que c'est la mode du café qui doit tout ignorer de l'eau chaude), privilégier les solutions simples et maîtrisées.

Lorsque le projet est fini à temps, qu'il est maintenable et facile à comprendre, c'est qu'on a pas trop mal bossé. Quitte à se faire traiter de naze par les écrivains de bouquins.

Mais ce n'est pas facile, j'ai moi même pendant longtemps passé mon temps à me demander si ce que je faisais c'était de la meilleure façon, théoriquement la plus juste, la plus réutilisable etc... Je n'ai vraiment commencé à appliquer mes propres conseils ci-dessus que lorsque je suis devenu indépendant (ou presque). Le concept agile "yagni" (you ain't gonna need it) est une bonne source d'inspiration, éviter de travailler pour rien en prévision de choses qui ne sont pas prévues ni demandées et par conséquent non facturables.
16  0 
Avatar de Freem
Membre émérite https://www.developpez.com
Le 06/08/2012 à 11:53
J'ai envie de dire ces quelques conseils, moi (mais je ne suis pas expert, pardonnez mon outrecuidance ):
_ ne jamais suivre aveuglément le conseil de quelqu'un d'autre, fût-il un guru. Les guru ne pensent pas comme vous, ce sont des gurus et pas vous.
_ la théorie, c'est quand ça devrait marcher, la pratique c'est quand ça marche et qu'on sait pas pourquoi. Il faut trouver le juste milieu.

Je m'explique.
J'ai appris seul à programmer.
J'arrivais à faire des programmes simples qui marchaient.
Je suis arrivé en BTS, on m'a dit: "Fait la conception avant de toucher la première ligne de code". J'ai suivi ce conseil aveuglément et n'ai plus rien réussi à faire qui marche.
Puis, aux détours du net, je suis tombé ici: http://wiki.wesnoth.org/WesnothPhilosophy ai été séduit par la philosophie KISS et en l'appliquant de mon mieux, j'ai réussi à faire de petits trucs qui marchent, mais qui étaient toujours bancals.
Depuis, j'ai évolué, je mixe ces deux conseils, et mes programmes arrivent à voir le jour d'une façon qui me satisfait.

Il ne faut pas suivre les conseils, il faut les comprendre, nuance.
Les conseils sont donnés par des gens qui ne pensent pas, et ne penseront jamais comme vous.
Les suivre, c'est se tirer une balle dans le pied. Comprendre pourquoi on vous le donne vous permet de développer une technique adaptée à votre façon de penser: certains sont de grands théoriciens, d'autres excellent dans l'empirique, la plupart ont besoin d'une alchimie subtile entre théorie et empirisme, qui diffère selon les gens.
Voila pourquoi c'est en forgeant qu'on devient forgeron, pas en suivant les conseils des forgerons qui, de toute façon, se contredisent tous les uns les autres, et pourtant, aucun n'a tord.
16  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 06/08/2012 à 14:49
Citation Envoyé par Homo_Informaticus Voir le message
Je n'ai que deux ans et demi de boite derrière moi, toujours débutant.
(.../...)
+1, voire +1000

J'ai 12 ans de bouteille, mais, au final, j'ai toujours plein de limites, et plein de domaines dans lesquels je suis encore débutant. Notre domaine est tellement vaste que nous sommes tous débutants, presque partout. Il y a toujours plys de choses à apprendre que de choses que l'on sait.

Croire que l'on sait, c'est un des plus gros risques, je crois.
15  0 
Avatar de Pergos
Membre habitué https://www.developpez.com
Le 06/08/2012 à 17:42
Citation Envoyé par el_slapper Voir le message
+1, voire +1000

J'ai 12 ans de bouteille, mais, au final, j'ai toujours plein de limites, et plein de domaines dans lesquels je suis encore débutant. Notre domaine est tellement vaste que nous sommes tous débutants, presque partout. Il y a toujours plys de choses à apprendre que de choses que l'on sait.

Croire que l'on sait, c'est un des plus gros risques, je crois.
+1

Comme le dit le proverbe chinois :

Celui qui sait qu'il sait, écoute-le.
Celui qui sait qu'il ne sait pas, éduque-le.
Celui qui ne sait pas qu'il sait, éveille-le.
Celui qui ne sait pas qu'il ne sait pas, fuis-le.
13  0 
Avatar de gaiasson31
Nouveau membre du Club https://www.developpez.com
Le 06/08/2012 à 13:59
Pour vous, quel est le meilleur conseil que l'on peut donner ?

Chaque conseil que j'ai pu lire sur cette discussion est un bon conseil à mes yeux mais j'en rajouterai quand même un : faites ce que vous aimez.
12  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 06/08/2012 à 14:45
Citation Envoyé par hotcryx Voir le message
Mon conseil :

"produire un code performant dès le départ, cela vous fera gagner du temps par la suite."
C'est plutôt le meilleur moyen de faire un code imbitable... Commence par faire un code qui marche, élimine les bugs, et seulement à ce moment là tu pourras te préoccuper de l'optimiser.

Premature optimization is the root of all evil
-- D. Knuth
10  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 07/08/2012 à 12:56
Comprends ce que tu fais

Ça peut paraitre simple, mais ça ne l'est pas. Parce qu'on peut aller très loin dans la compréhension : Ok, tu fais du Java. Mais est-ce que tu sais comment fonctionne la JVM ? Le garbage collector ? Est-ce que tu connais le bytecode ?

Bien connaitre les fondements des outils, des principes, des langages, des méthodes qu'on utilise, c'est toujours payant, à la fin.

Aborde chaque problème avec naïveté

C'est en supposant plein de choses qu'on obtient un truc pas terrible à la fin.

N'ai pas peur de casser ce que tu as fait

Tout le monde écrit du code qui finit à la poubelle avant d'avoir jamais été utilisé. C'est normal, et même très bien. Si tu trouve une meilleure solution que ce que tu as déjà fait, n'hésite pas à refaire. sur le long terme, tu seras gagnant.
6  0 
Avatar de deuz59
Membre régulier https://www.developpez.com
Le 10/08/2012 à 15:07
S'il fallait un seul conseil : "WHAT first, HOW last"

Traduction explicative : "Ecrire ce qu'on fait, le QUOI, d'abord en reléguant l'implémentation pure, le COMMENT, en dernier lieu"

Trop souvent on doit déduire, voire supposer sans certitude, ce qu'un code fait en fonction de l'implémentation qui est faite. En terme de maintenance pour le ciblage/diagnostique, trop de perte de temps/énergie à analyser/comprendre du code inutilement pour finalement tomber sur la seule partie qui nous intéresse, sans compter le risque d'erreur d'interprétation.
6  0 
Avatar de YannPeniguel
Membre éprouvé https://www.developpez.com
Le 06/08/2012 à 11:37
Je suis deux directives simples qui m'aide à développer efficacement:

Définir clairement le problème à résoudre : Sur le plan fonctionnel d'abord, que doit faire l'application ? Et sur le plan technique, comment le réaliser ?

Je remarque autour de moi que la plupart des gens qui ont du mal à développer n'ont, dès le départ, pas défini clairement leur tâche avant de se lancer.

Quand la tâche est claire, le reste coule souvent de source.

La deuxième rejoint un petit peu celle d'Erik Buck mais est plus générique: Privilégier les solutions simples utilisant des briques déjà existantes et fiables plutôt que de se lancer sur du spécifique inutile avec une architecture complexe.
5  0 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 05/08/2012 à 17:50
Totalement d'accord avec Obie Fernandez : Toujours se forcer à comprendre ce qui se passe plutôt que vouloir coder rapidement une rustine qui, la plupart du temps, ne fait que cacher le mal, pas le corriger.

Totalement d'accord avec Bill Wagner : surtout lorsque les délais sont au plus juste. On demande d'abord un code qui fonctionne correctement.

Partiellement d'accord avec Eric Lippert : Si oui, participer aux forums et autres permet de progresser (c'est d'ailleurs comme ça que j'ai appris le .Net, il y a quelques années), je ne suis pas du tout d'accord avec "si vous ne l'avez pas, rechercher sa réponse sur Internet.". Rechercher dans les doc style MSDN, Javadoc, essayer de comprendre les choses etc... oui. Mais "Rechercher sur Internet", me laisse comprendre "Rechercher sur les autres forums et faire un copier/coller de la réponse", là, non. On est pas un moteur de recherche, Google sait très bien le faire.
Mais rechercher sur d'autres forums, comprendre et tester la réponse et être capable de la réexpliquer, là, oui, c'est tout bénef.
5  1