Soutenez-nous
Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 6 PremièrePremière 123456 DernièreDernière
Affichage des résultats 41 à 60 sur 109
  1. #41
    Membre éprouvé
    Avatar de VivienD
    Homme Profil pro Vivien Duboué
    Étudiant
    Inscrit en
    octobre 2009
    Messages
    260
    Détails du profil
    Informations personnelles :
    Nom : Homme Vivien Duboué
    Âge : 23
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : octobre 2009
    Messages : 260
    Points : 403
    Points
    403

    Par défaut

    Citation Envoyé par ManusDei Voir le message
    Au lieu de faire une fonction qui ajoute X à tous les élements d'une liste (renvoyant X'), une fonction qui va appliquer une fonction Y à chaque élement d'une liste (renvoyant Y'), une fonction qui va récupérer l'information Z de chaque élément d'une liste (renvoyant Z', liste des informations), tu fais une fonction qui prend en paramètre une liste L et une fonction F, et qui applique F à chaque élement de L, renvoyant L'.

    Bref tu factorises 3 fonctions (à but unique) en une seule (qui a plusieurs utilisations possibles).

    C'est parfois un poil plus compliqué à relire, mais si il y a un bug dans ta gestion des listes, tu n'auras pas à traquer chacune des fonctions appliquées à X Y et Z pour corriger un bug.

    Ca c'est un exemple simple, souvent déjà prévu dans la bibliothèque de base du langage, mais c'est pour expliquer le principe.
    Merci, ManusDei.

  2. #42
    Membre Expert Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 1 010
    Points
    1 010

    Par défaut

    Citation Envoyé par poincare Voir le message
    Bien souvent, l'application que vous developpez a déjà été écrite
    Ah tiens ? Cela ne m'est jamais arrivé.

  3. #43
    Modérateur
    Avatar de Nemek
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    1 982
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 28
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 1 982
    Points : 3 988
    Points
    3 988

    Par défaut

    Citation Envoyé par I_believe_in_code Voir le message
    Ah tiens ? Cela ne m'est jamais arrivé.
    En ce moment ca m'arrive souvent mais c'est justement parce qu'on remplace l'application vieillissante
    Java : Forum - FAQ - Java SE 7 API - Java EE 7 API
    Articles : Introduction au langage Ceylon

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  4. #44
    Membre Expert Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 1 010
    Points
    1 010

    Par défaut

    Citation Envoyé par fcharton Voir le message
    Le meilleur conseil qu'on m'ait donné, c'était "ne jamais hésiter à refaire".
    Francois
    C'est aussi le meilleur qu'on m'ait donné. Dans un logiciel que je maintiens depuis bientôt vingt ans (oui, j'avais quinze ans que j'en ai terminé la première version), beaucoup de fonctions, voire des modules entiers, en sont à leur six ou septième version. Chaque version apporte au moins une des améliorations suivantes à la précédente :

    - son code est plus facile à comprendre ;
    - elle peut servir de sous-routine à une nouvelle fonctionnalité que je vais ajouter bientôt, alors que ce n'était pas le cas de la version précédente ;
    - l'algorithme a une meilleure complexité (par exemple n^2 au lieu de n^3) ;
    - elle est conforme à un style d'écriture que j'ai appliqué ailleurs et qui a donné des bouts de code bien lisibles.

    J'ajoute que pour certaines fonctions assez simples à écrire, je code systématiquement une version sans effet de bord et une avec effets de bord. Cela ne coûte pratiquement pas de temps supplémentaire sur le moment, mais je gagne du temps dès qu'il faut utiliser ces fonctions dans de nouveaux algorithmes qui s'écriront, selon les cas, plus facilement ou non dans un style "fonctionnel".

  5. #45
    Membre confirmé Avatar de Lordsephiroth
    Profil pro Patrick Mingard
    Inscrit en
    mai 2006
    Messages
    173
    Détails du profil
    Informations personnelles :
    Nom : Patrick Mingard
    Âge : 29

    Informations forums :
    Inscription : mai 2006
    Messages : 173
    Points : 201
    Points
    201

    Par défaut

    Pour ma part je donnerai ce conseil simple et efficace : être curieux et passionné.

    Sinon je rejoins largement les conseils de skip en première page : éviter les couches d'abstractions superflues, éviter de tout mettre en fichier de configuration, éviter de chercher à compresser le code (y a ZIP pour ça). Lisez son post, il est bien écrit et j'adhère parfaitement à sa vision.
    Always code as if the guy maintaining your application is a violent psychopath!
    Site personnel sur la saga Final Fantasy : http://www.final-fantasy.ch

  6. #46
    Membre à l'essai
    Inscrit en
    avril 2007
    Messages
    23
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 23
    Points : 23
    Points
    23

    Par défaut

    A peu de chose près, on peut résumer les pensées 1, 2, 5 et 6 à : "faites du TDD"...

  7. #47
    Membre régulier
    Inscrit en
    octobre 2004
    Messages
    71
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 71
    Points : 96
    Points
    96

    Par défaut

    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.

  8. #48
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 046
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 046
    Points : 8 286
    Points
    8 286

    Par défaut

    Citation Envoyé par Jay13mhsc Voir le message
    A peu de chose près, on peut résumer les pensées 1, 2, 5 et 6 à : "faites du TDD"...
    faut pas pousser.

    (1) "write less code"
    (2) toujours prendre le temps de réfléchir quand on a une erreur avant de rajouter du code supplémentaire.
    (5) 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.
    (6) Son conseil : d'abord rendre son code fonctionnel avant de vouloir l'améliorer.


    Pour le 1, quel rapport? Quel rapport entre le TDD et la quantité de code?
    Pour le 2, avoir les tests unitaires est fortement utile, ça n'oblige pas à les faire AVANT le code(initial ou rajouté).
    Pour le 5, pareil : il parle de pouvoir tout tester facilement, histoire de pouvoir faire une version deux qui soi isofonctionelle de la version un, pas d'écrire les tests en question avant la question un.
    Pour le 6, je ne vois pas le rapport non plus. Je code, je teste(peu importe comment), je fais marcher, puis ensuite seulement je rajoute des choses ou j'améliore l'existant.

    Attention, je ne dégoise pas le TDD(même si en Cobol, c'est compliqué ne serait-ce que d'en rêver, mais passons), c'est sans doute une excellente méthode. Simplement, ton interprétation des conseils me parait très, très orientée.
    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.

  9. #49
    Nouveau Membre du Club
    Homme Profil pro Fabrice Hauhouot
    Développeur logiciel
    Inscrit en
    octobre 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Hauhouot
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : octobre 2009
    Messages : 43
    Points : 33
    Points
    33

    Par défaut

    Lisez plus que vous ne codez

  10. #50
    Invité régulier
    Profil pro Razack KONI
    Inscrit en
    février 2009
    Messages
    7
    Détails du profil
    Informations personnelles :
    Nom : Razack KONI

    Informations forums :
    Inscription : février 2009
    Messages : 7
    Points : 7
    Points
    7

    Par défaut

    Pour ma part, c'est le conseil de Bill Wagner que je suis chque fois que je code.

  11. #51
    Invité de passage
    Inscrit en
    janvier 2011
    Messages
    33
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 33
    Points : 0
    Points
    0

    Par défaut

    Reflechir avant d'écrire une seule ligne de code, c'est le meilleur moyen d'écrire un code simple et eficace donc facile a maintenir.

    J'ai horreur des programmes fleuve...

  12. #52
    Invité de passage
    Profil pro Pacome KOFFI
    Inscrit en
    avril 2010
    Messages
    2
    Détails du profil
    Informations personnelles :
    Nom : Pacome KOFFI

    Informations forums :
    Inscription : avril 2010
    Messages : 2
    Points : 1
    Points
    1

    Par défaut

    RAS (complètement d'accord) pour Obie fernandez, Eric Lippert et Bill Wagner. Merci les gars. Quant à ce qui est d'écrire peu de code, cela dépend de ce qu'on cherche à créer et lire plus qu'on ne code, reste à savoir si on comprend véritablement ce qu'on lit si on ne l'applique pas en même temps. Mais merci d'y avoir penser.

  13. #53
    Membre du Club
    Développeur informatique
    Inscrit en
    mars 2009
    Messages
    54
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2009
    Messages : 54
    Points : 41
    Points
    41

    Par défaut

    Les meilleurs conseils que je puisse donner sont:
    [Niveau 0]
    - Ecrivez les tests avant le code
    - Coder avec des interfaces
    - Verifier que l'algorithme n'est pas connu avant de réinventer la roue
    - Chercher dans les structures des patterns évidents (visitor, builder, command, ...)
    - Coder ses propres exceptions
    - Analyser et mettre en place une politique flexible de logs (avec AOP pourquoi pas)
    [Niveau 1]
    - Documenter chaque entete de package, chaque entete de fonction
    - Une fonction ne doit pas dépasser 100 lignes - il y a cependant des exceptions à cette règle
    [Niveau 2]
    - Lire ces livre:
    * Design Pattern (GoF)
    * CERT (https://www.securecoding.cert.org/co...ndard+for+Java)
    * Meyer & Jossutis (C++)

  14. #54
    Membre du Club
    Profil pro
    Inscrit en
    octobre 2006
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : octobre 2006
    Messages : 43
    Points : 40
    Points
    40

    Par défaut

    Keep it simple

  15. #55
    Membre Expert
    Avatar de Pelote2012
    Homme Profil pro Yannick Leborgne
    Développeur informatique
    Inscrit en
    mars 2008
    Messages
    758
    Détails du profil
    Informations personnelles :
    Nom : Homme Yannick Leborgne
    Âge : 33
    Localisation : France, Haute Vienne (Limousin)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : mars 2008
    Messages : 758
    Points : 1 260
    Points
    1 260

    Par défaut

    Pour ma part, le 1er travail est de bien comprendre le besoin (actuel et futur) , en posant des questions, en mettant par écrit, demandant des cas concrets (curiosités)
    En suite, il faut analyser les différentes options qui se présentent pour répondre aux besoins
    Puis coder propres et être rigoureux. Je penses que la qualité 1ere d'un développeur est sa capacité à être carré dans sa tête. Les brouillons, les supers-codeurs (astuces de furieux) parfois ça marches, mais s'il faut faire évoluer le code ... que faire, devoir tout réécrire (comme ça m'est déjà arriver, car le gars à l'origine de l'appli à optimiser son code à mort mais du coup rendu tellment spécifique que toute modif même mineure, étaient impossible)
    Parfois vaut mieux un code moins évolué mais évolutif.
    Pour le reste :
    Les noms de variables , de fonction ... en termes explicites
    La solution la plus simple est toujours la meilleure
    des commentaires sur les parties plus compliquées
    NE SURTOUT PAS SE FAIRE CONFIANCE (vérifier toujours son boulot)
    Comprendre avant de faire un copier/coller (quite à faire une petite appli à part)
    Touche perso, je travaille toujours en itératif (je fais je refais je rerefais...), une simplification amène toujours une autre. (je précise qu'à chaque tour mon appli est stable )
    ...

  16. #56
    Invité de passage
    Inscrit en
    mars 2012
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : mars 2012
    Messages : 3
    Points : 1
    Points
    1

    Par défaut

    En tant que débutant et ayant rencontré des difficultés de débutant, je suis totalement d'accord avec le classement de el_slapper.

  17. #57
    Membre actif
    Avatar de EtherOS
    Homme Profil pro Lionel Tidjon
    Etudiant Polytechnicien
    Inscrit en
    juillet 2012
    Messages
    57
    Détails du profil
    Informations personnelles :
    Nom : Homme Lionel Tidjon
    Localisation : Cameroun

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

    Informations forums :
    Inscription : juillet 2012
    Messages : 57
    Points : 162
    Points
    162

    Par défaut Ma Proposition

    +---------------------+
    + PROPOSITION +
    +---------------------+

    Tous les propositions données sont bonnes. ma proposition pour le développement est :
    Code :
    1
    2
    3
    4
    5
    Analyser : ceci dit avoir des objectifs Clairs,voir si ca repond a un besoin, des données clairement etablies , ceci dit faire l' elaboration des UML,etc... pour structurer clairement les classes et diagrammes ,la structure detaillée du programme.
    ♥  Mise en algorithmique en suivant par exemple le modèle LEA
    ♥  Programmer : faire un code clair , bien commenté, lisible, bien indente et suivant une logique syntaxique propre (ie attribut des noms ayant un sens et lies au contexte de votre objectif) a vos variables ou paramètres.
    ♥ Compilation : rechercher l 'erreur progressivement bref suivre la recherche de manière iterative , corriger les fautes de syntaxe , les variables mals attribuées et les bugs.
    ♥ Optimisation : corriger le code afin de le ramener a l' objectif visé , rendre l usage facile par l'utilisateur , rendre la presentation du programme plus beau , esthetique et élégant .

  18. #58
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 046
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 046
    Points : 8 286
    Points
    8 286

    Par défaut

    Citation Envoyé par EtherOS Voir le message
    +---------------------+
    + PROPOSITION +
    +---------------------+

    Tous les propositions données sont bonnes. ma proposition pour le développement est :
    Code :
    1
    2
    3
    4
    5
    1  Analyser : ceci dit avoir des objectifs Clairs,voir si ca repond a un besoin, des données clairement etablies , ceci dit faire l' elaboration des UML,etc... pour structurer clairement les classes et diagrammes ,la structure detaillée du programme.
    2  Mise en algorithmique en suivant par exemple le modèle LEA
    3 Programmer : faire un code clair , bien commenté, lisible, bien indente et suivant une logique syntaxique propre (ie attribut des noms ayant un sens et lies au contexte de votre objectif) a vos variables ou paramètres.
    4 Compilation : rechercher l 'erreur progressivement bref suivre la recherche de manière iterative , corriger les fautes de syntaxe , les variables mals attribuées et les bugs.
    5 Optimisation : corriger le code afin de le ramener a l' objectif visé , rendre l usage facile par l'utilisateur , rendre la presentation du programme plus beau , esthetique et élégant .
    Il manque à mon sens un feedback sur la conception de haut niveau(tes étapes 1 et 2). Tes étapes 3, 4 et 5 me paraissent parfaitement adaptées : on découvre progressivement le problème en le codant, en le compilant, et en le testant, et c'est ainsi que l'on en améliore la compréhension. Sauf que souvent, celà a un impact sur l'algorithmique prévue, voire sur l'analyse initiale.

    Un projet mené sérieusement envisage que les êtres humains ne sont pas parfaits, et que la conception de base peut avoir loupé certaines choses. Ca ne la rend pas inutile, au contraire(sinon on ne sait pas ou on va), juste, elle ne doit pas être sacrée.
    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.

  19. #59
    Rédacteur
    Avatar de mitkl
    Homme Profil pro Timothée Bernard
    Étudiant
    Inscrit en
    février 2010
    Messages
    365
    Détails du profil
    Informations personnelles :
    Nom : Homme Timothée Bernard
    Âge : 22
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : février 2010
    Messages : 365
    Points : 1 011
    Points
    1 011

    Par défaut

    Petite mise-à-jour pour signaler la série n'étant pas terminée, de nouvelles interviews sont apparues, voici un aperçu :

    • Rob Pike : Rob Pike est un programmeur très expérimenté. Il a travaillé chez Bell Labs sur le projet Unix en côtoyant chaque jour les célèbres Thompson, Kerninghan et Ritchie. Depuis 2002, il travaille chez Google. Il est l'un des créateurs du langage Go. Son conseil, c'est Ken Thompson qui lui a donné : "Si vous plongez directement dans le bug, vous allez régler un problème local dans le code. Mais si vous réfléchissez à comment le bug est apparu, vous allez souvent trouver et corriger un problème d'un plus haut niveau dans votre code. Cela améliorera son design et empêchera l'apparition de nouveaux bugs.
    • Russ Olsen : Russ Olsen est l'auteur du livre Eloquent Ruby. Il n'a pas réellement de conseils à donner, juste une expérience amusante à partager.
    Si vous ne savez toujours pas ce qu’est la récursivité, relisez cette phrase.

    Mon blog sur la programmation et l'informatique !

  20. #60
    Membre chevronné
    Inscrit en
    janvier 2011
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 231
    Points : 665
    Points
    665

    Par défaut

    Citation Envoyé par mitkl Voir le message
    Quel est le meilleur conseil à suivre quand on programme ?
    Avancer par petites étapes mesurables plutôt que se lancer sans filet dans un développement gigantesque.

    Une bonne technique est la suivante :

    1. Définir le but de la prochaine petite étape (une méthode, une classe...) et créer un moyen d'en mesurer le succès : un test unitaire par exemple.

    2. Ecrire le code nécessaire pour compléter l'étape.

    3. Recueillir le feedback de notre mesure. Si c'est un échec, retourner à 2. Si c'est un succès, enjoy ! Ca parait tout bête, mais ces petits "moments de satisfaction" sont un très bon carburant.


    Avec ça j'ajouterais le conseil de Mark Summerfield (en fait, plutôt de Kent Beck ou Martin Fowler) à savoir refactorer le code à la fin de chaque étape.

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
  •