Quel est le meilleur conseil quand on programme ?

[mitkl]

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


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 ?

[MarieKisSlaJoue]

On ne peux que être d'accord avec celui de Eric Lippert pour rappel

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.

, ceci dit c'est pas forcément le plus simple à mettre en œuvre, car ça demande de l’implication et de la générosité. (En plus du temps).

Mais le meilleurs reste pour moi. celui de Obie Fernandez

toujours prendre le temps de réfléchir quand on a une erreur avant de rajouter du code supplémentaire.

C'est celui qu'on devrai toujours avoir en tête pour moi.

Le premier d'Erik Buck d'écrire moins de code est plus une maxime qu'un conseil je trouve.


Quand au meilleur conseil qu'on m'est donné la tous de suite je vois pas. Aucun n'a du me marquer, mais si ça me revient...

En tous cas leur projet est très intéressant.

[sevyc64]

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.

[deathness]

Ce sont tous des bons conseils... Quand ils sont suivi de manière modéré!
Pour moi l'enseignement a une grande part la dedans, sur la méthodologie inculqué pour résoudre les problèmes, et sur l’apprentissage des standards de nom par exemple.

[chaplin]

Bill Wagner ..."d'abord rendre son code fonctionnel avant de vouloir l'améliorer !"

D'abord, on essaye de comprendre l'aspect métier, ensuite on optimise le code.

Les autres conseils peuvent être appliqués selon un ordre et le temps dont on dispose (temps = luxe = pas payé par le client )

Edit:

[B]Eric Lipper ... "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."

J'hésite entre les deux.

[el_slapper]

toujours prendre le temps de réfléchir ...

Pas besoin de plus. Même si les autres conseils sont bons aussi, je trouve. Mais ça, c'est vraiment la base. Celui qui applique le petit manuel sans réfléchir va dans le mur. Tout le reste en découle :

toujours prendre le temps de réfléchir :
==>à comment écrire moins de code
==>à chaque fois qu'on a une erreur
==>et lire du code avant de se lancer dans les grandes manoeuvres
==>ce qui passe aussi par des interactions-conseils-echanges avec d'autres professionels
==>sur les optimisations possibles du code, notamment en terme de lisibilité/maintenabilité, ainsi que sur la manière optimale de tester.
==>sur l'objectif réel du code : être beau, ou marcher?

Et on retrouve l'ensemble des conseils donnés.

[_skip]

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.

[tomlev]

Envoyé par mitkl

Eric Lippert Eric Lippert est un développeur C# qui a travaillé chez Microsoft.

Il y travaille encore... il est dans l'équipe du compilateur C# et membre du design committee du langage

Pour moi les meilleurs conseils sont ceux de Danny Kalev (read much more than you write) et d'Eric Lippert (participer sur les forums et chercher la réponse quand on ne la connait pas). En tous cas c'est ce qui m'a fait le plus progresser.

[grunk]

Envoyé par mitkl

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 !

C'est un des principes que j'essai de respecter tout le temps. Je fait toujours la fonctionnalité la plus basique possible , pour avoir un code fonctionnel et sans bug. Et ensuite je rajoute les folies des graphistes et ergonome

Le conseil principal que je pourrais donner , c'est de coder le plus tard possible. Récolter le plus d'informations possible , sur l'environnement , le besoin du client final sans pour autant tomber dans le travers de l'exès de conception ... A foncer tête baisser dans un projet on se retrouve généralement avec un projet galère où il faut tout changer tous les 3 semaines.

[YannPeniguel]

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.

[Freem]

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.

[whiplash_alex]

Vous en conviendrez, le meilleur conseil que l'on peut donner à certains programmeurs, c'est "fait autre chose !"

[poincare]

Mon meilleur conseil : trouver et reutiliser des bibliothèques existantes.
Bien souvent, l'application que vous developpez a déjà été écrite et il y a sur le Web des composants logiciels qui évitent de recoder. Gain de temps, gain d'argent. Avant de coder, un tour sur Sourceforge, Github et rosetta.org est indispensable.

[air-dex]

Envoyé par mitkl

Pour vous, quel est le meilleur conseil que l'on peut donner ?

