Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 4 sur 7 PremièrePremière 1234567 DernièreDernière
Affichage des résultats 61 à 80 sur 124
  1. #61
    Membre du Club

    Homme Profil pro Emmanuel Colomb
    Développeur informatique
    Inscrit en
    juin 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Nom : Homme Emmanuel Colomb
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2012
    Messages : 6
    Points : 40
    Points
    40

    Par défaut

    Je ne maîtrise que le C++ mais je pense que le conseil de Erik Buck est valable pour tous les langages et que c'est le meilleur conseil que l'on puisse donner.


    En effet, une bonne factorisation de code implique qu'à peu près tous les autres bon conseils et techniques de programmation soient exploités, notamment les conseils indiqués dans ce blog

    Attention, je dis bien une bonne factorisation mais je n'en dirais pas plus sur ce que c'est car ce serait très long, il doit bien exister des bouquins là dessus.

    La technique de (re)factorisation de code est cependant rarement utilisée dans un processus de développement en équipe :
    - D'abord parce que la factorisation n'apporte pas de gain fonctionnel (le gain fonctionnel est le seul paramètre généralement pris en compte).
    - Ensuite parce-qu'une tâche de (re)factorisation n'est pas facile à mettre en place et peut s'avérer dangereux si elle est mal réalisée :
    - on peut facilement ajouter des bugs en factorisant,
    - La factorisation implique souvent de modifier les interfaces et cela peut engendrer des modifications en cascade assez pénibles pour les autres développeurs (tout le monde vous tombe dessus )

    Bref ce type de tâche est souvent remise aux calandres grecs :
    1. Une équipe qui développe est très souvent à la bourre et n'a donc "pas le temps d'écrire du code correctement factorisé",
    2. Une équipe qui rajoute une fonctionnalité sur un code précédemment écrit n'a pas été mandatée pour refactoriser ce code ancien, il rajoute une verrue et basta !

    Bien souvent une refactorisation est mise en oeuvre "lorsque l'on a plus le choix" :
    - le code est trop incompréhensible,
    - la moindre modif de code doit être reportée à plusieurs endroits

  2. #62
    Membre régulier
    Inscrit en
    avril 2009
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : avril 2009
    Messages : 30
    Points : 91
    Points
    91

    Par défaut

    Il y a des cas où la refacto peut entrainer un gain financier direct.

    Je suis en stage chez un fabricant de système embarqué (suite avionique) et ils doivent développer en suivant la norme DO-178B (norme avionique etc.) : http://fr.wikipedia.org/wiki/DO-178

    Pour certaines fonctionnalités ils doivent avoir un certain niveau de certification. Par exemple pour un module critique qui en cas de dysfonctionnement peu entrainer le crach de l'appareil, il faut le développer en DAL A. Je vous laisse lire les contraintes de dev en DAL A sur l'article mais en gros : faire une refacto pour repenser l'archi du logiciel et passer de 1.3m de lignes à 800k lignes leur a fait gagner de l'argent par rapport au coût qu'aurait engendré de certifier 500k lignes supplémentaires.

    ++

  3. #63
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 137
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 137
    Points : 4 787
    Points
    4 787

    Par défaut

    Citation Envoyé par Dutiona Voir le message
    Il y a des cas où la refacto peut entrainer un gain financier direct.

    Je suis en stage chez un fabricant de système embarqué (suite avionique) et ils doivent développer en suivant la norme DO-178B (norme avionique etc.) : http://fr.wikipedia.org/wiki/DO-178

    Pour certaines fonctionnalités ils doivent avoir un certain niveau de certification. Par exemple pour un module critique qui en cas de dysfonctionnement peu entrainer le crach de l'appareil faut le développer en DAL A. Je vous laisse lire les contraintes de dev en DAL A sur l'articule mais en gros : faire une refacto pour repenser l'archi du logiciel et passer de 1.3m de lignes à 800k lignes leur a fait gagner de l'argent par rapport au coût qu'aurait engendré de certifier 500k lignes supplémentaires.

    ++
    Pas tellement d'accord car la refactorisation ne change pas le nombre de branche. Or a ce niveau d'exigence, on ne certifie pas des lignes mais des embranchements.

    Par ailleurs, je me demande si ce n'est pas toute la méthode qui est certifiée, par exemple en utilisant la méthode B on prouve mathématiquement la conformité du programme.
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    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. #64
    Expert Confirmé
    Homme Profil pro Benoît
    Inscrit en
    février 2003
    Messages
    1 738
    Détails du profil
    Informations personnelles :
    Nom : Homme Benoît
    Âge : 33
    Localisation : Belgique

    Informations forums :
    Inscription : février 2003
    Messages : 1 738
    Points : 2 908
    Points
    2 908

    Par défaut

    Citation Envoyé par Nemek Voir le message
    Pas tellement d'accord car la refactorisation ne change pas le nombre de branche. Or a ce niveau d'exigence, on ne certifie pas des lignes mais des embranchements.

    Par ailleurs, je me demande si ce n'est pas toute la méthode qui est certifiée, par exemple en utilisant la méthode B on prouve mathématiquement la conformité du programme.
    refactorisation = code exitant donc vouloir le modifier dans un système ou la certification coute de l'argent est une hérésie.
    Refactorisation est une hérise, si un code marche tu n'as pas besoin d'y toucher, si tu dois y toucher ce qu'il n'est plus bon et donc il ne sert a rien de regarder l'existant :p
    Je ne suis qu'un pauvre débutant alors ne frappez pas si mes idées ne sont pas bonnes

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

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

    Par défaut

    Citation Envoyé par BenoitM Voir le message
    si un code marche tu n'as pas besoin d'y toucher
    ...et tant pis s'il n'est pas maintenable...

  6. #66
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 137
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 137
    Points : 4 787
    Points
    4 787

    Par défaut

    Citation Envoyé par I_believe_in_code Voir le message
    ...et tant pis s'il n'est pas maintenable...
    Dans un projet en DO-178B avec un DAL > E, tu ne modifies que ce qui te concerne directement ...
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    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

  7. #67
    Membre régulier
    Inscrit en
    avril 2009
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : avril 2009
    Messages : 30
    Points : 91
    Points
    91

    Par défaut

    En pratique en DAL A :
    un programmeur A écrit une ligne de code
    un programmeur B vérifie la ligne
    un programmeur C la test
    si bug on reboucle sur programmeur A avec une procédure de débugage et tout ce que ça implique (déclaration d'incident dans un logiciel dédié etc.)

    Ensuite ya la phase de test unitaires etc. Mais les lignes sont *vraiment* relues.

    Donc faire de la refacto sur du certifié c'est pas forcément une hérésie. Tout le projet est en DAL > C avec 80% en DAL B et un module en cours de dev en DAL A (environ 5%).

    Et si, toute la méthode autour doit également être certifié. Ca inclue donc que tous les logiciels métiers utilisés pour dev doivent l'être (avec un niveau >= au niveau de certification de ce qu'on dev avec), les logiciels de test, de repport de bug etc.

    C'est une grosse machinerie pompe à fric et croyez-moi vu le coût du projet actuel (et à venir) ils auraient pas fait la refacto d'archi (d'ailleurs c'est pas la première, le projet a 10ans avec pas mal de livrables) si ça leur avait perdre de l'argent sur le long terme (ils prévoient déjà des trucs en 2014-2015 ^^ ).

  8. #68
    Expert Confirmé
    Homme Profil pro Benoît
    Inscrit en
    février 2003
    Messages
    1 738
    Détails du profil
    Informations personnelles :
    Nom : Homme Benoît
    Âge : 33
    Localisation : Belgique

    Informations forums :
    Inscription : février 2003
    Messages : 1 738
    Points : 2 908
    Points
    2 908

    Par défaut

    Citation Envoyé par I_believe_in_code Voir le message
    ...et tant pis s'il n'est pas maintenable...
    hélas oui que que si il n'est pas maintenable ca veut dire que tu dois le voulu/modifier et donc l'adapter, si tu l'adaptes c'est qu'il ne correspond plus aux critères et donc vaut mieux réécrire plutot que d'adapter

    Sinon c'est ce que j'ai l'impression avec mon expérience, on ne touche a rien ou le moins possible (je n'ose imaginer dans des programme certifier) et personnelement je trouve que ca ressemble plus a mettre un amplatre sur une jambe de bois.
    Je serai plus pour l'optique de réécriture que de refactorisation.
    Remplacer une jambe qui boite par un genoux qui boite, certe c'est plus beau mais la personne boitera toujours.
    Mais j'admet qu'on a pas toujours les moyens, le budget, l'envie, la part de risque qui permetent de réécrire tout
    Citation Envoyé par Duitiona
    ...
    Euh tu es sur que c'est de la refacto ou de la correction de bug?
    Je ne suis qu'un pauvre débutant alors ne frappez pas si mes idées ne sont pas bonnes

  9. #69
    Membre régulier
    Inscrit en
    avril 2009
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : avril 2009
    Messages : 30
    Points : 91
    Points
    91

    Par défaut

    Vu l'ampleur, plutôt de la refonte en fait ^^ .

  10. #70
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 137
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 137
    Points : 4 787
    Points
    4 787

    Par défaut

    Citation Envoyé par BenoitM Voir le message
    Sinon c'est ce que j'ai l'impression avec mon expérience, on ne touche a rien ou le moins possible (je n'ose imaginer dans des programme certifier)
    En fait c'est plutôt le contraire, car il y a beaucoup plus de validation. Et l'historique est beaucoup mieux géré. Enfin ce que j'ai vu en tout cas.

    Sur un projet de gestion qui gère des millions de ligne à la journée, on teste rarement (jamais ?) les millions de lignes. Dans le meilleur des cas, on échantillonnent sur certains cas (quelques cas nominaux, quelques cas aux limites, les cas qui ont posé problème et éventuellement quelques cas pris totalement au hasard).
    Sur un projet de ce type tout sera testé ! Par contre comme le souligne Dutiona faut être prêt à payer parce que ca coûte rapidement un bras.
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    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

  11. #71
    Invité de passage
    Inscrit en
    août 2010
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : août 2010
    Messages : 15
    Points : 0
    Points
    0

    Par défaut Bon conseils

    il faut tous ces conseils donné par ces "spécialistes " mais les suivre en priorité dans l'ordre inverse c'est-à-dire en commençant par le dernier conseil.

    Je constate une chose en lisant les propros de ces spécialistes et bien, ils ont les mêmes meilleures conseils que tous mes potes. en tout cas si ce sont ces conseils qui on fait d'eux des spécialistes de haut vol, alors mes potes et moi le deviendront très vite.

  12. #72
    Candidat au titre de Membre du Club
    Inscrit en
    mai 2011
    Messages
    19
    Détails du profil
    Informations forums :
    Inscription : mai 2011
    Messages : 19
    Points : 11
    Points
    11

    Par défaut

    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
    Cette approche peut paraitre absurde: "tenter de répondre à une question dont on a pas la réponse". Celà peut même tendre vers une sorte d'hypocrysie ou un syndrome de Dunning-Kruger...
    Mais, sur un site comme Stackoverflow, celà prend tout son sens: affiner ses connaissances en affinant sa réponse...dans le genre tu vas consulter la MSDN pour être sur d'un détail...

  13. #73
    Membre confirmé
    Avatar de EtherOS
    Homme Profil pro Lionel Tidjon
    Etudiant Polytechnicien
    Inscrit en
    juillet 2012
    Messages
    58
    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 : 58
    Points : 210
    Points
    210

    Par défaut Conseils de Programmation

    +----------------------------------------------+
    + conseil pratique +
    +----------------------------------------------+

    J'ai lu les conseils precedents pour moi tous sont bon et vraiment me seront tres utiles dans ma formation.
    Pour ma part, le meilleur conseil est :
    <<aimer ce que vous faites >> Quand tu aimes ce que tu fais , tu le fait bien et tu y donne ton tout pour que ce soit le meilleur .

  14. #74
    Candidat au titre de Membre du Club
    Homme Profil pro mathieu roiron
    Développeur .NET
    Inscrit en
    février 2012
    Messages
    15
    Détails du profil
    Informations personnelles :
    Nom : Homme mathieu roiron
    Localisation : Suisse

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

    Informations forums :
    Inscription : février 2012
    Messages : 15
    Points : 11
    Points
    11

    Par défaut Planifier avant de coder

    Je développe des petites applications dans le cadre de ma formation.

    Mon conseil est le suivant, définir un design robuste avant d'écrire du code. Les avantages d'une telle pratique sont que le code est documenté avant d'être réalisé, le code est mieux structuré et la maintenance pourra être moins pénible.

  15. #75
    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 roironm Voir le message
    Je développe des petites applications dans le cadre de ma formation.

    Mon conseil est le suivant, définir un design robuste avant d'écrire du code. Les avantages d'une telle pratique sont que le code est documenté avant d'être réalisé, le code est mieux structuré et la maintenance pourra être moins pénible.
    titre de ce forum précis :
    Débats sur le développement - Le Best Of Décideurs : Le meilleur des débats sur les choix de technologies pour le développement. Ce forum est réservé aux professionnels.
    Ce qui explique que tu sortes des choses, euh, je vais rester poli, dépassées. Concevoir avant de coder, c'est à la fois nécéssaire et très insuffisant. si c'était suffisant, il n'y aurait pas besoin de refactoring, de démarches agiles, de gestion des personels comme facteurs prépondérants des projets, etc...

    Ca ne veut pas dire que tu as tort. Simplement, tu n'as fait qu'effleurer le sujet. Généralement, les projets sont trop complexes pour que "définir un design robuste" soit suffisant(même si ça aide). Ca n'est même pas toujours possible.
    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.

  16. #76
    Membre éclairé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 321
    Points
    321

    Par défaut

    J'ai longtemps hésité a poster, mon premier post ici, tant les débats sur ces sujets récurrents sont sans fin.

    Pourtant au risque de paraître hors sujet, s'il est un conseil a donner "quand on programme", c'est de lever la tête et de communiquer, j'entends a titre professionnel. Trop souvent (toujours ?) les développeurs oublient que l'informatique est une activité faite par des hommes et pour des hommes. S'il existe des techniques pour réduire le nombre d'erreurs, de bugs, d'un programme, seule une bonne communication permet de prévenir ses "errements".

    Toujours professionnellement parlant, pour moi, un "bon programme" est celui qui s'adapte au mieux aux imprécisions inévitables d'un "cahier des charges", expression de besoin d'un client ou d'un marketeux, au travail de ses "collègues" développeurs, essaie d'anticiper les difficultés de validation, intégration et d'exploitation ou d'utilisation. C'est a ça qu'on reconnait un architecte débutant d'un expérimenté, le second intègrera dans son architecture des éléments qui n'ont absolument rien de "technologique".

    Plus concrètement, dans son activité de "tous les jours", si tous les conseils cités plus haut sont bons, c'est peut-être celui d'Eric Lippert (participer a des forums) qui me parle le plus. Là encore il est question de communiquer, de compléter ses connaissances, découvrir de nouveaux langages, mais au delà, des approches différentes d'un même sujet. Il n'est pas de problème qui ne peut se décomposer en problèmes "connus" et ne peut trouver sur la toile des sujets similaires qui en parle, voir fournisse directement une "solution".

    Incroyable (en 25 ans de carrière) le nombre de fois où j'ai vu des développeurs réinventer la roue suite a leur manque de connaissances alors qu'une solution était "à portée de download". Apprenez a décomposer efficacement un problème, en ayant enrichi vos connaissances, en "sujets connus", a y intégrer (voir mon premier conseil) les éléments "sensibles" que vous anticipez dans le projet, ajoutez aux conseils précédents celui du "loose coupling" et votre "programme", en tout cas vos travaux seront bien plus "tout terrain" pour évoluer en cours de projet et espérer atteindre au mieux la "cible" qui aura inévitablement bougé en cours de route :-)

  17. #77
    Expert Confirmé

    Développeur NTIC
    Inscrit en
    janvier 2011
    Messages
    1 682
    Détails du profil
    Informations personnelles :
    Âge : 24

    Informations professionnelles :
    Activité : Développeur NTIC
    Secteur : Biens de consommation

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 682
    Points : 3 799
    Points
    3 799

    Par défaut

    Citation Envoyé par I_believe_in_code Voir le message
    ...et tant pis s'il n'est pas maintenable...
    C'est malheureusement la réflexion que se font les portefeuilles d'entreprise ...

  18. #78
    Membre Expert
    Avatar de mumen
    Homme Profil pro
    Développement à façon multisecteur.
    Inscrit en
    mars 2004
    Messages
    545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Développement à façon multisecteur.

    Informations forums :
    Inscription : mars 2004
    Messages : 545
    Points : 1 295
    Points
    1 295

    Par défaut

    • Etre toujours débutant, c'est quelque chose qui me parle. Mais pour moi, ce n'est pas un conseil que quelqu'un pourrait ni même devrait suivre, c'est plus une attitude, un type.


    • J'ai lu dans ce fil le conseil de ne pas chercher à optimiser le code lors de la première écriture. J'étais content de lire ce j'avais appris tout seul... ... sans le formuler et je le recommande très chaudement. Ça marche .


    • Je me fais aussi le témoin d'une amie qui est de l'autre côté de la barrière, elle est utilisatrice. Elle me dit simplement mettez vous à la place de l'utilisateur. Non mais sans blague ! Quel égoïsme !


    • Si je devais donner mon conseil à moi, ce serait de faire en sorte de devoir se rappeler le moins de choses possibles même à un certain prix. Ça paye toujours en tranquillité d'esprit.

      Cela inclut automatiquement d'éviter au mieux la dérive d'utilisation - par le développeur certes - mais aussi par les usagers. La dérive est un témoin vivant pour le programmeur, elle prouve que le travail est mal fait ou pas terminé. Si l'on ne peut l'éradiquer, il faudrait toujours au minimum l'entériner par une action concrète inscrite visiblement dans le développement. La dérive est le précurseur de l'usine à gaz.

    Nakedata : La démo.

    ·

  19. #79
    Membre éclairé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 321
    Points
    321

    Par défaut

    Citation Envoyé par mumen Voir le message
    ...J'ai lu dans ce fil le conseil de ne pas chercher à optimiser le code lors de la première écriture...
    Ce conseil me pose toujours un problème mais je pense me souvenir que nous avons évoqué le sujet il y a quelques temps car le "ne pas optimiser" va se traduire trop souvent par "je fais n'importe quoi". Comme je pense l'avoir écrit il y a quelques temps, il est de nombreux réflexes que l'on doit acquérir en programmation pour écrire un code propre et déjà presque optimum dès la première écriture et ce sans "surcoût".

    Malheureusement j'ai vu trop de code immonde consommant inutilement des tonnes de ressources, trop vu des centaines d'heures perdues en support ou en réingeniering a l'effondrement d'une plateforme quand 5mn d'attention en développement auraient pu les éviter.

    On apprend avec l'expérience a faire la part des choses pour évaluer au mieux l'effort "utile" mais le conseil est alors donné a un développeur déjà expérimenté, pas un débutant a qui je demanderai plutôt de ne pas hésiter a prendre conseil auprès de l'équipe pour l'aider a faire les bons choix.

  20. #80
    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

    Là encore, il s'agit de savoir raison garder. Il y a des petits trucs tous bêtes qui ne compliquent pas vraiment le code. Exemple sous VBA-EXCEL 2003(ou la limite de colonnes est 255, en dur)(attention, code débile) :

    Code :
    1
    2
    3
    4
    BlaBlaTrouve = false
    For colonne = 1 to 255
        If Cells(ligne, colonne) = "Blabla" Then BlaBlaTrouve = True
    Next Colonne
    ça s'optimise assez facilement en allant chercher la dernière colonne remplie, et en sortant si trouve :
    Code :
    1
    2
    3
    4
    5
    6
    7
    BlaBlaTrouve = false
    For colonne = 1 to Cells(ligne, 256).End(xlLeft)
        If Cells(ligne, colonne) = "Blabla" Then 
            BlaBlaTrouve = True
            Exit For
        End If
    Next Colonne
    autre exemple, déjà évoqué par d'autres :
    Code :
    Message = Fonction1(Trim(Ucase(Cells(l,c)))) & "-" & Fonction2(Trim(Ucase(Cells(l,c))))
    facilement optimisé en :

    Code :
    1
    2
    CelFormatee = Trim(Ucase(Cells(l,c)))
    Message = Fonction1(CelFormatee) & "-" & Fonction2(CelFormatee)
    (on peut aussi faire un While, pour les allergiques aux Exit/Break)
    Moi, ça me parait encore simple et lisible. Si on imbrique ça dans une boucle par ligne, le gain de performance peut être important. Et franchement facile.

    Mais si on veut faire encore mieux, on va assez vite se perdre.

    C'est pareil pour une bufferisation d'accès aux données. Mémoriser le dernier appel référentiel, c'est assez facile, et ça rapporte gros(1 heure sur 6 la dernière fois que je l'ai fait). Mémoriser une table des derniers appels, c'est compliqué, et si les données sont triées, ça ne va pas rapporter grand chose de plus.

    Les trucs "simples" de ce genre, ça n'est pas franchement de l'optimisation. C'est juste de la propreté. L'optimisation, c'est de changer d'algorithme pour aller plus vite. C'est beaucoup plus risqué. Dans mes exemples, je ne change pas d'algorithme, je me contente d'utiliser les éléments autant de fois que necéssaire - et pas plus. En gardant l'algo de base, bête et méchant.
    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
  •