Quand tu obtiens un résultat acceptable...
Oui, je n'avais pas vu la chose comme ça, et pour pousser ton raisonnement au bout c'est peut-être encore plus vrai dans un developpement amateur ou c'est plus ou moins le résultat qui te motive. En fait, je voyais plus que le fait que tu n'avais pas d'échéance réelle, ma remarque n'était pas vraiment réfléchie.
Il faut bien se dire qu'optimiser un truc, c'est un boulot sans nom.
Attention, je ne parle pas d'optimisation sauvage du code style démo, je parle juste de ne pas faire n'importe quoi (comme tu éviterais un 'not in select' en sql si tu le peux). Tu es obligé d'avoir une bonne connaissance de tes objets pour pouvoir les utiliser sans introduire de redondances de traitement. Dans les fait, ce n'est pas toujours évident d'avoir cette connaissance a cause du côté boite noire de l'objet et même si tu l'as un objet peut acceder à une ressource quelconque pour des besoins internes (généralement méthode privée) et toi tu sera obligé de répeter la séquence d'accès à cette ressource pour tes besoins propres (c'est peut-être ce qu'il se passe avec le filemanager de gome). Je pense que c'est un problème de design mais parfois ce n'est pas évident à résoudre, voire impossible de faire proprement. Ce genre de truc tu le rencontres dès que tu dois faire du sur-mesure avec des composants visuels (d'ailleurs le problème est le même avec les modèles relationnels en BD).
Au passage, merci pour la ref (Design Pattern), encore un bouquin à lire :)
Mais le temps de développement coute en général plus cher que les infrastructures.
Ca je n'en suis vraiment pas convaicu. Pour une boite qui vend du logiciel, sans doute, mais pour des softs développés et utilisés en interne, je ne crois pas, surtout s'il sont beaucoup diffusés (changer 30 machines revient à payer quelqu'un pendant un an). C'est vrai que le développement en interne n'est plus vraiment d'actualité, mais je ne pense pas que ça dure (le processus est le même que pour l'objet a outrance: on obtient des spécialistes de leur métier mais incapables de s'interfacer (et de comprendre) une autre branche, uniquement parce qu'il faut un certain bagage pour comprendre le problème et qu'ils n'ont pas le temps de l'acquérir).
Dans mon boulot, il préfèrent (espérons que ça dure :)) mettre le temp et l'argent qu'il faut pour le développement que d'être emmerdés par la suite (ce qui se passe généralement dans les développements externes).
[^] # Re: Un peu comme MS-Windows 1
Posté par Toufou (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Oui, je n'avais pas vu la chose comme ça, et pour pousser ton raisonnement au bout c'est peut-être encore plus vrai dans un developpement amateur ou c'est plus ou moins le résultat qui te motive. En fait, je voyais plus que le fait que tu n'avais pas d'échéance réelle, ma remarque n'était pas vraiment réfléchie.
Il faut bien se dire qu'optimiser un truc, c'est un boulot sans nom.
Attention, je ne parle pas d'optimisation sauvage du code style démo, je parle juste de ne pas faire n'importe quoi (comme tu éviterais un 'not in select' en sql si tu le peux). Tu es obligé d'avoir une bonne connaissance de tes objets pour pouvoir les utiliser sans introduire de redondances de traitement. Dans les fait, ce n'est pas toujours évident d'avoir cette connaissance a cause du côté boite noire de l'objet et même si tu l'as un objet peut acceder à une ressource quelconque pour des besoins internes (généralement méthode privée) et toi tu sera obligé de répeter la séquence d'accès à cette ressource pour tes besoins propres (c'est peut-être ce qu'il se passe avec le filemanager de gome). Je pense que c'est un problème de design mais parfois ce n'est pas évident à résoudre, voire impossible de faire proprement. Ce genre de truc tu le rencontres dès que tu dois faire du sur-mesure avec des composants visuels (d'ailleurs le problème est le même avec les modèles relationnels en BD).
Au passage, merci pour la ref (Design Pattern), encore un bouquin à lire :)
Mais le temps de développement coute en général plus cher que les infrastructures.
Ca je n'en suis vraiment pas convaicu. Pour une boite qui vend du logiciel, sans doute, mais pour des softs développés et utilisés en interne, je ne crois pas, surtout s'il sont beaucoup diffusés (changer 30 machines revient à payer quelqu'un pendant un an). C'est vrai que le développement en interne n'est plus vraiment d'actualité, mais je ne pense pas que ça dure (le processus est le même que pour l'objet a outrance: on obtient des spécialistes de leur métier mais incapables de s'interfacer (et de comprendre) une autre branche, uniquement parce qu'il faut un certain bagage pour comprendre le problème et qu'ils n'ont pas le temps de l'acquérir).
Dans mon boulot, il préfèrent (espérons que ça dure :)) mettre le temp et l'argent qu'il faut pour le développement que d'être emmerdés par la suite (ce qui se passe généralement dans les développements externes).