Ne jamais se précipiter sur son IDE/Editeur de code mais commencer par écrire ce qu'on veut faire sur un brouillon. Cela permet de poser ses idées, de les éclaircir, de les mettre au point et de gagner du temps au moment du codage pur et dur.

[sviardot]

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.

Particulièrement d'accord en particulier pour lutter contre la maladie actuelle - le clonage du codage - On écrit de plus en plus de code, peut être parce que l'on a la place, sans se rendre compte que l'on risque alors de traiter une problématique équivalente avec des codes différents. Sans compter que pour corriger un problème ou faire évoluer, il faut repasser sur toues les copies.

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.

Particulièrement vrai et ce pour deux point au moins :
* Une erreur n'est pas toujours une erreur mais peut traduire une mauvaise compréhension de la problématique fonctionnelle ou de l'utilisation du logiciel.
* Lorsque des patchs correctifs sont écrits, ils ne prennent souvent en compte que le point de détails mis en évidence par l'erreur. L'erreur est corrigée, et encore pas dans toutes les copies du même code, sans vérifier si la correction ne vas poser de problèmes ailleurs. Et c'est hélas trop souvent ce que l'on constate sauf que le problème est alors beaucoup plus complexe à corriger car découvert tardivement.

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

Avec une trentaine d'année d'expérience en développement,je sais maintenant que rare sont les problématiques qui n'ont pas été déjà développées. Donc on récupère les analyses et surtout on apprend des erreurs des autres pour ne pas les refaire.
Et puis, lire permet d'avoir une certaine compréhension de ce que le fonctionnel demande donc d'avoir une vision à plus long terme (prévoir l'administration et l'évolution).

[gaiasson31]

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.

[Homo_Informaticus]

Je n'ai que deux ans et demi de boite derrière moi, toujours débutant.

Ceci dit les trois leçon que j'ai tiré jusqu'ici :

-Comprendre le besoin final : Les cahiers des charges élaboré pendant 6 mois avant de commencer le développement répondent à un besoin théorique d'un fonctionnement parfait du service. Pour bien coder, j'ai besoin de comprendre ce que le client final attend et je demande de passer du temps dans son service. Souvent ils ont des idées auxquelles on ne penserait pas. Bien sûr cela implique la possibilité et le temps accordé pour le faire, chose rare. Je me sens plus proche des développement agile répondants plus rapidement à un besoin fonctionnel et donner une amélioration constante. Je n'adhère personnellement que très peu aux cahiers des charges arrêtés et non discutables x mois avant la conception. (Il y a bien sûr des justes milieux )

-Je comprend le fonctionnement de mon environnement et je forge mes outils : Je développe en C# et j'ai passé beaucoup de temps (perso certes) à étudier l'architecture des systèmes Windows et les services Windows Server. J'ai pris le temps ( encore une fois c'est certes un luxe que m'a accordé ma boite, bien que passé du temps perso aussi) de développer mes propres bibliothèques pour répondre à mes besoin en me forçant à coder à partir des classes de base. Ainsi j'ai une compréhension de ce qu'il se passe étape par étape lorsque j'effectue une action.

et surtout le plus dur :

- Connaître ses limites et trouver le bon compromis entre qualité et temps de développement. J'avais tendance et j'ai parfois toujours à chercher le code le plus optimisé, le plus propre. De plus en plus je jauge combien de temps il me faut pour trouver ce compromis lorsque j’écris du code. Si je dois livrer une application et qu'une fonction peut être fonctionnelle en 2 jours mais que je mettrais 1 semaine à optimiser, je dois savoir m'arrêter, livrer le fonctionnel et me planifier l'amélioration lorsque le planning le permet.

Ces règles que je me donne à moi même sont un mélange de ce qui a été cité et je suis tout à fait d'accord avec le fait qu'il ne faut pas prendre les règles des gourou à la lettre. Il faut en comprendre les principes. L'apprentissage se fait surtout par l'expérience et par l’échec... surtout l’échec

Comprendre le besoin, connaître ses outils. Lorsque vous bloquez et trouvez une solution sur Internet, prenez le temps de relire, comprendre et recoder.

[hotcryx]

Mon conseil :

"produire un code performant dès le départ, cela vous fera gagner du temps par la suite."

[tomlev]

Envoyé par hotcryx

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

[el_slapper]

Envoyé par Homo_Informaticus

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.