Bravo pour votre initiative;

Vos articles sur la POO m'ont éclairé. J'avais du mal a comprendre quel était l'interet mais maintenant je le sais.
J'arrend votre article sur le code avec impatience.

Merci pour vos impressions :-)
Première partie sur le code publiée. En espérant que ça vous parlera.

Salut,

J'aime bien ton image de shaddoks qui pompent dans l'article sur les cahiers des charges. C'est un peu ce que je ressent quand je vois des armoires pleines de ces documents que personne ne lit et qui terminent 10 ans plus tard a la poubelle lors du prochain deménagement :-))))

Je trouve que tu fais un bon boulot de démystification.
Merci.

Je suis intimement persuadé qu'il faut toujours chercher les solutions efficaces et se débarasser de tous ces trucs qui polluent : documents inutiles, réunions longues où rien ne se dégage, planifications fausses mais consommatrices de temps, etc... En gros il s'agirait d'un bon dégraissage de mamouth !

L'approche de tes evaluations est pragmatique ce qui evite de trop se planter! Par contre moi ma direction me demande souvent une evaluation a priori, alors que je n'ai encore rien analysé !

Je calcule des delais au pif et je les multiplie par 2 ! Ca ne marche pas, je suis toujours hors delais; mais je ne sais pas comment faire autrement.

Comment tu ferais toi ?

Merci pour ces conseils et astuces :-)

Multiplie par 3 :-)

Vouloir évaluer (et certainement donner un délais de livraison) alors que l'on ne sait pas quels seront les modules à faire et que l'on ne connait pas les impondérables ça revient à résoudre une équation à 12 inconnues !

Pour moi le mieux c'est de donner, comme tu fais, une première estimation "à la louche" puis de communiquer fréquemment sur l'avancement de ton projet que tu réévalues en permanence (avec ma méthode par exemple).

Si tu parviens à justifier les éventuelles dérives et que tu as des responsables qui connaissent le métier ça ne doit pas poser de problème.

Oui je pense comme toi qu'il n'y a pas de solutions miracles ! Le mieux etant de communiquer le plus souvent possible et d'affiner au jour le jour. Merci pour ton avis.

Ludo

La solution est intéressante mais limitée... si tu n'as pas commencé avec assez d'écart et que tu l'atteins, c'est mort.

La meilleure solution reste pour moi l'identifiant à base de GUID.

1- C'est unique, aucune chance de collision
2- Le jour où par malheur on te demande de fusionner des données de plusieurs bases, il n'y a strictement RIEN à faire, puisque toutes les clés étrangères ne risquent pas de se retrouver 2 fois...

Effectivement les GUID seraient la solution idéale. Ce serait bien que PcSoft les intègre en natif, par exemple au niveau de la déclaration du type d'identifiant unique (il faudrait certainement une table de compteurs). Ceci-dit un développeur pourrait faire cette gestion lui-même.

Ma solutlion consiste juste à initialiser les identifiants sur une application avec gestion d'indentifiants "classiques" dans le but d'améliorer les tests et de détecter facilement les liens corrompus.

Les intégrer en natif n'est pas primordial, les bases de données sérieuses savent le gérer, et je délègue toujours le travail de la gestion des ID à la base.

Et pour HF, c'est pareil dans le fond, quelques triggers font parfaitement l'affaire.

Mais peu de gens sortent de sentiers parfois mal battus de PCSoft ;)