Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 7 12345 ... DernièreDernière
Affichage des résultats 1 à 20 sur 124
  1. #1
    Membre Expert
    Avatar de mitkl
    Homme Profil pro Timothée Bernard
    Étudiant
    Inscrit en
    février 2010
    Messages
    364
    Détails du profil
    Informations personnelles :
    Nom : Homme Timothée Bernard
    Âge : 23
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : février 2010
    Messages : 364
    Points : 1 088
    Points
    1 088

    Par défaut 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 ?

    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 ?
    Si vous ne savez toujours pas ce qu’est la récursivité, relisez cette phrase.

    Mon blog sur la programmation et l'informatique !

  2. #2
    Membre Expert
    Avatar de MarieKisSlaJoue
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2012
    Messages
    509
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Eure et Loir (Centre)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : mai 2012
    Messages : 509
    Points : 1 394
    Points
    1 394

    Par défaut

    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.
    Ce post à été écrit par un panda

  3. #3
    Modérateur
    Avatar de sevyc64
    Homme Profil pro Yves
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    7 023
    Détails du profil
    Informations personnelles :
    Nom : Homme Yves
    Âge : 41
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 7 023
    Points : 18 060
    Points
    18 060

    Par défaut

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

    Parce que le partage est notre force, la connaissance sera notre victoire

  4. #4
    Expert Confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2008
    Messages
    1 163
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2008
    Messages : 1 163
    Points : 2 612
    Points
    2 612

    Par défaut

    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.

  5. #5
    Membre Expert Avatar de chaplin
    Inscrit en
    août 2006
    Messages
    1 215
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 1 215
    Points : 1 571
    Points
    1 571

    Par défaut

    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.

  6. #6
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 173
    Points : 10 473
    Points
    10 473

    Par défaut

    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #7
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 722
    Points : 6 894
    Points
    6 894

    Par défaut

    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.

  8. #8
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 286
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 286
    Points : 39 064
    Points
    39 064

    Par défaut

    Citation Envoyé par mitkl Voir le message
    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.

  9. #9
    Modérateur
    Avatar de grunk
    Homme Profil pro Olivier
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 157
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 157
    Points : 7 566
    Points
    7 566

    Par défaut

    Citation Envoyé par mitkl Voir le message
    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.

  10. #10
    Membre Expert

    Homme Profil pro Yann Peniguel
    Consultant CRM
    Inscrit en
    septembre 2010
    Messages
    450
    Détails du profil
    Informations personnelles :
    Nom : Homme Yann Peniguel
    Localisation : France

    Informations professionnelles :
    Activité : Consultant CRM

    Informations forums :
    Inscription : septembre 2010
    Messages : 450
    Points : 1 022
    Points
    1 022

    Par défaut

    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.
    Si vous moinsez, merci de répondre pour argumenter!
    Ma présentation

  11. #11
    Expert Confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    805
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 805
    Points : 2 650
    Points
    2 650

    Par défaut

    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.

  12. #12
    Invité de passage
    Inscrit en
    août 2012
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : août 2012
    Messages : 1
    Points : 0
    Points
    0

    Par défaut

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

  13. #13
    Membre régulier Avatar de poincare
    Homme Profil pro Henri Poincare
    Architecte technique
    Inscrit en
    mai 2007
    Messages
    48
    Détails du profil
    Informations personnelles :
    Nom : Homme Henri Poincare
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2007
    Messages : 48
    Points : 75
    Points
    75

    Par défaut 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.

  14. #14
    Membre Expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 110
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 110
    Points : 2 281
    Points
    2 281

    Par défaut

    Citation Envoyé par mitkl Voir le message
    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.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  15. #15
    Candidat au titre de Membre du Club
    Homme Profil pro SERGE VIARDOT
    Architecte de système d'information
    Inscrit en
    mai 2009
    Messages
    3
    Détails du profil
    Informations personnelles :
    Nom : Homme SERGE VIARDOT
    Localisation : France

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2009
    Messages : 3
    Points : 14
    Points
    14

    Par défaut Conseil pour programmer ?

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

  16. #16
    Nouveau Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    août 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2012
    Messages : 3
    Points : 28
    Points
    28

    Par défaut

    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.

  17. #17
    Membre confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    août 2010
    Messages
    89
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : août 2010
    Messages : 89
    Points : 255
    Points
    255

    Par défaut

    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.

  18. #18
    Membre chevronné
    Développeur
    Inscrit en
    mars 2012
    Messages
    485
    Détails du profil
    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 485
    Points : 622
    Points
    622

    Par défaut

    Mon conseil :

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

  19. #19
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 286
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 286
    Points : 39 064
    Points
    39 064

    Par défaut

    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

  20. #20
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 173
    Points : 10 473
    Points
    10 473

    Par défaut

    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •