Quel est le meilleur conseil quand on programme ?
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 ?
:fleche: Avec qui êtes-vous le plus d'accord ?
:fleche: Quel est le meilleur conseil que vous ayez reçu ?
:fleche: Pour vous, quel est le meilleur conseil que l'on peut donner ?
Ne pas re-inventer la roue
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.
Conseil pour programmer ?
Citation:
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.
Citation:
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.
Citation:
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).